Daniel sent us this one, and I want to start with the image he opens with, because it's a good one. A computer that has to run flawlessly inside your chest for ten years or more. No swapping the battery. No patch Tuesday. correct, every single cycle, while your immune system is doing everything it can to reject it. Daniel's asking us to map the whole embedded computing landscape, from your ESP32 sitting on a breadboard to the silicon keeping someone's heart beating, and then compare that to other extreme environments: cubesats, deep-ocean sensors, nuclear instrumentation. What silicon goes in these things, what are the constraints, and how does the engineering discipline for something like pacemaker firmware differ from writing a sketch for a hobbyist microcontroller? That's the territory.
I'm Herman Poppleberry, by the way. Quick note before we dive in: today's episode is powered by Claude Sonnet four point six, which is a fun thing to say out loud. The reason this question lands hard for me is that most people, even people who work in tech, have a mental model of embedded computing that stops somewhere around "small computer, low power." And that model is fine until you start asking what it actually means to put one of these things inside a human being, at which point every assumption you've been carrying quietly explodes.
The gap between "small computer" and "implanted computer" is not a spectrum. It is a chasm with a regulatory body standing at the bottom of it.
That is exactly right. And the chasm has a name, and the name is FDA Class III. But we'll get there. Let's build the foundation first, because Daniel's prompt is actually structured really well. He wants the taxonomy before the extremes, and that's the right order.
Four categories, meaningfully different, frequently confused.
An MCU, a microcontroller unit, is the thing most hobbyists encounter first. The ESP32, the ATmega series, the STM32 family. What makes it an MCU is that everything lives on one chip: the processor, the RAM, the flash, the peripherals. You are not building a system around it, you are building a system with it. The tradeoff is that the architecture is fixed. You get what the manufacturer put on the die.
Fixed is not a dirty word when fixed is exactly what you need. There is actually a useful analogy here. An MCU is like a studio apartment where the kitchen, the bedroom, and the living room are all in one room. You did not design the layout, but everything you need is right there and you are not paying for square footage you will never use.
That is a better analogy than most I have heard. And it captures why the MCU dominates the volume market. The vast majority of embedded systems in the world do not need architectural flexibility. They need a thing that reads a sensor, makes a decision, and drives an output, reliably, cheaply, and at low power. The MCU is that thing.
Precisely the point. A PLC, a programmable logic controller, is a different beast entirely. It is not primarily a computing device in the way we usually mean. It is an industrial control device that happens to have a processor in it. The priorities are determinism, ruggedness, and surviveability in environments with vibration, temperature swings, and electrical noise. Factory floors, HVAC systems, water treatment plants. The programming model is different too, ladder logic rather than C or Python.
Which is deliberately approachable for electrical engineers who think in relay diagrams rather than code.
And the ruggedness point is worth dwelling on for a second. A PLC in a steel mill is dealing with electromagnetic interference from arc furnaces, ambient temperatures that can swing sixty degrees Celsius over a shift, and vibration profiles that would shake a consumer PCB apart in a week. The hardware design philosophy is completely different from anything in the hobbyist or even the standard embedded world. Wide operating temperature ranges, conformal coating on the boards, connectors rated for thousands of insertion cycles.
The Siemens S7 series is probably the most widely deployed PLC family in the world, and if you look at the hardware specs, the operating temperature range alone tells you something. Minus twenty-five to plus sixty Celsius for some variants. That is not a number you see on an ESP32 datasheet.
Then you have SoCs, systems on a chip. This is where the integration goes much further. You are putting a full application processor, often multiple cores, a GPU sometimes, memory controllers, wireless radios, all on one piece of silicon. Your phone's main chip is an SoC. The Raspberry Pi's chip is an SoC.
High performance, but you are paying for it in power draw.
FPGAs, field-programmable gate arrays, are the outlier. You are not programming a fixed processor. You are literally configuring the logic gates themselves. Massively parallel, reconfigurable, but the development overhead is significant. Hardware description languages, long synthesis times.
So: MCU for constrained control, PLC for industrial determinism, SoC for application-level compute, FPGA for when the problem itself is the hardware. That's the map — and it's a framework that really only works because these categories are distinct.
And that distinction is crucial. People conflate MCU and SoC constantly, but understanding the differences is key when you're making a hardware decision.
Where does that confusion come from? Because the ESP32 gets called an SoC in some datasheets and an MCU in others, and I have seen arguments about it online that go nowhere productive.
The ESP32 is a genuinely interesting edge case. Espressif calls it an SoC, and technically they are not wrong. It has dual-core Xtensa processors, integrated Wi-Fi and Bluetooth radios, a hall effect sensor, capacitive touch controllers, all on one die. But in terms of how people use it and what it competes with, it behaves like an MCU. The programming model is MCU-style, the power profile is MCU-adjacent, the use cases are MCU use cases. So you get this terminology drift where the same chip answers to both names depending on who is in the room.
Which is fine until you are trying to explain to someone why they should not use it to run a neural network inference pipeline at scale.
The ESP32 is exceptional at what it is for. You want a connected sensor node that wakes up, reads a temperature, publishes over MQTT, and goes back to sleep drawing microamps in deep sleep mode? That chip is almost unreasonably capable for the price. Espressif got the power gating right. The deep sleep current is around ten microamps, which means on a small lithium cell you are talking months of operation.
For ten dollars or less, which is why it is in everything from smart plugs to industrial sensor nodes.
The STM32 family is worth spending a moment on because it covers an enormous range. STMicroelectronics has dozens of STM32 variants. The STM32L series is optimized for low power, the STM32F series for performance, the STM32H series pushes into territory where you are getting Cortex-M7 cores running at several hundred megahertz with double-precision floating point. These are not hobbyist chips, they are production silicon in automotive, industrial, and medical applications.
The ATmega is the ancestor. Arduino made it famous. But in a new design today, you would have to have a strong reason to reach for an eight-bit AVR over a thirty-two bit Cortex-M part at the same price point.
The nostalgia is real though. There is a simplicity to the ATmega architecture that has genuine pedagogical value. You can trace every clock cycle. For teaching, that is not nothing.
Where does the FPGA actually earn its complexity premium? Because the development overhead is not trivial. If I am a small team, when does it become worth it?
Signal processing is the canonical answer, and it is canonical because it is correct. When you need to process data streams in real time at rates that would saturate any fixed processor, the FPGA's parallelism is not a luxury, it is the only option. Software-defined radio is a good example. You are receiving a wideband RF signal, you need to do filtering, decimation, demodulation, all in real time, potentially at hundreds of megasamples per second. A microcontroller cannot touch that. Even a high-end SoC struggles without dedicated hardware acceleration. An FPGA handles it because you are not serializing operations through a processor pipeline, you are running all of those operations simultaneously in dedicated logic fabric.
The question is less "is FPGA better" and more "is my problem inherently parallel.
That is the right framing. And there is a medical connection here that is worth flagging before we move into implants properly. Cochlear implant signal processing has historically used FPGA-adjacent architectures, custom ASICs built from FPGA-proven designs, because the audio processing pipeline for stimulating the auditory nerve has real-time requirements that are non-negotiable. You cannot buffer and process later. The latency budget is measured in microseconds.
How tight are we talking? Because microseconds covers a lot of ground.
The auditory system is extraordinarily sensitive to timing. The interaural time difference that lets you localize sound is on the order of tens of microseconds. Cochlear implant processors are not trying to replicate that at the electrode level, but the overall processing chain from microphone to nerve stimulation has to stay under a few milliseconds or users report the audio feeling disconnected from the visual world. Lip sync, essentially, but for your own ears. So the individual pipeline stages have to be much faster than that aggregate budget.
An ASIC is the endpoint of that journey. You prove it on an FPGA, then you tape out the custom silicon once the design is locked.
And in medical devices, taping out custom silicon is not unusual at all. It is expensive, but when you are making millions of units and the power budget is in microwatts, custom silicon pays for itself. Which is actually a perfect segue into what makes implanted devices their own category entirely, because everything we have described so far assumes you can reach the hardware if something goes wrong.
Inside someone's chest, you cannot.
That is the constraint that changes everything. The moment you seal the enclosure and implant it, you have committed to every decision you made during development. There is no field service call. There is no firmware rollback via USB. The device either works for ten years or the consequences are immediate and serious.
Walk me through what is actually inside a modern pacemaker. Because I think most people picture something more sophisticated than the reality.
The silicon is simpler than you would expect, and deliberately so. Modern pacemakers from the major vendors, Medtronic, Abbott, Boston Scientific, are built around ultra-low-power ARM Cortex-M0 or Cortex-M0-plus cores. Not the M4, not the M7. The smallest, simplest member of the ARM Cortex-M family. Thirty-two bit architecture, no floating point unit, minimal instruction set. And that is not a cost-cutting decision. That is an engineering discipline decision.
Simpler means fewer things that can go wrong.
Fewer transistors switching means lower power draw, lower heat generation, and a smaller verification surface. When you are doing formal verification on firmware, every line of code you add is more proof obligation. The M0 architecture has a tiny instruction set, which means the compiler output is predictable and the behavior under edge cases is well understood. You are not getting surprises from out-of-order execution or branch prediction. It does exactly what you told it to do, in the order you told it to do it.
Which is the opposite of what you want from a high-performance processor and exactly what you want from something running inside someone's chest.
The battery chemistry is also specific and interesting. Pacemakers have historically used lithium-iodine cells, which are unusual. They are not rechargeable, they have a very flat discharge curve, and they can last ten to twelve years at the current draws these devices operate at. The average current consumption on a modern pacemaker is in the range of ten to thirty microamps. That is how you get a decade of runtime from a cell that weighs a few grams.
For comparison, the ESP32 in deep sleep is around ten microamps, and we were impressed by that.
And the ESP32 is not running cardiac sensing algorithms while it sleeps. The pacemaker is. It is continuously monitoring the cardiac signal, making pacing decisions, logging events, all at that power budget. The analog front end for sensing the cardiac signal is often more power-hungry than the digital processing. Getting that front end down to sub-microamp quiescent current is a serious analog design challenge.
What about newer devices that do support inductive recharging? Because I know some implantable cardioverter-defibrillators and the newer leadless pacemakers have moved in that direction.
The leadless pacemaker trend is interesting from an engineering standpoint. Traditional pacemakers sit in a subcutaneous pocket near the collarbone with leads threaded into the heart. Leadless devices like Medtronic's Micra series are self-contained capsules implanted directly into the right ventricle. No leads, which eliminates a significant failure mode because leads fracture and insulation degrades over time. But you have a much tighter volume constraint, which makes the power budget even more severe. There is active research into energy harvesting from cardiac motion, piezoelectric transducers that convert the mechanical energy of the heartbeat into electrical charge. The numbers are not yet compelling enough for primary power, but as supplemental trickle charging it is plausible.
The heart powering its own pacemaker. There is something almost poetic about that, and I say that as someone who does not usually traffic in poetry.
The biocompatibility layer is the part that does not get enough attention in technical discussions. The silicon itself is encapsulated, typically in a titanium housing with a hermetic seal, because the body is a remarkably hostile electrochemical environment. Chloride ions, proteins, immune cells. The electronics never touch tissue directly. But the leads, the electrodes that interface with cardiac muscle, those do. And the coating on those electrodes, steroid-eluting tips to suppress the inflammatory response at the tissue interface, that is a materials science problem running in parallel with the electronics problem.
You have got a firmware problem, a power problem, an analog design problem, and a materials science problem, all of which have to be solved simultaneously and verified to a standard that no consumer product ever approaches.
FDA Class III is the regulatory category, and it is worth being specific about what that means in practice. Class III covers devices that sustain or support life or present a potential unreasonable risk of illness or injury. The premarket approval pathway, the PMA, requires clinical trial data, manufacturing quality documentation, and a level of software verification that is categorically different from anything in consumer electronics. The software development process is aligned with IEC 62304, which mandates traceability from requirements through design through code through test. Every function has a risk classification. Safety-critical functions require unit tests, integration tests, and often formal proof.
Can you put a number on what that verification process actually costs? Because I think people hear "rigorous" and do not fully register what that means in dollars and time.
The figures that get cited in the industry are sobering. A typical PMA submission for a Class III device can run into the tens of millions of dollars when you factor in clinical trials, the quality management system overhead, and the software documentation burden. The software documentation alone for a pacemaker firmware release can run to thousands of pages. Not because anyone wants to produce thousands of pages of documentation, but because the traceability requirement means every requirement has to be linked to a design element, which has to be linked to a code module, which has to be linked to a test case, which has to be linked to a test result. That chain has to be complete and auditable. If you cannot close the chain, you do not have a submission. And that is before the FDA reviewer asks any questions.
The coding standard question is interesting. Because in the embedded world generally, MISRA-C is the standard people cite for safety-critical firmware. Is that what pacemaker teams are actually using?
MISRA-C is the floor, not the ceiling. MISRA-C restricts the subset of C that is allowed: no dynamic memory allocation, no recursion, no unreachable code, limited use of pointers. Those restrictions exist because undefined behavior in C is a genuine hazard when you cannot tolerate surprises. But pacemaker firmware teams go further. Static analysis tools, code coverage requirements that approach one hundred percent for safety-critical paths, and in some cases formal verification using tools like Frama-C or model checkers. The DO-178C standard from aviation is adjacent and influential even though it is not directly applicable to medical devices. Some medical device teams explicitly adopt DO-178C-level rigor because the FDA recognizes it as a credible approach.
The no-dynamic-memory-allocation rule is one of those things that sounds arbitrary until you have seen a heap fragmentation bug in production. At which point it sounds like the most obvious rule in the world.
Dynamic allocation in a long-running embedded system is a time bomb. The heap might behave perfectly for weeks and then fragment in a way that causes an allocation failure at a moment that cannot be predicted or reproduced in testing. In a system where you need to reason about worst-case behavior, that unpredictability is disqualifying. You allocate everything statically, at compile time, and you know exactly what your memory map looks like before the device ever ships.
Then someone finds a vulnerability in the wireless communication stack, and all of that rigor runs into a different kind of problem entirely.
Jude Medical situation in 2017 is the case study here. The FDA issued a safety communication about cybersecurity vulnerabilities in Abbott's St. Jude pacemakers and ICDs. The devices had a radio frequency communication protocol for remote monitoring that was not adequately secured. Researchers demonstrated that an attacker in radio range could potentially issue unauthorized commands. Abbott issued a firmware update, which was itself a significant moment because it demonstrated that over-the-air updates for implanted pacemakers were technically feasible. But it also surfaced a genuine tension in the field.
Because the same radio that lets a cardiologist check the device remotely is a potential attack surface.
The update mechanism itself carries risk. If a firmware update corrupts the device, you cannot roll back by pulling a battery. The validation requirements for an OTA update to an implanted cardiac device are extraordinary. You are not pushing a patch and hoping for the best. Every build is tested exhaustively, the update protocol has multiple integrity checks, and the device has a fallback to a known-safe operating mode if the update fails verification. The regulatory filing for a firmware update to a Class III device is itself a significant undertaking.
There is a broader principle hiding in that St. Jude case that I think is worth naming. The security model for implanted devices was designed in an era when the threat model was essentially physical. Someone would have to be in the same room as the device programmer to interact with it. The moment you add wireless range, you have expanded the attack surface to anyone within radio distance, and the original security assumptions do not hold.
Which is a pattern that shows up across the entire IoT landscape, not just medical devices. The threat model gets designed for the deployment environment that exists at the time, and then the environment changes. The difference with cardiac implants is that the stakes of getting that wrong are uniquely high.
I want to push back gently on something I have been hearing in the broader medical AI conversation, because it comes up whenever someone talks about smart implants. The idea that you would put machine learning inference inside a pacemaker. And I am skeptical.
You should be skeptical. The engineering discipline for implanted cardiac devices is specifically oriented around eliminating cleverness. You want deterministic behavior. You want to be able to prove, not just test, that the device will respond correctly to every input state. A neural network running on embedded hardware introduces a verification problem that is currently unsolvable to the standard these devices require. The FDA has frameworks for AI-enabled medical devices, but they are primarily for external diagnostic tools, imaging analysis, that kind of thing. Putting a non-deterministic inference engine inside something that is keeping someone alive is a different proposition entirely.
The discipline is about removing uncertainty, not adding capability.
That is exactly the right frame. The capability question for implanted devices is almost always secondary to the reliability question. And that is what separates the pacemaker firmware engineer from the person writing ESP32 sketches. Not intelligence, not skill. It is the question you start with. The ESP32 developer asks what can I make this do. The pacemaker firmware engineer asks what is the worst thing this could do, and how do I prove it cannot.
Right, and that reliability-first mindset scales down from pacemakers to less extreme environments too. If you're building something for a critical application but aren't yet at the pacemaker end of the spectrum, what does that actually look like in practice? Because there's a lot of territory between writing an ESP32 sketch and doing formal verification on cardiac firmware.
The first question to ask is what does failure cost. And I mean that literally. Write it down. If this device fails, what happens? If the answer is the product ships a wrong temperature reading, you are in one world. If the answer is a patient receives an incorrect insulin dose, you are in a completely different world with a different toolchain, different process, different regulatory posture.
That failure cost question is probably the most useful single frame for choosing hardware and methodology. Because it collapses a lot of the taxonomy we spent the first half of this episode building.
It cascades into everything. Power budget, verification depth, the choice between an MCU and an FPGA, whether you need a real-time operating system or whether a bare-metal loop is actually safer because there is less scheduler behavior to verify. All of those decisions flow from failure cost.
The RTOS question is interesting because it cuts against the intuition that more infrastructure means more reliability. Can you say a bit more about when a bare-metal loop is actually the safer choice?
A real-time operating system introduces a scheduler, and a scheduler introduces timing behavior that is harder to reason about than a simple sequential loop. In a bare-metal system, you know exactly when every piece of code runs relative to every other piece of code. In an RTOS, task preemption and priority inversion are real phenomena that can produce bugs that only manifest under specific timing conditions that are extremely difficult to reproduce in a test environment. For a device where the failure cost is high enough, the question becomes: is the capability the RTOS gives me worth the verification burden it introduces? For some devices the answer is yes, because the complexity of the application demands it. For a pacemaker, the answer has historically been no.
There is also a cubesat angle here that Daniel flagged and we have not touched on yet. Because space is another environment where you cannot reach the hardware after deployment, and the constraints are different again.
Space is fascinating because the failure modes are almost inverted from the medical case. In a pacemaker, your primary enemy is power depletion and the biological environment. In a cubesat, your primary enemy is radiation. High-energy particles from cosmic rays and trapped radiation belts cause single-event upsets, which are bit flips in memory or registers caused by a particle strike. A bit flip in the wrong register at the wrong moment can corrupt a computation, crash the processor, or in the worst case latch the device into a state it cannot recover from without a power cycle.
You cannot power cycle it from the ground on demand.
Not reliably, no. The mitigation strategies are interesting. Radiation-hardened silicon uses design techniques at the transistor level to make bit flips less likely. But rad-hard parts are expensive and the performance is often lower than commercial equivalents because the hardening techniques trade off against speed and density. The cubesat community, which tends to be university labs and small commercial operators working on tight budgets, often uses commercial off-the-shelf parts and compensates in software. Error-correcting memory, watchdog timers that reset the processor if it stops responding, voting architectures where you run the same computation on three separate processors and take the majority result.
The voting architecture is a fun one. You are essentially building fault tolerance by redundancy and then arbitrating. Which is what you do in aviation too.
The Boeing 777's flight control computers use a triple-redundant voting architecture with processors from three different manufacturers running different software implementations, specifically to guard against a common-mode failure where a single bug or a single particle strike takes out all three simultaneously. The diversity is deliberate. It is expensive and complex, but the failure cost calculation says it is worth it.
Which brings us back to the frame we keep returning to. What does failure cost, and what complexity is justified by that cost.
For listeners who are developers and want to get closer to this space without immediately submitting a PMA to the FDA, the open-source medical IoT space is worth exploring. There are projects working on open-source artificial pancreas systems, continuous glucose monitor integrations, that kind of thing. The regulatory situation for personal use is different from commercial device development, and the community has done serious engineering work.
OpenAPS is the one I would point people toward. It is an open-source closed-loop insulin delivery system that has been running on real patients for years. The engineering discipline in that community is rigorous given that it is volunteer-driven. And it gives you a concrete codebase to read where the failure cost question has been taken seriously.
Reading production firmware for a safety-adjacent application is a different education than any tutorial.
You see the defensive coding patterns, the watchdog timer discipline, the way error states are handled. That's what the curriculum is all about.
That's a great place to leave people, honestly. Because, in the end, the curriculum is the codebase.
The field is not standing still. The leadless pacemaker trend we touched on, energy harvesting from cardiac motion, closed-loop neural stimulation in deep-brain devices that adjusts parameters based on real-time biomarker feedback. The constraint envelope is shifting, slowly and carefully, but it is shifting.
The deep-brain stimulation case is worth a sentence or two because it represents a different point on the capability-versus-reliability curve. Current DBS devices deliver continuous or scheduled stimulation at fixed parameters. The next generation, devices like Medtronic's Percept PC, are starting to do adaptive stimulation, where the device reads a biomarker from the local field potential and adjusts stimulation parameters in response. That is a closed-loop control system running inside someone's skull, and the verification challenge for a system that changes its own behavior based on sensed data is categorically harder than verifying a fixed-parameter device.
The frontier is not putting a neural network in a pacemaker. It is building closed-loop controllers that are still deterministic and verifiable but respond to physiological state. Which is a much more tractable problem.
The open question I keep coming back to is where the verification tooling goes. Because the gap between what formal methods can prove today and what the next generation of implantable devices will require is going to widen before it narrows. That seems like the hard problem.
And it is not just a software problem. As devices get more capable, the interaction between the analog front end, the digital processing, and the wireless stack becomes harder to reason about in isolation. You need co-verification across domains that currently have completely separate toolchains. That is a research problem that will take a decade to mature into production practice.
Which, not coincidentally, is about how long the battery lasts.
Perfect timing, as always.
Big thanks to Hilbert Flumingtop for producing, as ever. And this episode runs on Modal, keeping our compute fast and our bills predictable. If you got something out of today, a review on Spotify goes a long way. This has been My Weird Prompts. We will see you next time.
