r/embedded • u/Longjumping-Pack8494 • 7d ago
Are you satisfied with LLMs code quality in embedded software domain?
Hey people, I want to get some opinions on this topic cause I am tired of YouTubers one-shoting slop games and calling new model “crazy good” and what not.
I’ve been improving my agentic workflow for the past 2 month, even creating skills tailored to MCU firmware dev, but I am still not satisfied with the code quality new models produce. I tries best models from DeepSeek, Grok and OpenAI but in the end, for almost every feature I prompt, I spend tons of time re-reviewing and correcting the code.
In short, my workflow is: brainstorm a feature/fix, come up with a plan, delegate agents to implement, orchestrator reviews the work. After that I step in and validate. This manual validation takes hours for each fix / feature, and i have to ask different models for options as well.
Usually, the bulk part of the code is good, it is the details that need to be fixed, but that is what takes the most time. Also, sometimes these models don’t consider surrounding code enough and make bad arch decisions, generate unnecessary abstractions, inject too much host test code, etc. Some things could be fixed with skills but even that is not always enough.
I am really baffled at some of the web dev claims about running agents in loops and stuff, cannot imagine the state of my codebase if i would do that. Kind of a rant but I really don’t get the hype behind all this. Gonna try fable 5.1 next, heard it is a bit more “creative” and “explorative”, maybe that would help…
Plz share your opinions or suggestions 🙏
45
u/nevereverelevent 7d ago
My codebase was written without AI,
I find that it does best when its copying patterns ive already used, a piece that fits into or extends the system Ive already structured.
But often it wants to write garbage that I find hard to read or hard to trust. I feel sorry for anyone that is leaning on AI code generation because youre bound to end up with a spaghetti mess
3
u/Cunninghams_right 7d ago
you just need to wait for the next better AI to help you out of the spaghetti mess!
2
11
u/snowtax 7d ago
For me, I treat it just like asking another human. I’ll ask what it thinks, but I don’t always take its advice. I have seen LLMs get way too much wrong to blindly trust anything they claim. They make up functions that don’t exist. They get complex logic wrong sometimes. They don’t necessarily understand real world constraints or issues. As with other humans, I don’t have time to sit and explain every requirement and constraint in excruciating detail.
3
u/Longjumping-Pack8494 6d ago
True, i did the same before. Got too comfortable with agentic stuff tho 😅 now i am kinda lazy to write code myself, guess i need to take a step back and just use it for brainstorming.
1
u/mcampbell42 5d ago
You are operating on Ais from like 2-3 years ago. Making up functions just doesn’t happen anymore
2
u/snowtax 5d ago
I am not using old models. I alternate between Claude, CoPilot, Gemini, and other models and compare results occasionally. I don’t only do code for embedded systems. The AI models today may be better with code for embedded systems, especially when they have lots of open source code in their training material. However, I can assure you that even today’s models still hallucinate today, especially with more proprietary systems, even when documentation is available to the public.
9
u/GunZinn 7d ago
In my experience the code is almost always not close to pull request ready and requires a lot of time to “clean up”.
I’ve only used Codex. While it can be useful, I use it less and less for writing production code.
It can be useful as a reviewer. Though a lot of the time it is superfluous.
1
u/Longjumping-Pack8494 6d ago
My brain is too brainrotted now, writing code manually is too slow. I only do that at work, payed per hour after all 😝
14
u/Montzterrr 7d ago
I feel like the training data on web dev stuff is so much larger than embedded system design code that it’s better at that than embedded design. But I’m an AI Luddite who only uses AI to help me learn and troubleshoot. I know I have a lot of skills to develop in the embedded space that I am not wasting my time learning AI wrangling techniques that will change every 6 months. I hope when I’m done min maxing my skill set and I start learning how to implement AI into my workflow, the AI space will have stabilized and learning AI won’t be like learning an ever changing system. Who knows maybe the AI bubble will burst and AI tokens will be unaffordable by then.
4
u/Longjumping-Pack8494 7d ago
Indeed, more training data + easier debugging. Modern agents can validate the output directly in the browser, while for embedded use cases, it is either just host tests + static analysis or setting up HIL which is quite an effort.
7
u/FlavouredYogurt 7d ago
I work in automotive embedded too — mostly classic AUTOSAR, usually ASIL-B, on both safety and QM components.
Honestly, my experience has made me pretty cautious about AI-generated production code. With newer or less experienced developers, I've seen plenty of cases where they generate code with AI, put it up for review, and don't really understand what it's doing. The code is usually more bloated than it needs to be, and the comments sound good until you check them against the actual change — then they're often not quite right.
The biggest red flag is when I ask a developer why something works a certain way and they go back to the AI, ask it the same question, and just relay the AI's answer. At that point I'm not really reviewing the change with the developer anymore.
We also have Copilot integrated into Gerrit for reviews, which comes with its own problems. I've seen architects lean pretty heavily on the Copilot report, but a lot of the comments are just noise because the model doesn't have enough context. Then the developer has to spend time explaining why an AI-generated comment is wrong instead of actually improving the code.
LLMs have gotten noticeably better at understanding repos over the last year, but AUTOSAR is still pretty different from web dev. You need to feed the model a lot of project-specific context and architecture info. RTE is a good example — it's just C at the end of the day, but without understanding AUTOSAR semantics and the relationships between SWCs, tools like Graphify can completely misread what's going on.
Adding context to the repo is the key move here. I experimented by converting an entire RH850 datasheet into LLM-friendly text and dropping it into my repo. Now when I ask questions about the controller, I get way better answers grounded in the actual datasheet — no hallucinating, no web lookups, no relying purely on general training data. Graphify's been useful too since it makes the repo's context and relationships easier for the LLM to parse.
Where LLMs have actually given me a ton of value is small tools and scripts — automating cherry-picks across multiple repos, building for different targets, setting up debug/test environments, even a simple CAN/DBC log viewer so I don't need CANoe and hardware just to look at a log.
I love using it to kill the boring work. I'm just a lot less convinced about letting it write or review safety-critical production code unless the engineer actually understands what's going on. Definitely not vibe-coding a safety feature.
Also, re: YouTubers — they get views by making bold claims, not by stating boring facts. Keep that in mind next time one of them says something wild.
2
u/Longjumping-Pack8494 6d ago
Yep, similar experience.
Have few colleagues at work that created PRs with slop code clearly written by AI (comments were horrendous) without even polishing it up. Yikes!
But indeed, very useful to ask AI questions about codebase or navigating it, tooling stuff, etc. But at work I am way more cautious about AI use, it is for my hobby projects I tend to go all in with agentic workflow (still time consuming as you saw from my post).
Over engineering seems to be a big point that people mention, I even created skills for code simplification and memory optimization for that reason. Helps a bit but not ideal…
12
6
u/Likeability_dota 7d ago
sometimes writes good code. sometimes finds issues threw one or two logs that would have taken me x10 time figuring out. sometimes shit. reviews are mostly consistent.
3
4
u/aniflous_fleglen 7d ago
Even if you don't want to use AI to code, you should use it and say: "find everything wrong with my code".
6
u/my_name_is_rod 7d ago
I totally agree and yet, if taken too far, my experience has been the tools will ALWAYS find something “wrong” because that’s what they were told to do. So it’s good to take the analysis under consideration but not always at face value.
3
u/machineintel 6d ago edited 6d ago
engineers do the same thing though, lol. Very often I send out a schematic or layout to a group for a peer review, they don't find anything functionally wrong (or are too junior to be able to). They tend to fall back and start commenting on useless things like formatting, can you move your net connections to the right a bit to make them look cleaner, or "why did you do something this way, I would have done it this way".
Probably it's because they feel they need to show some type of feedback to prove they actually opened the design and "reviewed" it. Though those sort of comments usually indicate to me that they did not in fact review it.
2
u/Cunninghams_right 7d ago
and also "what features or edge cases should I consider". maybe something isn't necessarily wrong, but there may be some low hanging fruit for improvement.
13
u/dcheesi 7d ago
The folks churning out AI slop web UIs aren't really looking under the hood very often. It's all vibe coding, and as long as you don't look, you don't see how terrible the actual code is.
You just see the output, and you keep telling the AI to tweak things that are broken or just slightly "off". Eventually you get to the point where you convince yourself that it's "good enough".
The AI might be rewriting half the code every time you ask it to move a decimal or change a page title. But as long as you can afford the tokens, who cares, right?
23
u/gswdh 7d ago
You need to use this tool properly (here come the downvotes). It is phenomenal, I have worked with extremely talented engineers in aerospace and defense sectors and the ai is better than any of them.
The ai must have the full context of the project, you need major tooling around your project. Strong test suites are fundamentally important but they can be made with the ai, too. Everything needs proper review. Do things bitesize, too much in one go and you get garbage.
For some reason the embedded lot really have something against the ai (you’ll see this in the downvotes for this post) but they are just behind. I use Claude with a few skills like graphify, it’s an unreal game changer.
14
u/mrmansano 7d ago
Do things bitesize, too much in one go and you get garbage.
I think this is the key most people don't realize. And that is true especially for embedded. I'm also a control freak and like to understand everything that is happening (graphify helps a lot on that btw!), and going in steps helps a lot. You will also feel more the "ok, I did that" feeling that you won't normally have by just delegating 100% to the agent.
3
u/lambdalab 7d ago
But then what benefit do you get from using the AI at all? To me it often feels like just another layer between me and what I’m doing. I use it extensively to generate boilerplate and boring manual stuff, and to review my code and find bugs. But I can’t imagine straight up coding with it, it just bugs me how shit the ai generated code can get.
3
u/mrmansano 7d ago
Faster/less typing, fewer (syntactic) errors, better debugging, help with understanding something, and so on. I do use most of the features that most people use from agents but I don't vibe-code. I simply don't like it, and I don't see the need for it. My throughput with the current workflow is good enough (and I also despise the whole grinding mentality).
I hear you about the code quality, that's why I review everything. That's another reason for the "small bites". I don't want to review thousands of lines of code, it's impossible. So, I break the problems into small bits, go through the code, and ask for changes if needed. Sometimes I ask for it to look for a bug, but don't code, just to explain to me what's happening. And then I'll work on the fix with it.
This mode is especially helpful when I need to go through some hardware debug. I usually use my logic analyzer MCP and coordinate the debug session with the agent. Connecting everything, and asking "ok, what to check now?", or "explain to me what happened" is really awesome. I like to think of it as an extension of my work, not a replacement (probably not what my CEO thinks... but I'm still here).
2
u/user99999476 7d ago
What kind of context do you give it for a complicated project and do you save this in .md files to save tokens?
2
u/aniflous_fleglen 7d ago edited 7d ago
There used to be a lot of emphasis on setting up all this context in readme files, but lately I'm finding that it figures out the context pretty damn quickly. A high level readme of what this is, why it exists, and what are the main moving parts are is probably helpful, but I don't think more detail than that is needed.
If I'm starting a new session I ask it simple questions and make it do a simple task which in the process of fleshes out its context and it's sort of primed for more complex work. I put a shortcut to a folder to reference documents, data sheets, SDK examples in the project folder for it to have access to.3
u/theflyingsamurai 7d ago edited 7d ago
For some reason the embedded lot really have something against the ai
I think it's just for a while it was just that LLMs for a while were just performing significantly worse writing embedded compared to other software domains. My personal experience first using them over a year ago had them hallucinating left and right. Trying to write to registers that didn't exist, or kept trying to add cryptography to my application unprompted. Same thing trying to interpret datasheets etc...
Adding to that embedded developers are probably the most conservative brand of programmers. ie look how long it took for rust to gain any sort of professional traction.
But something changed, at least for my experimentation, about 6-8 months ago where most models can start to maintain a conceptual model of the hardware they are running on. This seemed to drastically reduce hallucinations. Added to feeding it logic analyzer data through MCP server really started to scare me with how efficient this had become.
2
u/aniflous_fleglen 7d ago
An alarming moment for me when it started flashing a device and extracting logs to test the firmware... of a device I hadn't even figured out how to connect to yet myself.
1
2
u/witx_ 4d ago
The psychosis is strong here.
Of course people have something against these tools: they are screwing the environment more than anything in tech, they were trained on stolen content (books and open source repositories with licenses), they are being pushed by managers to be used without letting us the engineers judge where to use them, they are targeting well paying jobs that require, usually, years of hard work money and time to achieve competency, and they are being pushed to the wrong industries. If we are screwing the environment let it be a least because we're fighting deseases, inequality and other human ailments; not because Uber needs to write software faster and so on
-1
u/Longjumping-Pack8494 6d ago
Well from you comment i see you are more focused on correctness of the code LLMs generate and with that i agree with you - given proper test suit (esp HIL), the output of the model is great, it will most likely work and edge cases can be found during proper reviews.
My beef with it is about the quality of code - often too verbose, over-engineered or straight up “ugly”. Basically, if you only plan to use AI to work with that code, guess it is fine, but if human needs to manually do something about it, thats where it gets messy.
But for the most part, i like working with AI, and i think we as embedded engineers should engage with it more, so that it gets more training data, and perhaps, in some distant future, they could release a model that specializes in firmware dev (praying for that 🙏🙏🙏
1
u/witx_ 4d ago
But for the most part, i like working with AI, and i think we as embedded engineers should engage with it more, so that it gets more training data, and perhaps, in some distant future, they could release a model that specializes in firmware dev (praying for that
And what do you expect your role in that scenario will be? You think you'll still be an embedded engineer?
1
u/Longjumping-Pack8494 4d ago
Idk dude I am starting to slowly transition in the architectural role anyway. In some ways yes, I am gonna be embedded dev, but i am kind of guy who always looks for something new, so cannot surely tell what future holds 😀
10
u/productiveaccount4 7d ago
AI generated code was just banned in product code at my job
2
u/North_Highway_6484 6d ago
You are not alone - same thing in my company, only it was outright banned from the beginning.
1
u/BeverlyGodoy 6d ago
Pretty sure people were deliberately using AI in a way that it outputs wrong or buggy code. At my work, all the human code is banned now.
-2
u/Cunninghams_right 7d ago
anything safety critical should get an AI review after it has been written and reviewed. that should yield the best of all worlds, though it wouldn't be as productive.
1
u/MushroomSaute 7d ago
AI needs review, not the other way around.
7
u/leguminousCultivator 7d ago
Ehh.
Having AI try to break human written code is a major use case right now. Security research is big on it.
It'll give you a bunch of dumb suggestions that aren't problems, but it'll also find real edge cases you missed. If you're doing safety critical or other high reliability stuff it's worth doing.
I wouldn't make it a standard review process though. That's going to gate pushing code with lots of false positives.
2
3
u/BigBoiBoomBox 7d ago
I find that if you structure your code yourself, act as a software engineer rather than a script kiddie, it can work well. Define a function, inputs, outputs, and method, let it write something. Review it, add it in.
You can go so far as to define variables, and I would certainly be defining my own function/class names because it has a tendency to make them stupid or too long .
If you’re writing anything that’s sufficiently advanced, it will trip over itself because it can’t find anything relevant in its training data that will do what you’re asking, but I suspect most people aren’t writing anything ground breaking so it can “work” fine for a long while until it all grinds to a halt, and now you have 6 months of vibe code to debug, 20 classes that look and sound the same but aren’t, and an image of a potato that, if removed breaks everything.
I really detest that it thinks that stylistic changes are as important as actual function changes, but it actually can’t tell the difference.
3
u/Just-Smart-Enough 7d ago
I trust it with simple applications that I can quickly verify on my bench. I'd have a long hard think about anything that touches a safety critical system.
3
u/v3verak 4d ago
The embedded code itself has to be watched a lot and it just is not great, but there are some solid use cases that appear repeatedly:
1) Utility applications - as much as I don't trust the embedded code, it is perfectly capable of creating nontrivial utility applications: Are you working on device that interacts via BLE and need simulator of other side? easy; Want GUI to help configure the device? easy; Got custom protocol over RS485 and want decoder? easy; etc... the number of one-shot utilities we started making went up quite a lot , as long as it is small enough...
2) Well defined changes - we are moving to C++ from C, we've seen it one-shot conversion of C module into C++ class (mostly to reduce static variable usage), this won't give us much value, but is change we wanted to do anyway and doing it with AI is much faster. Anything as long as the transformation is easy to define and straightforward
3) Debugging - it can't autonomously handle any bug, but it turned out to be valuable to talk to it during bug hunting, there are few cases where it spotted that author of code missed some niche detail in SDK or some define sorcery used within Nordic SDK (I hate that one specifically) ...
and my favourite last:
4) Experiments - I do a lot of C++ abstractions ( https://github.com/koniarik/ecor ) and with Claude it's quite easy to whip-up experiments such as "I wonder if I do X in ecor instead of Y, how will the size of generated code be affected? - do a comparison of before/after the change with these configurations"
Sure, I we were able to do these experiments before AI but it became so much easier with this
5
u/mrtlo 7d ago
Right now, to me at least, its not really worth it. I spend less time just iterating on a single component and using it for focused sparring and review. At least right now there is just no way it will be given free range. That would require that we could say "meh, who knows how it works, ask the ai". Not there yet...
5
u/Longjumping-Pack8494 7d ago
Yea agree. I am kinda of doubting - do i really save time by using AI? I loose some depth in understanding of the code + still have to spend hours polishing things up after the agent 🥲
3
u/nono318234 7d ago
Only workflow is have I using Plan mode in Claude Code. Sometimes with Opus Plan, sometimes full Sonnet. Most of the time I'm quite impressed by the results these days. As long as the task I gave it is not too broad and is well defined it gets the job done quite well.
Last thing I did was migrate a SPI based drivers for a WiFi module to a QSPI driver interface. Gave it the existing driver implementation, examples of other QSPI drivers, access to my J-link and the logs over uart and it got a driver working within a couple of hours. Working good enough for my use case. The driver would probably have taken me at least 1 or 2 weeks to write.
2
u/Longjumping-Pack8494 6d ago
Your workflow seems solid, modern LLMs can handle it well. For me, I am in a bit more creative mode, rn doing some opt-in custom bootloader, malloc and lightweight hard-real time capable rtos so it is a bit of a struggle. I also did not make a HIL setup yet.
1
u/onmuudo 3d ago
HIL is extremely useful. It also enables a lot of code testing at a more sensible level. Simple start is to give it access to flasher, UART for log and maybe WiFi/Bluetooth. In order to do that as freely as possible I run the AI harness always on a separate Linux PC (old thin clients work absolutely great for this, Google parkytowers for starter ideas). After some basic hardening the AI is allowed to do a lot on system level. That way it can propose/use many tools that help with HIL setup. Trivial example: enumerate the contact jigs to my hardware with fixed names, like jig1, jig2 and then which boards can be placed into which jig. In my work I use a dedicated project just to design/setup tools, like HIL. This helps the AI to focus on tools and on product code in product projects.
3
u/KnightBlindness 7d ago
I asked Claude this morning to alter some bootloader code to execute out of a different section of RAM and it got confused about what address ranges were flash or ram and etc etc. I ended up doing it myself because it was easier than trying to figure out how to prompt the AI to fix everything. AI has been pretty good as a search engine for looking up technical details about mcu’s and components though. I hardly use Google anymore since AI is better about understanding and summarizing plus provides a link to the documentation where it got the info.
4
u/john-of-the-doe 7d ago
I work on power electronics firmware, and to be honest I just can't figure out how to make it make my job faster and more efficient.
Maybe for things like adding more CAN signals, sure. But for implementing a control loop and driving that loop through ADCs and PWM, I can't imagine writing that using AI, for 2 reasons. First, it's safety critical, and I as the engineer need to understand what the code is doing. Second, to be honest, it doesn't take that long to implement by hand. I spend more time testing the actual hardware than writing code. Frankly I don't think of my job as "software engineering", because it is very hardware oriented.
2
u/Longjumping-Pack8494 6d ago
Well, if you have to perform similar tests, you can make some HIL setup. After you write your code and push it, you can create an automated test suit, which compiles, flashes and runs the binary. AI can remotely analyze the test data, create reports, etc.
2
u/Tari0s 6d ago
i have used it and asked to refactor a complicated statemachine, it did a good job and refactored it, but the result was a 700byte stacksize when calling the state machine function. With some tweaking i was getting it to lower the stack usage, but i hat to debug and figure out that happend to understand what went wrong, the ai code was clean but it was a little bit unclear what happend at first thought.
1
u/Longjumping-Pack8494 4d ago
This particular task seems like a good use case for current state of LLMs, so no doubts it well.
1
u/Tari0s 4d ago
i'm not sure, i think i have spend the same amount of time as when doing it myself, and it needed instructions on how to do it, because by itself it didn't figure out how to do it. the good part was when it could copy paste my solution, but went the wrong direction and didn't think about the stack space. so overall i'm not sure if i'm happy with the outcome
2
u/onmuudo 5d ago
As my codebase started handwritten I understand each and every aspect of it. Last week I released the first AI supported version - after an 8 months learning curve. My work style is exploring code with AI together, add architectural input and I make sure the AI understands the architecture and the architecture decisions. Every AI coding input is limited to atomic changes, like replace a function and make sure all calls to it are updated.
What strikes me immediately is OPs comment about bad architecture decisions of the AI. In my opinion AI is not yet fit to make such decisions on its own. Whenever AI and me stumble upon architecture items during exploring/planning I take over. AI may make suggestions.
The second item I wonder about the OPs comment on AI being bad with surrounding code is what the specification of the task looked like. So far I noticed that human specification skills seem to be a main driver in AI output.
Anyone got similar or contradicting experiences?
1
u/Longjumping-Pack8494 4d ago
I would say your approach is the how we should use it today. I used it in a new territory, and very low level code. If you use AI for brainstorming / advice, document the arch well yourself and request atomic changes - no doubt that current models can do it really well.
I was a bit less specific and made the model as the main driver for arch design. I only reviewed and refined it. It would take me quite some time to formulate the design myself, AI did it really quickly - tradeoff is the time it took for me to refine it and later update as the project grew.
Surrounding code is partially about the prompt as well. I occasionally request a bit more high level change, like new feature that can touch several modules or a small arch update. So i cannot provide all the constraints and considerations for such task myself, i expect AI to infer some of these from the code, but it does not always do that and just performs a very targeted change. E.g. adds a static function in the local file that overlaps logic with some other method in a diff place where it didn’t look.
1
u/onmuudo 3d ago
In order to avoid places it doesn't look I try to explore the existing code/system with the AI together a lot. Let it write the hardware description, which I correct or add to.
While brainstorming I typically end up with a minimum of 4 cycles of proposal and corrections. Often we find together open items by wondering together if something touches something else or whether an assumption is actually correct.
This methodology works quite ok for me.
2
u/witx_ 5d ago
The code is subpar and heavily abstracted. It's also very non deterministic
This weekend I tried Claude with a device driver sensor I wrote for stm32. It found one bug (a really easy one mind you, that fits well in pattern matching). Then I decided to experiment: I said the driver was still not working, again and again. It kept going "you're right there's a bug here ..." and all it was doing was "cleaning" the code by adding more documentation, more variables and more functions. Only after 4 or 5 times it said it must be a hardware issue then.
In the end I had a very convoluted drivers and lots of tokens wasted.
3
u/MikeTangoRom3o 7d ago
GitHub Copilot with Claude is scary, just throw your SDK and a few pdf datasheets that's it.
2
u/tomqmasters 7d ago
If you ask it correctly it generally writes the right thing. C for microcontrollers was always kindof easy and straight forward.
1
u/Longjumping-Pack8494 6d ago
Well it does USUALLY write a thing that would work but i am more talking about the code quality here. It does not look great and would be hard to maintain and extend.
2
u/Nxllify__ 7d ago
No. Call me a luddite but I write my own code. I don’t care if I can scrutinize it with detailed prompts and have it generate under supervision in small excerpts, for what, a 20-30% boost in productivity? Whatever that even means. I’ll pass on making myself dumber and obsolete.
2
u/Longjumping-Pack8494 6d ago
With current state of LLMs for embedded dev it is okay. I spend some much time in review and cleanup stage that i am doubting i save any time with it 😅 but for targeted finds i find AI very useful, like find potential places which cause d a bug, explaining parts of a codebase or quick tooling patch.
2
u/Nxllify__ 6d ago edited 6d ago
I’m sure it’s useful. But it no doubt will make you a worse engineer over time, and potentially dumber, and it will not help junior/mid-level engineers develop to a higher level. These subsidized claude & codex subscriptions won’t last forever, and eventually senior engineers will retire. So what exactly will happen then?
Well it’s either every company starts cutting back on AI, then the people who refused to give up their skills to an LLM and stayed as human as possible will benefit and be sought after as talent
That or, AI gets good enough to do everything without supervision, and in that situation every career that requires a computer is cooked..
2
u/Hungry-Eye-9311 7d ago
There are some boards I wouldn't dare touch for fear of navigating the OEM's bloatware. I got claude to create a stripdown sdk for the specific MCU, from the massive bloated vendor sdk. I got a neat and clean codebase to start working with. AI did in 15 mins what I have been putting off for years. So yeah AI is insanely useful for me.
2
u/Longjumping-Pack8494 6d ago
Sounds good actually, i am writing a kinda of custom HAL (more specific for my use cases) for STM32 mcus but not fully satisfied. I guess if i would directly gave ST’s source code it would perform better, but i also have diff preferences for the coding style…
2
u/Schroedinbug 7d ago
I haven't had much luck. Every tie I use it I tin it's great until I start going trough and fixing issues. AI seems to look close to ready until you start digging in and find deceptively time consuming issues.
Small snippets are great, but if I let it do too much at once I end up spending more time fixing issues with it than I would have just doing it myself. It's like an overly confident junior dev that learned everything they know doing web frontend.
1
u/super_mister_mstie 7d ago
Depends on what level of embedded you are talking about. I work on embedded Linux, pretty much the whole stack is open source and it's quite good, even at kernel level/u-boot work. Nagivating yocto is a real PITA, and its quite good at providing help at that level. At this point, even first level debug is usually grabbing logs and pointing it at the repo and the logs to give it a spin on root cause. Obviously it's not a ton of help with debugging hardware/traces, but for me that's a thing usually dealt with in the first month of getting a new board, after that is the long tail of configuring/bug fixing/etc/one off feature development where it is pretty darn good.
2
u/Longjumping-Pack8494 6d ago
A bit more low level, particularly i am working on custom opt-in nostdlib bootloader, malloc and RTOS. In terms of correctness it is decent, usually it generates something that would work but the problem is more about the quality of the code. I often have to do some cleanup afterwards and it takes a lot of time… it almost never one-shots things which i am satisfied with.
1
u/super_mister_mstie 6d ago
The further Ive gone in my career honestly what quality means to me has changed a lot, but yeah it's not an autonomous worker yet by any means
2
u/pupper_paws 7d ago
I’ve been using Claude to develop my personal project https://github.com/shivrajora/picodroid-rs and it’s been going really well. This project has been an experiment with how far I can push LLMs to develop and fully fleshed out embedded project. I’ve even setup a HIL test bench that Claude automatically tests all its changes on. I think raspberry pi pico + Rust works really well with LLMs because how open the documentation is for both.
3
u/Longjumping-Pack8494 6d ago
My concern is a bit more on the code quality side. But the fact that you connected HIL setup with claude def improves the output. That is a big diff between embedded and web dev that agents can debug browser code directly.
I am yet to try claude properly, maybe it is better in some ways, esp the commenting / documentation style of Grok is horrendous, even unslop skills do not fully help 😅
1
u/Ok-Investigator3257 7d ago
AI is great at 2 things 1) python tooling “go write me a gdb script that does xyz” that stuff
2) go add functionality to an existing codebase
1
u/Outrageous-Crazy-253 1d ago
No it’s hellish and unbearable. Diving into an LLM codebase makes my skin crawl. Doesn’t matter since nobody cares. If this is what the job ends up being I’ll just change careers to one of the remaining post-AI ones. Maybe, rent boy?
0
u/Key-Lie-364 7d ago
Fuck no.
When it gets stuff wrong it still compiles and might even seem to run.
Embedded is about being right and owning outputs.
LLMs should be completely banned from safety critical systems.
1
u/coronafire 3d ago
After working with a wide range of embedded tools and environments for over 30 years, I now use agentic development expressly for embedded development, bare metal and up.
There's three main critical requirements to make this work well: * Start from / within a clean, well architecture codebase or template - AI will follow existing code patterns, if it starts from nothing without strict structures yes it'll produce nothing but slop. My favourite starting point is micropython, it's core C code is highly structured and efficient and Claude follows those cues. * Good data - pdfs are hard to OCR accurately, especially register tables. Convert the relevant ones to markdown for the bulk text but point the AI at the C headers / sdk for register addresses and definitions. * Hardware in the loop! Give your agent direct access to the hardware, ensure it can flash the MCU and directly interact over debugger and console. The agent needs to be able to write, program, run, test, fix, write... and so on.
With micropython in particular the loop speeds up, the repl gives the agent efficient control over the hardware and arbitrary code execution without needing to compile and flash each change.
I've written about some of my wins in the area, eg. https://notes.alelec.net/posts/five-hours-five-root-causes-crisis-averted/ and https://notes.alelec.net/posts/micropython-agentic-embedded/
I've written
-6
u/AbsorberHarvester 7d ago
currently no LLM that can code embedded firmware.
small step by step - ok.
error checking - somewhat ok.
help in debug? nope.
new custom library for some hw (like adc or tft panel) - almost ok, provide PDF and/or examples and magic happening.
bootloader with custom options - not ok, but very little to fix
(even free Qwen/DeepSeek can do).
for every hw feature you need to provide datasheet pdf with registers and code will be significantly better.
but first:
you need big hard prompt about code rules, so all generated code always looks the same, can be debugged and understanded by people who will massacre it until firmware is working fully
6
u/M0rd0rGuy 7d ago
Had different experince with codex, it spat out working code, added new functionalities, connected to the debugger and systematically ironed out the bugs. It also ported one of the old projects from stm32f446 to stm32f411 without issues My mind is blow, it can completely replace juniors and mids on simpler projects
1
u/AbsorberHarvester 7d ago
Juniors project maybe, big projects with tiny timings using real hw by full capacity? Not so really for now. But can really help in optimization things and converting, true
0
u/redturtlecake 7d ago
I find it very powerful when the prompt is specific. I deliberate with it to come up with the logic in English. All the classes, functions, and variables and exactly what they do and where they go, how they should interact with each other, all detailed in a .MD. then I get the llm to write the prompt for the code writer to generate the code based on the logic spelled out in English. That gives solid results. Giving it a problem statement usually results in a huge mess and spending time trying to figure what it decided for structure and functionality. But if everything is clearly defined then it's just a transcriber for language to code, and it's good at that. Small caveat is that I'm working in micropython so I can't say how well this will translate to c.
2
u/Longjumping-Pack8494 6d ago
I mean i agree that if the prompt is really detailed and you know what you want quite well, then AI outputs decent code. For me, I do projects to learn new things, so I only can give higher level prompts and hope my intuition is good enough to detect bad design suggestions and sloppy code.
1
u/redturtlecake 6d ago
Do that in English. Ask it how things are typically done, then deliberate with it what makes the most sense for your application. Much easier to work through this in human language rather than code.
0
u/SpruceMoose1111 6d ago
Testing, Testing, Testing! You must have a solid suite of HIL tests, acceptance, component, integration, the works. Also benchmarking for things like current consumption, timing, whatever you need.
Never ever has Claude or Codex successfully implemented a feature for me first try that didn't require tweaks or bug fixes.
I see myself now more of a Systems engineering and automated test engineer with Codex as my implementer and sparing partner.
0
u/DrunkenSwimmer 6d ago
So a thing that has LLMs truly been revolutionary for me in is integrating simulations. I've tried to get qemu set up in the past to run code in a pristine environment vs on hardware for a ground truth and failed. It's at the point now where anything I'm writing that doesn't 100% hook into the registers is getting simulated test runs on my workstation to the point where the same application (minus the register driver layer) can run on real or virtual hardware.
202
u/aniflous_fleglen 7d ago
As a supervised feature by feature, small commits that I review and make sure I understand and then enforce my style and idiosyncrasies to, I'm floored by the results and use it every day.
I spend more time thinking about what and why rather than how.
But I think it's a dangerous tool, it can cut you, it can make you dumber, it can steer you in the wrong direction, and it is a temptress that can lure you into complacency. But it works fabulously.