Hi Antal!
In short: The data comes out of CubeMX, which contains a bunch of XML files.
These are transformed, cross-referenced and filtered to generate these device files.
https://github.com/modm-io/modm-devices/tree/develop/devices/stm32
This is awesome, I'll try to use these when I get to implementing
something. I assumed that the register data is also extracted from the
SVDs (or some other source) and all data merged together, but now I
realize that's not needed for C++, since you can just use the header
files.
The advantage of the CMSIS header files over the SVD files is that everyone actually uses them to compile code.
The SVD files originally were only for the Keil IDE debugger to assign meaning to IO memory addresses.
They therefore aren't required to be completely accurate, which is a problem.
Yeah, it wasn't my best talk, I'm not practiced enough to handle such a complex topic.
I'm currently writing a very long blog post about modm, going into all the details of it.
I've spent the last 4 years looking at this data, if it's not in the above device tree data already, it is _not_ trivial to add. An example is the clock tree data, which exists in the raw data, but it's lacking critical data, which again I'd have to manually add. Ultimately the CubeMX data is incomplete and sometimes just plain wrong.
There's an example in the slides that shows automatic clock
configuration (slide 50). Is that manually written for that specific
target, or are clock trees available for a subset of the devices?
That's based on this proof-of-concept implementation:
The CubeMX data does contain real clock graphs, which are used as the data model behind the Clock Configuration tab in CubeMX, however they didn't contain the _full_ clock graph.
So I added it manually for the F100 and designed an experimental API. But I didn't find a good API for it in the end.
A better way would be to formulate your personal experiences as executable assumption checkers, and run them over the raw data.
This is actually what I did in modm in the GPIO driver, because the assumptions I made in xpcc regarding GPIO AF were wrong.
In fact they were _so_ wrong that our assumption check failed on the majority of STM32 devices and we had to rewrite the API from scratch.
https://image.slidesharecdn.com/niklashauser-170228153235/95/datadriven-hal-generation-47-1024.jpg
That's a nice approach. Is this fixed in modm?
Yes, see this here:
About the robot car project, I convinced my teammate to use xpcc (he
only ever used ST's HAL before, and only used C), and he really liked
how easy it is to do mostly anything in xpcc, and we used some of the
drivers too, so it was awesome. (One of the factors for choosing it
was that there's a driver for the VL53L0X sensor, which we used in our
car). We actually finished 1st place in one of the categories, and
xpcc helped a lot in that, so thanks! :)
Thanks, that's always great to hear! And congratulations!
(I just did a count, we have ~50 functioning device drivers, holy cow!).
Cheers,
Niklas
