Absolutely this. The same price and the Bluepill has much more powerfull CPU.
The problem is HAL support. Some periphery is supported, other is not. ADC and DMAs for UARTs were merged just recently. Stuff like SPI / I2C slave modes is missing, I think HAL interface is not fleshed out yet. Stuff like usb stack would probably take a lot time to complete.
How does it work to call C for the missing peripherals?
For instance using the exiting vendors libraries. The book in question does not seem to cover this, unfortunately.
I think for a long time we will have to accept that Rust and C are going to co-exist on these devices. So that story should be workable.
My embedded code tends to have a strong split between application logic (in platform-independent, data-driven functional code, with automated tests) and underlying hardware-dependent "app host" (as little custom code as possible), with a data-based interface.
I would be quite happy doing C for the hardware layer and Rust for the application logic layer.
I'm not sure how well it would work, the rust embedded HAL crates like to be in control of all peripherals in order to give nice guarantees of things being properly initialised.
Calling C would also have to touch the same structures which would, if nothing else, change the state of some peripherals to something that will break the rust guarantees.
I haven't tried it, but it should be doable. A lot of linux-based rust libs wrap C libs and link to them, or compile their own embedded version during build. Same thing here too, though there could be some problems regarding what C compiler is used and where it expects to find its libs.
The problem is HAL support. Some periphery is supported, other is not. ADC and DMAs for UARTs were merged just recently. Stuff like SPI / I2C slave modes is missing, I think HAL interface is not fleshed out yet. Stuff like usb stack would probably take a lot time to complete.