Upstream changes

[dbrgn]

Hi @HarkonenBade

Here are my changes from work on cube-parse over the last few weeks.

I am sorry that these are not multiple small focussed PRs, but it was incremental / explorative work so it would be quite an effort to split this.

Things this PR includes, summarized:

• Improved README with an introduction on how the CubeMX database is structured
• Improved error handling
• Get rid of compilation warnings
• Generate only a feature per GPIO group, not per MCU
• Use clap for argument parsing
• Set up CI
• Generate both pin mappings and feature list
• Add support for PAC dependencies in feature list (requires entries in FEATURE_DEPENDENCIES hash map)
• Bugfix: Include LPUART in serial pins

Some of this work has already landed in the stm32l0xx-hal:

• Introduce new Cargo features generated with cube-parse stm32l0xx-hal#82 (merged)
• Serial: Replace Pins trait with TxPin / RxPin stm32l0xx-hal#68 (proposed)
• Update I2C pin mappings based on STM32L0xx GPIO IP stm32l0xx-hal#87 (proposed)

By the way, it looks like those io-* groups correspond to the product categories.

The stm32l0xx HAL cannot yet use the pins! abstraction because the abstractions used are a bit different to the HAL you were targeting (less use of typestates when implementing traits). That's why I manually extracted the information from the generated output for now. However, I think in the long-term it would definitely make sense if STM32 HALs would use a universal pin mapping file generated from the STM32CubeMX database.

Thanks for getting things started, nice work!

[dbrgn]

Any news here? 🙂

[HarkonenBade]

Apologies for the extended inactivity, I've not really been touching the rust embedded world much these days. I'll try and have a quick review but as an important question, are there any changes to existing behaviour from the tweaks you have made? Mostly I'm concerned that I don't want any existing users workflows to break as part of accepting these changes.

[dbrgn]

I don't think so, but I'm not 100% sure to be honest.

I wonder if it might make sense to move this project to the stm32-rs organization for shared maintenance...

[HarkonenBade]

It seems that you had already been talking about this in the stm32f0-hal repo, and that's the only other one that I'm aware of even considering the use of this. So I think I'm principally happy to merge this and I'll bump the release version to 0.2.0 to indicate the notable changes.
Moving to the stm32 org might be worthwhile as I certainly don't have much time to work on this.

[dbrgn]

@adamgreig @hannobraun @arkorobotics what do you think about moving the project to stm32-rs? (I'm not sure if there are some politics involved as well.)

I'm happy to help with maintenance.

[adamgreig]

I don't have any objections to moving it into stm32-rs if @HarkonenBade is happy with that (hi Tom!), they're already in stm32-rs so should be able to do the move themselves. I can add @dbrgn as a maintainer after that. No politics that I'm aware of...

[HarkonenBade]

Ok, barring any immenant objections I'll do the merges and then move the repo over, probably tomorrow at this point?

[HarkonenBade]

Merge complete, I've tagged both the last existing commit as v0.1.0 and the new head of master as v0.2.0 along with bumping the cargo version. I've also initiated the transfer to stm32-rs. Thanks again @dbrgn for all your hard work!

[dbrgn]

Thanks, @HarkonenBade!