Can AI write embedded firmware? Yes. I ship a tool that does it, and I still would not leave it alone with a board that matters. Both are true at once, and most writing on this picks one and runs with it.
Here is the short version. A model can write the firmware for a small, well understood board, the kind that reads a sensor and blinks a light and sends a number somewhere, and it will get there faster than you will from a blank file. It falls over on timing, on anything with a deadline, and on hardware it cannot see. The gap between "it compiled" and "it works on my desk for a week" is where almost all of the real work lives, and that gap is not closing as fast as the demos suggest. What follows is what I have seen building it, plus what the people measuring it have published.
Why firmware is harder for a model than web code
The reason has nothing to do with the language. C is not harder than TypeScript for a model. The difference is what happens after the code is written. Write a web endpoint wrong and something tells you: a test fails with a line number, a server throws a stack trace. The loop from "wrote it" to "told exactly what broke" takes seconds, and a model can run that loop on its own until it stops failing.
Write firmware wrong and the light just does not come on.
Nothing in the silence tells you whether the bug is in the code, the schematic, a part placed backwards, or a solder joint. A model with no way to look at the board is guessing about the one thing that defines the job, which is the hardware in front of you. The datasheet it trained on might be the wrong revision. The chip on your board might be a clone with a different register map. The sensor might be fine and the pull-up resistor missing.
There is a second problem under that one. Firmware is not judged on whether it produces the right answer once. It is judged on whether it keeps producing it after four days, at the temperature inside the case, while a second peripheral competes for the same bus. Almost nothing in the public code a model learned from was ever tested that way.
What the benchmarks actually say
This is the part I find useful, because people quote numbers at me without reading what they measured. The clearest public benchmark is EmbedBench, which ran ten mainstream models over 126 cases covering nine electronic components across three hardware platforms. It is worth looking at where the numbers land, because the spread tells you more than the average.
The best model got about three quarters of the way there porting Arduino code to MicroPython on a Pico, and under a third of the way there porting the same kind of code to ESP-IDF. That is not about model quality. It is about how much of a platform's behaviour lives in documentation the model has read, versus in vendor SDK quirks it has not. The further you get from the well trodden path, the worse it does, and the drop is steep rather than gradual.
The caveat is what "right" means there. It means the code compiled and passed a functional check. The engineers at Veecle went through this carefully, and their conclusion is the one I would underline: none of these benchmarks test firmware under runtime conditions. No interrupt timing, no soak runs over days, no temperature, no two peripherals fighting over a bus. So 55 percent does not mean 55 percent of the firmware works on a board. It means 55 percent got far enough to be worth testing.
Their other write-up on the failure modes lists the ones I recognise from my own debugging: DMA buffers placed in flash, shared state touched before interrupts are masked, a UART baud divisor computed off the wrong clock tree. Every one of those compiles, and looks correct when you read it.
What changes when the tool can talk to the board
The single biggest thing you can do about all of this is close the loop. If the tool can reach the hardware, it stops guessing and starts asking. That is the bet we made with Tovan. It designs the board, so it already knows which pin the sensor sits on, which is half the context a model is usually missing. Then it sends the code to the board over a USB cable from Chrome or Edge, reads what the board actually reports back, and asks the sensors questions directly instead of assuming the datasheet is right. Firmware is in beta, and every supported board is in beta too: ESP32-S3, Raspberry Pi Pico and other RP2040 boards, XIAO nRF52840, ESP32-C3, ESP32-C6, RP2350 boards, nRF52840 modules. No exceptions, no tiers.
What that buys you is not magic. It is a narrower kind of wrong. When the tool can measure, the failures left over are the ones measurement cannot catch, which is a much smaller set than "anything could be broken anywhere."
A real example: the sample rate that was wrong
The clearest case I have is one I wrote up when we launched the feature. I had Tovan design a small heart rate prototype, strapped it to my wrist, and asked in one line for it to read my heart rate. It is a prototype, not a medical device, and nothing about the reading is medical grade.
The heart rate prototype from the firmware launch, on my wrist. A prototype, not a medical device.
It had a live reading about four minutes later, and ran five tests on the real board, all of which it started itself. The one that matters is the fourth. It read the sensor chip's own sample counter and found the chip was producing about 52.65 samples a second, not the 50 it had assumed. That 5 percent error was quietly skewing every beat interval. It moved the beat timing onto a real clock and measured the chip's real rate at startup instead of trusting the number.
It is easy to oversell that, so I want to be precise. A model guessing from a datasheet would have written the same wrong assumption. The difference is not that it was smarter, it is that it could ask the chip, so the mistake got caught on my desk instead of three weeks later when somebody noticed the readings were a bit high. It also asked me to count my own pulse for 30 seconds to check its answer against something outside itself.
Sensor work like that usually takes several passes. Simple requests, a light that comes on when a button is pressed, are often quick. I am not going to tell you it works first time, because it does not always, and anyone telling you otherwise has not shipped it.
Where it still falls over
- Anything with a hard deadline. Motor control loops, audio, anything where being 200 microseconds late is a failure. Models write code that is functionally right and temporally wrong, and nothing in the toolchain complains.
- RF and anything near certification. If a regulator is going to look at it, you want a person who has been through that. This is also where Tovan stops, deliberately.
- Chips nobody has written about. A new or obscure part, or one whose only documentation is a four page PDF in another language. The model has nothing to draw on and will confidently invent a register map.
- Anything safety related. If a bug hurts somebody or burns something, this is not the tool, and that goes for every tool in this category.
- Long running behaviour. Counter wraparound, drift, memory that leaks slowly. These show up on day four, and nothing in the write-test loop runs for four days.
Notice how many are about time rather than logic. Models are good at "what should this code say" and bad at "what will this code do on the hundredth hour."
How to use it without getting burned
I use AI written firmware every week and have not been bitten badly, mostly because of a few habits.
Read the code, all of it, once. Not because you distrust it, but because those five minutes are where you catch the assumption that does not match your board. In Tovan it sits in the Code view and you can copy it out. While you are in there, check the parts that matter against the datasheet yourself: register addresses, initialisation sequence, anything with a timing requirement. Not all of it. The three things that would be expensive to get wrong.
Treat it as a fast first draft on a board you can see. The value is not that it is correct. It is that you start from something that compiles and roughly works instead of from an empty file and a 400 page reference manual. That is worth a lot, and it is not the same claim as "it is done."
Test it on real hardware before you believe anything. Compilation is not evidence. If you have not watched the board do the thing, you do not know.
Keep each request small. One behaviour at a time. A request bundling four features gives you four places to look when it misbehaves.
What would have to be true before this is boring
The thing I am watching for is not a better model, it is a better loop. Firmware becomes genuinely boring when the tool can run the code on real hardware for a long time, under varying conditions, and reason about what it sees. Soak testing it starts itself. Instrumentation it can read without you wiring up a logic analyser. Some way to catch the bug that only appears when two things happen at once. None of that is a model capability. It is plumbing, and plumbing arrives quietly.
The second thing I want is honest reporting of what was and was not verified. Right now a tool hands you code and you have no idea which lines it checked against hardware and which it inferred, and that includes our own product.
Until then, the answer to "can AI write embedded firmware" is: it can write it, it can increasingly check parts of it, and you are still the one who decides it is good enough. If you want to see where that lands for a board you have in mind, you can describe it and watch what comes back. Designing needs no subscription, and there is a free allowance of build credit that refills every week.
Frequently asked questions
Can AI write embedded firmware that actually runs on real hardware?
Yes, for straightforward behaviour on common microcontrollers. The reliable path is a tool that can send the code to the board and read back what it reports, so it corrects against the hardware rather than its own assumptions. Code written with no access to the board is a draft, not a result.
What kind of firmware does AI get wrong most often?
Anything with timing in it. Interrupt priority, DMA, real time deadlines, peripherals competing for the same bus. These compile cleanly and read correctly, which is what makes them expensive.
How accurate are the published AI firmware benchmarks?
They are accurate about what they measure, which is compilation and functional checks. The best model in EmbedBench reached 73.8 percent on one migration task and 29.4 percent on another, and none of the benchmarks test behaviour over time, temperature, or contention. Read them as a floor on difficulty, not as a success rate for shipped firmware.
Can Tovan write firmware for any board?
No. It writes firmware for the boards it designs, on the chips it supports, and every one of those is in beta: ESP32-S3, Raspberry Pi Pico and other RP2040 boards, XIAO nRF52840, ESP32-C3, ESP32-C6, RP2350 boards and nRF52840 modules. The code goes to the board over a USB cable from Chrome or Edge on a computer, not over WiFi and not from a phone.
Related reading: who writes the firmware for your custom PCB, and how to pick a microcontroller for your first product, because the chip you pick decides most of how well any of this works.
0 comments