Support for the STM32L0x0 subfamily

[jglauche]

I implemented L0x0 subfamily and got the examples compile (and verified that the blink example is working!) https://github.com/stm32-rs/stm32l0xx-hal/issues/141

Please someone have a look at the unsafe brackets I had to add for my nightly rust in src/dma.rs .

For local testing, I had to replace stm32l0 dependency in Cargo.toml to stm32l0 = { path = "../stm32-rs/stm32l0" } after building the stm32-rs project. I didn't add this to the PR.

Requires my fork of https://github.com/jglauche/stm32-rs Waits on PR to merge: https://github.com/stm32-rs/stm32-rs/pull/505

[jglauche]

Some updates on this:

it looks like my PR to the stm32-rs library for the L0x0 SVD will be merged soon-ish.

On this HAL crate... there's a lot of work TBD

I tried merging the gpio.rs with an another crate to find out that I should have based it off another one (stm32f3xx-hal).

• I2c on the l0x0 wants AF6 open drain pins set with a pin mode of 0b10010
• In other HAL libraries, AF functions are stateful; I'd love to have the same here
• I tried setting my i2c clock and enable manually, I am still having issues with it and I am not fully sure why.
• while testing different clock configurations, the sanity checks in the i2c initialization are panicing on settings that STM32CubeMX would be happy with. I think that thing needs a lot of rework (and a way to manually set things)

I'm fighting bit with serial.rs too:

• using rtic in my project I first approached it by splitting RX an TX as late resources; then I needed to check serial.pending_event(). I needed to not split them and expose it with Serial, so I made them public. [any thoughts against?]
• pending_event does not clear the event, but there's no method to do it in serial. There should be!
• I'd like a way to handle CTS/DE pin handling built in

[hannobraun]

I haven't followed this closely, but a general note: It would make our (the maintainers) life MUCH easier, if you could submit as much as possible in as many self-contained pull requests as possible. Doesn't make sense to start now, as it is still blocked on your upstream PR, but I'm just saying, if this turns into one huge pull requests that changes everything, it will be hard to find the time to review it.

[jglauche]

I haven't followed this closely, but a general note: It would make our (the maintainers) life MUCH easier, if you could submit as much as possible in as many self-contained pull requests as possible. Doesn't make sense to start now, as it is still blocked on your upstream PR, but I'm just saying, if this turns into one huge pull requests that changes everything, it will be hard to find the time to review it.

I assumed as much, but I feel like I opened a can of worms here. The more I actually test the more things I find that don't work for a reason..

[hannobraun]

To be clear, improvements and fixes are definitely welcome. I'm just saying, I hope when they're ready they'll arrive in neat packages :smile:

[jglauche]

Quick update:

1. my PR to stm32-rs was merged, now integrating this RP blocks on them releasing their next version.
2. my I2C issue was caused by my test code causing a race condition at an eeprom write, resulting in an MCU bug described in the Errata as "new transfer cannot be launched if first part of the address is not acknowledged by the slave"
3. since I know how to reliably reproduce this bug, I'm planning to integrate a workaround for it in the upcoming weeks.

[Mstrodl]

Any news?

[jglauche]

Any news?

I haven't had the chance to keep my branch updated as my client that I was developing the l0x0 support to switched to l4 MCU