STM32 crate organization?

[tones111]

I'm a bit confused after today's update. I was previously unaware that this crate had been published on crates.io. It's actually spread across several crates.io packages (stm32f0, stm32f1, etc), but I don't understand the advantage to splitting it up.

In PR #5 I have attempted to automate the crate code generation via a build.rs script which allows the use of any device-specific backend via the corresponding feature flag. The attempt mimmicks the existing architecture, but I discovered very late in the effort that specifying multiple device feature flags prevents the library from compiling. Thus the build.rs script is able to detect this condition and panic with a more helpful error message.

error: symbol DEVICE_PERIPHERALS is already defined
361729 | static mut DEVICE_PERIPHERALS: bool = false;

With that knowledge I'd like to modify the build script to not combine devices under one lib.rs (I think this would also alleviate the need to call sed which likely causes trouble for building on windows). I'm just starting to play in the embedded rust space so I'm unsure if there are plans to try and fix that limitation. Perhaps it could allow dependent projects to build separate binaries for multiple targets, but it feels like feature flags in the dependent project would be a better implementation.

So, I wanted to open up a discussion regarding the direction of the crate's organization. Is there a reason to prefer splitting the packages? Would consolidating under one package using the build.rs dynamic generation be welcomed? I suppose since the packages have already been published to crates.io there's no way to put the genie back in the bottle.

Thanks for your consideration.

[adamgreig]

The main reason for splitting it up is file size. The generated crates are gigantic and the file for every device would have to be downloaded by a user of any device. crates.io has a 10MB file limit which the combined crate blows right past. By putting them into separate families, it's both possible to upload to crates.io, and makes life nicer for users having to download. For applications targeting a single device this hopefully isn't too much of a problem anyway.

[tones111]

Ok, that makes more sense. And they were grouped by family to prevent having to publish each one independently. Being new to embedded rust I've found the number of crates out there and their varying levels in the stack (svd2rust device crates like this, board support crates, all the HAL definitions and implementations, higher level crates like rtfm, etc) to be bewildering. Many are similarly named and it's hard to tell their purpose at a glance. Given the option to alleviate proliferating more crates I would thing it would be preferable to consolidate where technically possible.

So, to the second part of my original question, how about consolidating? PR #5 solves the file size issue by delaying generation of file until build time (all of the stm32* directories can be removed along with the Makefile and most supporting script). This means the brunt of the download is the svd/vendor directory which weighs in at just under 5MB.

The other advantages are that it explicitly documents which version of svd2rust is used to generate the files. It also gets rid of the sed hacks. I would think it would be easier to manage a single stm32-rs crate then trying to publish for each family. And there's less confusion with those crates and their relation to this crate.

[adamgreig]

It's an interesting idea and might be a good direction forward. Thanks for your work on the build script already. It's quite a change so I want to have a play with the new build script and think about it a little.

• I'm a little cautious about impact to build times but it's probably not too bad and only happens once anyway
• It might make documentation generation even harder than it already is
• I like the idea of a single crate supporting every device
• Removing the sed hacks is also nice
• It's a shame someone recently used the stm32 crate name on crates.io otherwise that would be perfect! Perhaps stm32-rs but then you have the usual slightly gross extern crate stm32_rs thing.

Do you think the build process should patch the vendor svd files and then run svd2rust, rather than supplying patched svd files?

[tones111]

On my machine the crate build time is dominated by compilation, not the generation.

Looking at the stm32 crate it looks like the projects share similar end goals (consolidation of STM32 support). The implementation approach differs. Perhaps we could collaborate with @rqou instead of duplicating effort.

How to obtain and maintain the svd files is still an open question in my mind. Trying to become the canonical source of updated files is a large effort and requires some sort of feedback loop with the upstream suppliers. Fortunately it looks like https://github.com/posborne/cmsis-svd is already well established for this task. I've been unable to locate how/where you were obtain the svd's for this repo.

Tracking the modifications against the svd files is a reasonable approach if those findings can also be pushed upstream. Maybe issues should be filed against the posborne repo?

[adamgreig]

I think everything is at an early enough stage that it makes more sense to try out alternative approaches and see what works well, rather than trying to consolidate everything immediately. I know a few other people are also working on various ways to do good device support, with a whole range of different approaches to data structures and code gen, many not using svd2rust either. I'm open to collaboration of course though!

I considered the posborne/cmsis-svd repo when I set this up, but it had a real mix of outdated ST SVD files. ST had released zips per-family with more up to date and consistent files, some of which have now been incorporated into that repository, but many old ones remain. The ones in this repository come directly from ST; they used to have a single page with all of them but now you have to go to the page for any individual chip in a family and it links to that family's zip file. #1 was a recent PR that updated the zips to the latest versions from ST.

I would be surprised if ST were interested in receiving updates to their SVDs, but who knows.

[johnthagen]

It's a shame someone recently used the stm32 crate name on crates.io otherwise that would be perfect!

You could try to contact https://github.com/rqou/stm32-unified-crate and see if they are willing to collaborate. Seems like a shame to duplicate all of the effort.