Support for the STM32L0x0 subfamily #146

jglauche · 2021-02-25T13:39:07Z

I implemented L0x0 subfamily and got the examples compile (and verified that the blink example is working!)
#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: stm32-rs/stm32-rs#505

hannobraun

Thank you @jglauche! I've taken a look, and nothing looks out of the ordinary. Left two comments about things I'm not sure about (maybe someone else will know more).

I'm going to convert this PR to a draft, as it's still blocked on various things (as you note). Please mark it as ready to review once it's ready.

hannobraun · 2021-02-26T11:43:28Z

Cargo.toml

@@ -55,6 +55,7 @@ disable-linker-script = []

 # STM32L0 subfamilies
 # (Warning: Some peripherals, e.g. GPIO, don't follow this subfamily grouping.)
+stm32l0x0 = ["stm32l0/stm32l0x0"]


Is that enough, or do we need to add more features flags (thinking about the ones @dbrgn auto-generated from CubeMX).

probably yes. I only have a l0x0RBT to test against, which is a class 5. I keep finding more things to fix; basically it's similar to the features of L020 class 5 with a lot of stuff cut out.

hannobraun · 2021-02-26T11:50:25Z

src/dma.rs

@@ -324,14 +331,14 @@ macro_rules! impl_channel {
                    handle:  &mut Handle,
                    address: u32,
                ) {
-                    handle.dma.$chfield.par.write(|w| w.pa().bits(address));
+                    unsafe { handle.dma.$chfield.par.write(|w| w.pa().bits(address)); }


This confuses me. Wouldn't the bits method be unsafe for all targets? Why did it work in the first place?

jglauche

[see below]

jglauche · 2021-02-27T23:31:04Z

src/gpio.rs

@@ -469,7 +469,7 @@ macro_rules! gpio {
                    }

                    #[allow(dead_code)]
-                    pub(crate) fn set_alt_mode(&self, mode: AltMode) {
+                    pub fn set_alt_mode(&self, mode: AltMode) {


is there any reason not to make this public? I looked at other hal crates, they made this a private function, but referenced all the pin modes as function

I don't see a reason, but I'm not very familiar with that code. I also don't know why the #[allow(dead_code)] is here and on AltMode itself. Seems all very weird.

…ck in sleep mode

jglauche · 2021-03-12T22:01:42Z

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 · 2021-03-13T10:34:15Z

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 · 2021-03-13T12:16:26Z

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 · 2021-03-13T18:23:49Z

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 😄

jglauche · 2021-03-17T12:49:03Z

Quick update:

my PR to stm32-rs was merged, now integrating this RP blocks on them releasing their next version.
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"
since I know how to reliably reproduce this bug, I'm planning to integrate a workaround for it in the upcoming weeks.

Mstrodl · 2022-12-06T04:14:09Z

Any news?

jglauche · 2023-03-02T17:57:38Z

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

jglauche added 10 commits February 25, 2021 13:00

hack out features that don't exists in l0x0 variants

4ef5590

add l0x0 to Cargo.toml

fface70

fix tab

87cfaf1

fix tab

8105d90

fix tab

55fce3b

fix tab

d419425

add unsafe to dma writes for nightly rust

db94619

make pwm example work for l0x0

230f99c

fix SPI pin setup for l0x0

d2ca540

fix l0x0 support for serial when using io-STM32L051

67cc695

hannobraun reviewed Feb 26, 2021

View reviewed changes

hannobraun marked this pull request as draft February 26, 2021 11:53

jglauche added 2 commits February 26, 2021 13:19

l0x0 has serial dma feature

9325d5e

make set_alt_mode public

785197b

jglauche commented Feb 27, 2021

View reviewed changes

jglauche added 7 commits February 28, 2021 13:49

fix l0x0 i2c pin layout

da2b070

enable dma for i2c on l0x0

480c488

make rcc config fields public to make PLL setup with prescaler possible

2fec383

merge serial.rs with origin

9386d31

partially merge gpio and rcc from the F3 hal crate to enable gpio clo…

1ae9c7b

…ck in sleep mode

expose fields in serial struct to public

f6426c0

revert Cargo.toml

9ae6f98

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for the STM32L0x0 subfamily #146

Support for the STM32L0x0 subfamily #146

jglauche commented Feb 25, 2021

hannobraun left a comment

hannobraun Feb 26, 2021

jglauche Feb 26, 2021

hannobraun Feb 26, 2021

jglauche left a comment •

edited

Loading

jglauche Feb 27, 2021

hannobraun Mar 1, 2021

jglauche commented Mar 12, 2021

hannobraun commented Mar 13, 2021

jglauche commented Mar 13, 2021

hannobraun commented Mar 13, 2021

jglauche commented Mar 17, 2021

Mstrodl commented Dec 6, 2022

jglauche commented Mar 2, 2023

Support for the STM32L0x0 subfamily #146

Are you sure you want to change the base?

Support for the STM32L0x0 subfamily #146

Conversation

jglauche commented Feb 25, 2021

hannobraun left a comment

Choose a reason for hiding this comment

hannobraun Feb 26, 2021

Choose a reason for hiding this comment

jglauche Feb 26, 2021

Choose a reason for hiding this comment

hannobraun Feb 26, 2021

Choose a reason for hiding this comment

jglauche left a comment • edited Loading

Choose a reason for hiding this comment

jglauche Feb 27, 2021

Choose a reason for hiding this comment

hannobraun Mar 1, 2021

Choose a reason for hiding this comment

jglauche commented Mar 12, 2021

hannobraun commented Mar 13, 2021

jglauche commented Mar 13, 2021

hannobraun commented Mar 13, 2021

jglauche commented Mar 17, 2021

Mstrodl commented Dec 6, 2022

jglauche commented Mar 2, 2023

jglauche left a comment •

edited

Loading