I think the hybrid approach, high-level Rust + low-level C is actually preferable. Rust really shines at the high-level things and you do what C is good at on the drivers.
Embedded Rust Experiments: Is My STM32 MCU Running Fast?
11–19 of 19 posts
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#12I think the hybrid approach, high-level Rust + low-level C is actually preferable. Rust really shines at the high-level things and you do what C is good at on the drivers.
I don't see what C gives you at a low level that rust doesn't.
You can translate C line by line into identical rust at no cost except that you have to write "unsafe" once per fn. With the exception of macros, but rust's replacements there are just better.
Keeping everything in one language seems like a worthwhile reason not to use C to me.
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#13That diagram of the clocking system is a good example of how the bigger MCUs are like having a whole computer on a single chip, with all the implications of complexity that brings. It's not enough to set up a single clock; you also need to make sure the clocks to the peripherals that are in use are also what you need them to be. (I wish such diagrams in datasheets would let you click on the appropriate blocks to jump…
Yeah, even a small part such as the cc1310 from Texas Instruments (a sub-GHz wireless SOC for Quite complex stuff.
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#14I think the hybrid approach, high-level Rust + low-level C is actually preferable. Rust really shines at the high-level things and you do what C is good at on the drivers.
I don't see what C gives you at a low level that rust doesn't. You can translate C line by line into identical rust at no cost except that you have to write "unsafe" once per fn. With the exception of macros, but rust's replacements there are just better. Keeping everything in one language seems like a worthwhile reason not to use C to me.
Mainly because of the extensive Hardware Abstraction Layers (HAL) libraries available from most mcu vendors
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#15Earlier quoted context omitted.
I don't see what C gives you at a low level that rust doesn't. You can translate C line by line into identical rust at no cost except that you have to write "unsafe" once per fn. With the exception of macros, but rust's replacements there are just better. Keeping everything in one language seems like a worthwhile reason not to use C to me.
Mainly because of the extensive Hardware Abstraction Layers (HAL) libraries available from most mcu vendors
1) they are crap and everybody hate them
2) I don’t see the point in buying an MCU whose timer is incredibly advanced (look at TIM1 and TIM8 on an STM32) and abstracting it afterwards.
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#16I think the hybrid approach, high-level Rust + low-level C is actually preferable. Rust really shines at the high-level things and you do what C is good at on the drivers.
I don't see what C gives you at a low level that rust doesn't. You can translate C line by line into identical rust at no cost except that you have to write "unsafe" once per fn. With the exception of macros, but rust's replacements there are just better. Keeping everything in one language seems like a worthwhile reason not to use C to me.
C gives you better options for static analysis of worst case stack usage, e.g. https://github.com/PeterMcKinnis/WorstCaseStack
Proprietary software for this is also available with superior UI and features, and I expect people serious about high-reliability embedded systems already use it.
Rust Nightly does have limited support for printing stack usage by function with -Z emit-stack-sizes, but I could not find anything for analysis of worst case stack usage in whole programs.
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#17I think the hybrid approach, high-level Rust + low-level C is actually preferable. Rust really shines at the high-level things and you do what C is good at on the drivers.
I don't see what C gives you at a low level that rust doesn't. You can translate C line by line into identical rust at no cost except that you have to write "unsafe" once per fn. With the exception of macros, but rust's replacements there are just better. Keeping everything in one language seems like a worthwhile reason not to use C to me.
The 'embedded' market runs the gamut from $0.05 to $15+ and within that range, users have different concerns.
At the $15 end of the market, developers have a good chance of wanting to import code from other sources. For example, depending on the application, they might need an RTOS to provide multi-threading, FAT32 for an SD card, or a network stack with SSL implementation.
Often, the developer will want a 'lightweight' library, i.e. one intended for microcontrollers, and often this will be written in C.
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#18Earlier quoted context omitted.
I don't see what C gives you at a low level that rust doesn't. You can translate C line by line into identical rust at no cost except that you have to write "unsafe" once per fn. With the exception of macros, but rust's replacements there are just better. Keeping everything in one language seems like a worthwhile reason not to use C to me.
C gives you better options for static analysis of worst case stack usage, e.g. https://github.com/PeterMcKinnis/WorstCaseStack Proprietary software for this is also available with superior UI and features, and I expect people serious about high-reliability embedded systems already use it. Rust Nightly does have limited support for printing stack usage by function with -Z emit-stack-sizes, but I could not find anythin…
Presumably you lose static analysis benefits as soon as you are mixing languages though?
Re: Embedded Rust Experiments: Is My STM32 MCU Running Fast?
#19It is always good to get to know your MCUs. When I first started using STM32s I would also scope the crystal and then toggle some pins as fast as possible to make sure. Many gadgets later I trust the programmatic detection of external crystal use and appropriate PLL function. If you HAVE to know if the crystal fails you can use the CSS (Clock Security System) to generate interrupts in case you fall back to the intern…
TIP: You should never scope a crystal directly as that could damage it. In production, for testing crystals, we output a PWM on a pin using the crystal as a source and measure that if the MCU doesn't have a built in functionality.
Interesting, but maybe not required. You can do a programmatic check of the crystal and PLL. I've had over 200k devices fabbed and deployed without ever directly testing a single crystal. What kind of error rate do you find?