Live Q&A - Building the Future of HAL: Leveraging AI and Deterministic Code Generation
---Nice to learn that AI is useful for documentation purposes! Does it need retraining when there are errata?---
Never mind, just scrolled down and saw that the question was already answered: "We don’t currently report on errata automatically, but that’s a great suggestion—we’ll definitely look into it!"
Looks nice, if not for the generated code, it looks as if it could give a very improved way of reading the reference manuals.
I was thinking the same.
Maybe they could create a web tool where you could search for parts that meet needs like "2 uarts, 1 I2C, 3 SPI at the same time". It's sometimes hard to make sure you get all peripherals you need without them conflicting on pins or resources.
This session was a great introduction. How well would the code perform on coverity or other static analysis tools?
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?
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.
Good work! Very impressive platform.