Would using stm32f1 be a good idea for device access ?

[gbip]

Hello !
Do you think that using the stm32f1 crate would be a good idea for device access ?

It would allow use to use a patched svd file for a more ergonomic device register access 😄

[therealprof]

@gbip Check out https://github.com/stm32-rs/stm32f1xx-hal

[gbip]

We are working on a robot due in May for a competition, should we prefer using this crate or stm32f1xx-hal in term of features ?

[therealprof]

This one has more features (requiring unstable code) and is more experimental. stm32f1xx-hal is essentially the successor of this crate without experimental features but support for more models of that family plus the ability to use it from cargo.

I think @japaric wanted to put a deprecated flag on this crate.

I only did a single pass on the other stm32f1xx-hal crate to set everything up so it could certainly use a cleanup. Other than that I'd be interested in what you feel is missing.

[gbip]

I am working on a pwm input implementation and I'd like to put my implementation on the stm32f1xx-hal instead of this one, but I need to maintain compatibility with our current codebase.

We have some production code that is working using :

• GPIO
• USART
• Timers in PWM mode
• DMA read/write
• SPI

Do you think that we can switch crate ?

Thanks ! 😄

[therealprof]

DMA is currently not stable as far as I'm aware, but I'd love to be proven wrong. Other than that the crate should be fully compatible API wise.

[gbip]

Is it not stable because it does not compile on stable, or because the implementation might be wrong ?

[japaric]

The DMA API described in https://rust-embedded.github.io/embedonomicon/dma.html should compile on stable 1.33.0 (scheduled for 2019-02-28).

[gbip]

I just switched our two binaries to the new stm32f1xx crate and everything compiled fine, except that I had to copy the memory.x linker script from the stm32f1xx repo to my project.
Is this an intended behavior ?

Anyway, I will try to make a PR with the new pwm input feature.

[therealprof]

Yes, the memory.x should be part of your project. There's no one fits all and the one in the crate is only for compilation of the included examples.