The future of this crate

[TeXitoi]

There are some questions about the future of this crate. Some questions:

• using stm32f1 crate as the device crate
• being generic on stm32f1xxxx chips
• modernizing and cleaning the crate.

Let's talk about all of that in this issue.

[burrbull]

I think it's better to create new stm32f1xx-hal or stm32f1-hal crate.

[TeXitoi]

My idea is:

• stm32f103xx is living as is in maintenance mode (feature PR accepted, but no refactor or API rewrite)
• stm32f1-hal is lanched in parallel

And the goal of stm32f1-hal:

• depends on stm32f1
• works on multiple stm32f1xx devices
• we introduce little by little the hal implementation by looking around for good ideas.

The problem is that I really can't do that alone:

• I'm (IMHO) a good rust developer, but a embedded newbie (touched my first MC in august 2018)
• I only have stm32f103, and don't plan to use other MC
• I only used stm32f103xx-hal crate, no others hal implementation
• I'm not interested in all the features of the hal. For the moment, I'm only interested in gpio, rtc, spi, i2c, pwm, timers.

Thus, I think we need a small community to launch this project with:

• non-embedded newbies
• users of a stm32f1 MC that is not stm32f103
• users of different rust hal crates
• dev interested in qei, dma, serial...

[therealprof]

stm32f1-hal is lanched in parallel

You mean like https://crates.io/crates/stm32f4xx-hal ? 😉

[TeXitoi]

yes

[therealprof]

Okay, while STM32F1 is not my main interest, I do have a lot of MCUs from that range (alone for the fact that every of the Nucleo and Discovery boards has an ST-Link based on the STM32F103) and I actually attempted to do the move to stm32f1 before due to me trying to build an IoT platform with the STM32F107.

So you can count me in for that stm32f1xx-hal plan.

Here's what I would like to propose:

• We create a new organisation as an umbrella for all STM32 related projects, I was thinking calling is stm32-rs but @adamgreig has dibs on it so I'd like him to be okay with that (and hopefully join in on the fun, too 😉)
• Invite all regular contributors to STM32 related crates to join this group
• I'd move all my STM32 related crates into this too, if the group agrees

Obviously there's a lot of stuff which needs to be done, we should definitely have bors and travis-ci set up for all of the crates (and currently mine and this one here are not governed at all).

[TeXitoi]

@thenewwazoo might be interested by this thread too.

[adamgreig]

I'm interested in this plan and have reserved the stm32-rs organisation on behalf of it, just to make sure it doesn't get taken before we decide what to do.

[therealprof]

@adamgreig That's great news.

[gbip]

I would also like to be a part of this ! I am still a student and I touched my first µc in in january 2018. I have some moderate Rust experience (I am using it regularly for 3 years).

I am making (with other student) a robot, and we have 2 µc :

• nucleo stm32f446
• blue/black pill (stm32f103 based)

But we can switch on whatever µc is best supported by Rust.

We are highly interested in serial communication and QEI, with Can communication being a bonus !

[RandomInsano]

I’m mostly a hobbiest but have been tinkering (very lightly) with micro controllers since 2009 with ATMega devices. I’m no stranger to reading data sheets and writing to registers but my Rust skills are mediocre.

I’d want to see USB and DMA in addition to those other features mentioned.

I have in my collection:

• STM32L100 Discovery
• STM32F3 Discovery
• STM32F1x (Blue and Black pills)

I don’t think I will be active in the group so my contributions will likely be on the user side.

[kellerkindt]

I'd also like to contribute. I have worked with a few microchip and atmel controllers in hobby projects since 2010, but with stm32 (+Rust) only since march. I'm not used to work in open source projects - aside from a few PRs - so just tell me when I'm doing something awfully wrong.

I'd also like the USB feature to be implemented. At the moment I'm only working with the stm32f103.

I'll not have a lot of time the next few days, but feel free to @ me.

[thenewwazoo]

I added some of my thoughts in this u.r-l.o thread I started.

[VictorKoenders]

USB is a huge one for me. I work with only stm32f103's and I've been trying to get USB to work but I can't figure it out. It would make a lot of my projects easier by not needing an USB-to-usart connection on each of my boards.

[TeXitoi]

@VictorKoenders you may be interested by https://github.com/mvirkkunen/stm32f103xx-usb

[VictorKoenders]

You're right, I AM interested in that!

[caemor]

Any progress here?

I am not too proficient with with micro controllers but trying to improve that. :smile: I have a stm32f3 discovery and the blue pill at home to help/test stuff in the stm org later if needed :wink:

[therealprof]

@caemor The f3 discovery won't help you too much for this crate. ;)

So here's my current take: Over at https://github.com/therealprof/stm32f4xx-hal we've been experimenting (somewhat successfully I'd say) with creating a universal crate for multiple STM32F4 MCUs. Now that we know that the chosen approach works fine I'm feeling confident that we can transform this crate into new crates and vastly increase the usefulness of the HAL. The key points for me to make this happen are:

• Use stm32-rs (or more precisely stm32f1) as the PAC, this might require adjustments to the HAL and/or SVD fixes
• Set up CI
• Support multiple chips using feature gates (starting with stm32f103 of course)
• Move out all examples into a (or potentially multiple) separate crate(s), which allows us to get rid of unstable requirements more easily
• Stabilise this crate and publish to crates.io

@japaric Any concerns or a veto from your side? @adamgreig Can we get that stm32 organisation on the road so we can improve the bus factor on this?

@all What would be the preferred name for this? I've heard a suggestion of stm32f1-hal, unfortunately (or not, in case STM decides to start an improved/incompatible F4 series with a slightly different name, like they did with the L4+) I started my F4 crate as stm32f4xx-hal.

[TeXitoi]

FFor the name, I'd prefer to be coherent with the svd crate name, thus stm32f1-hal or rename stm32f1.

[dbrgn]

I'd also be interested in contributing. I plan to use a blue pill for a few projects, so my main interest is also the stm32f103.

I know Rust quite well but I'm still a bit of a beginner when it comes to embedded programming.

[lorenz]

I'd also contribute. I'm doing some IOT stuff (but primarily on local network) on the STM32F10x (currently F103 since that's cheap and easily available) and maybe soon the STM32H7 series with Rust. I've paired them with a Si4463 radio and some energy harvesting stuff and I'm getting a devboard for that fabbed (mainly for sensor networks/control applications).

[dbrgn]

As @therealprof wrote:

@adamgreig Can we get that stm32 organisation on the road so we can improve the bus factor on this?

Would be great to get things started.

Right now the impl days at Rustfest Rome are taking place, maybe that might be a place to continue hacking on these areas :slightly_smiling_face: I don't know if some of you are attending, I know that at least @japaric and @rnestler are.

[dotcypress]

I'd also like to contribute and I've started porting stm32f4xx-hal for stm32L1 line here.

@adamgreig Does it make any sense to move stm32l1xx-hal repo to stm32-rs org?

[adamgreig]

@dotcypress very happy to have stm32l1xx-hal in stm32-rs org, it's definitely in scope.

[therealprof]

Just to let you know: I've pushed a preliminary version of this HAL to https://github.com/stm32-rs/stm32f1xx-hal. It does not fully compile yet due to a SNAFU in the SVD file which requires fixing in stm32-rs but other functionality should be all there and on the same level as this crate. Now the real work begins. ;)

[rnestler]

So should be deprecate this repo in favor of the https://github.com/stm32-rs/stm32f1xx-hal one?

[therealprof]

Eventually, yes.