Though obviously the Rust approach provides a lot more guarantees, especially at runtime.
The one thing that interests me is how flexible this approach would be at dealing with cases where you have to hack around a hardware bug. For example, I had a board on it with an I2C expander whose default I2C address was not one the STM32 was able to address, but could be changed at runtime with an I2C command. So this was dealt with in firmware by initializing those pins initially as GPIO and bit-banging in the message to change the address, then changing them over to the regular I2C peripheral and taking it from there.
How possible would something like that be with this much more tightly constrained Rust IO model?
Looks to me like this is something that can be added to the take() function. After all, you're generating the crate yourself with svd2rust. I wonder if these "auto-crates" would be viable for submission to crates.io. This way you could solve that HW bug once and for all for everyone.
https://github.com/andysworkshop/stm32plus/blob/master/examp...
Though obviously the Rust approach provides a lot more guarantees, especially at runtime.
The one thing that interests me is how flexible this approach would be at dealing with cases where you have to hack around a hardware bug. For example, I had a board on it with an I2C expander whose default I2C address was not one the STM32 was able to address, but could be changed at runtime with an I2C command. So this was dealt with in firmware by initializing those pins initially as GPIO and bit-banging in the message to change the address, then changing them over to the regular I2C peripheral and taking it from there.
How possible would something like that be with this much more tightly constrained Rust IO model?