Role of AI in Embedded Development: Solving the Data Problem
AI is transforming software development, but embedded systems are not benefiting at the same pace. The reason is not just model capability. It is the data.
Chip behaviour is still scattered across reference manuals, datasheets, errata, SDKs, application notes, and engineer experience. Registers may be partly machine-readable, but the most important layer, including sequences, dependencies, constraints, and silicon-specific behaviour, is not.
This talk argues that AI should not be used mainly to generate production drivers directly from PDFs. That path leads to hallucinated registers, missed initialization steps, and subtle hardware bugs. Instead, AI should help build the missing structured hardware data layer.
Once chip behaviour exists as vendor-neutral, machine-readable data, driver generation, BSP migration, tests, emulation, documentation, and compliance evidence become downstream transformations. AI can support rapid prototyping, while deterministic generators can produce reproducible, traceable output for safety-critical systems.
The future of AI in embedded is not just better code generation. It is better hardware data.
Do you have any tips for what developers can do in the interim to meaningfully use AI for code generation in the embedded space? Long term it makes sense to have a unified model, but in the short term, have you had any success with for data generation from manuals and data sheets?
Hi! I think at this point, if you're looking to leverage AI generation, the best thing is robust architecture definition, breaking up execution steps, and agentic HIL debugging. Have a look at Jacob's workshop, it's a very good review of best practices we've seen work in the field.
Thanks for the recommendation. I haven't had a chance to go through all the presentations yet, but will definitely check it out. Regarding my question, I don't think I phrased it properly, but my main question was if there are any short term solutions (prior to the industry adapting a unified format) for capturing information from existing manual and datasheets and feeding to the LLM.
Ah, got it, that's exactly what we do at Embedd.it. We've built an automated pipeline that processes existing documentation (datasheets, reference manuals, SVDs, XML, SDKs) into a unified device model, so no need to wait for industry-wide standardisation.
Hi Michael,
do you mind to share the slides, as promized. :-)
Thank you!
Michael
Hi Michael,
Apologies, uploaded before, but seems like there was a technical glitch and they didn't load properly.
Regards,
Michael
Thank you!
Can you make the slides available? Thanks.
Sure, I'll add them, thanks!
If I've understood correctly, you suggest encapsulating all the knowledge needed to work with hardware into JSON. Do I have that right? Do you think all the necessary knowledge can be categorised and stored this way, or will there always be something that just has to be said in prose?
Good question. For the layer I’m talking about, drivers and BSPs, the knowledge does end up in structured form eventually. It becomes code.
A driver is already a structured representation of how to use the hardware: register writes, ordering rules, dependencies, conditions, timing, error handling, and workarounds. So the issue is not that hardware knowledge can never be structured. It clearly can be, because every working SDK proves that.
The problem is where that structure appears in the process. Today, the source of truth is usually prose: reference manuals, datasheets, errata, and app notes. Engineers then reconstruct the operational model from that prose and encode it into target-specific driver or BSP code.
That reconstruction is repeated for every MCU family, every OS, every BSP layer, and every port. So we already have structure, but it appears too late, and it is locked into a specific implementation.
My argument is that the operational model should exist before the code: functions, sequences, dependencies, constraints, and errata in a target-neutral representation. Then code becomes one output of the model, rather than the first place where the model exists.
Some prose will always be useful for explanation and rationale. But the operational knowledge needed to build drivers should not have to be reconstructed from prose every time.
That's clear. Thank you.
fully agree. For AI to generate better embedded drivers, the key is not only better models, but better structured hardware data. Without machine-readable knowledge. AI will always risk producing code that looks correct but fails on real hardware.
I had a similar experience in the past weeks while working on an automotive switch driver. A lot of time was spent correcting or guiding the AI model’s understanding of the hardware context. It was still a great assistant, but it became very clear that if the hardware behavior and dependencies had been available as structured data, the task would have been much easier and more straightforward.
Great talk..... Structured hardware data is really the foundation for making AI much more useful in embedded development.