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

> 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.


xpcc-dev mailing list

Reply via email to