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. >> I've held a talk about how we use these device files in modm at EmBO++17: >> https://www.slideshare.net/emBO_Conference/datadriven-hal-generation > > Interesting, thanks! I don't quite understand what the huge matrix of > devices with different colors mean though. 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: https://github.com/salkinium/save-the-clocktrees <https://github.com/salkinium/save-the-clocktrees> https://github.com/roboterclubaachen/xpcc/pull/39 <https://github.com/roboterclubaachen/xpcc/pull/39> 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: https://github.com/roboterclubaachen/xpcc/issues/178#issuecomment-306741413 <https://github.com/roboterclubaachen/xpcc/issues/178#issuecomment-306741413> > 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
_______________________________________________ xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de https://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
