Home > On-Demand Archives > Theatre Talks >
Building the Future of HAL: Leveraging AI and Deterministic Code Generation
Michael Lazarenko - embedd.it - Watch Now - EOC 2025 - Duration: 30:33
Low-level software remains one of the biggest bottlenecks in electronics development. Every hardware change—whether due to supply issues, new functionality, or shifting requirements—engineering teams face weeks or months of rework just to get the hardware usable again. And as devices become more complex and development cycles continue to shorten, this problem is only getting worse.
The hardware abstraction layer (HAL) is essential to manage this complexity. It separates hardware-specific behavior from application logic, allowing teams to swap components and scale across platforms. But today, HALs are still built mostly by hand—slow, brittle, and hard to validate.
In this talk, I’ll walk through how we’re building a different approach:
- Using AI not to generate code directly, but to retrieve, interpret, and stabilize hardware data
- Using structured generation to produce deterministic, traceable, and certifiable low-level software
- Combining these methods to support a flexible, repeatable HAL generation process that works even in functional safety environments
I’ll cover:
- Why HAL development is a growing problem
- How we use structured models and deterministic rules for code generation
- What testing and documentation look like in our system
- What we’ve already built and what’s coming next
I find the topic and the tool you presented very interesting. Accelerating the development process is becoming increasingly important, and with the use of AI, we can make rapid progress. However, what you’ve proposed with this tool is incredible—it’s like jumping straight to the finish line. One question that remains for me is how this applies to cases involving less advanced technologies or situations where the documentation is not very specific or clear—how does the tool extract valuable data in those scenarios? Thank you, and excellent contribution.
How to tweak your generated driver?
Example: I have a UART, that has a stupid design, it set a flag (bit) when it detects errors on RX, in order to clear those flags, I have to trigger a function in the UART that not only clears those flags but resets the whole UART, including the TX part. this results in garbled data on TX, if sending is in progress when i clear those flags.
I had to tweak the UART driver so it will look into not only the TX state, but also the SW buffer wit TX data, to find a gap where I can reset the UART. (Yes. I did say stupid HW design).
How would you go on doing that with your tool?
Looks nice, if not for the generated code, it looks as if it could give a very improved way of reading the reference manuals.
This is a game changer! The cost seems quite reasonable too. I can see it would also reduce bugs in writing the drivers by hand too. I presume the configuration can be in GitHub, so it's easy to review any changes that have been made that deviate from the datasheet? Does it report on errata automatically and offer to update to the latest issue?
Hi Simon,
Thanks a lot! At the moment, configuration is done via our UI, but we’re working on enabling everything to run through the user’s CI/CD pipeline.
We don’t currently report on errata automatically, but that’s a great suggestion—we’ll definitely look into it!
Amazing! Am I to understand this can create drivers and or a BSP?
Hi! Thanks for the kind feedback.
We’re currently generating drivers for peripherals and actively working on MCU support, with plans to gradually roll out the capability to generate a full BSP.
Hello, if sensor needs to be connected to the chosen board, how do I enter the information which pins it is connected to?
Hi Zilvinas,
The pinout of the selected board corresponds to the default peripheral layout. For SPI peripherals, the default NSS pin will be used. For boards with multiple I2C controllers, the system will scan each controller and look for the address of the specific part you’re testing.
For boards that do not have dedicated pins for the specified interfaces, you'll need to refer to Zephyr’s support page for the board. It will contain the selected pinout for each peripheral controller.
Michael, thanks for your presentation. It was the first talk I watched at this year's EOC and it was impressive - in fact, I couldn't believe it works so well and easy. I'm looking forward to the Zoom discussion. I guess your VSC extension also works with Cursor. Thank you!
/Thomas
Hi Thomas! Thanks a lot for the kind feedback! As always there are still many things to improve, but we are working hard on it :) Look forward to seeing you at the Q&A session.
This session was a great introduction. How well would the code perform on coverity or other static analysis tools?