Hi Niklas, Thanks for this extremely long answer, it is very interesting, sorry for taking so long to get back to you.
On 8. Feb 2018, at 01:52, Niklas Hauser <niklas.hau...@rwth-aachen.de> wrote: > Have you seen @japaric's post on that topic? > http://blog.japaric.io/brave-new-io Yes, I'm trying to follow new developments in embedded Rust, and especially @japaric, who is doing most of the work. As far as I know, only the low-level register access code is generated at the moment for Rust, with svd2rust (and that too seems to be less than optimal, for example a distinct type is generated for all of the GPIOs, even if they are completely the same), but not anything higher-level (the HAL for a few STM32 devices are written mostly by hand for a small range of devices if I understand correctly). > Unfortunately, SVD files don't contain information beyond the memory map and > even worse, the SVD files are often incorrect in some minor way. > Btw, so are the official CMSIS header files that ST ships. > https://github.com/modm-io/cmsis-header-stm32/commit/1ec448711db342deb4d4bf20b670166701a38f26#r27042841 I've noticed this too, and it's pretty annoying. > 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. > 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. > This is an insane amount of work, and I'm not willing to put in the hours for > this anymore than is absolutely necessary. > I fear that if I were to publish this generator and it were to become popular > (which the Rust community surrounding @japaric absolutely has the ability to > do), I'd be overwhelmed with support requests for all sorts of additional > data, regardless of how labor intensive it is to procure. I hope this will not happen at all / in a way that would make you uncomfortable :) > 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? > 2. There is a real risk of creating a pseudo-standard of assumptions from my > work, since there is no other STM32 data available elsewhere at the moment. > I've been following the Linux Device Tree community for a while now, > especially the discussion about the Device Tree Specification: > https://github.com/devicetree-org/devicetree-specification [...] I'm not familiar with this specification, but I can see your point. > 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? > 4. I recently quit my job at ARM working on mbed OS and uVisor because they > didn't allow any out-of-the-box thinking on embedded software designs, like > we do in xpcc/modm. I mean, they don't even generate their linker-/startup > scripts, which is absolutely TRIVIAL to do with even the most basic data. > It's insane how much unnecessary manual labor goes into porting/maintaining > mbed OS. > My takeaway was that with the entire IoT craze, nobody in this industry takes > the time to fix the foundational issues, like HAL design, tool support, > library support (don't get me started on Newlib). Most engineers I met can't > even point out any flaws in these, they are just so used to it. > I'm still downbeat and angry about that and I need time to gain some distance > from that experience. I'm sad to hear that, I hope you'll get over it and find something more enjoyable to work on :) > For now I recommend you use the device files as they are. You're not going to > be able to extract any more data from CubeMX without unreasonable effort. > I'll keep them updated with every quarterly release of modm. I'll reevaluate > my position if more projects start using that data and people are willing to > take up some of the maintenance effort like what has happened in xpcc. That > really is a joy to maintain, I feel like people care about this stuff :-) > Make sure to look at modm if you want to generate code/data/documentation > from this data, since it was designed for exactly that purpose. I'll see if I can come up with anything useful using this for Rust. Unfortunately(?) I just finished working on an embedded project (a robot car for a competition), so I think I'm not gonna work on embedded stuff too much, but let's hope. 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! :) On Fri, Feb 9, 2018 at 2:03 AM, Niklas Hauser <niklas.hau...@rwth-aachen.de> wrote: > I've had some discussions with my friends and as a result I've changed my > mind: I've published the generator as well as some docs to get you started. > https://github.com/modm-io/modm-devices Awesome, though I think I'll be fine with the generated files as a start. Thanks, Antal _______________________________________________ xpcc-dev mailing list xpcc-dev@lists.rwth-aachen.de https://mailman.rwth-aachen.de/mailman/listinfo/xpcc-dev
