Comment by mikepurvis | Hacker News Reader

Comment by mikepurvis | Hacker News Reader

Parent Full thread

I'm interested in this as well, as a long-time Cortex/STM32 user. The barrier for me historically in exploring alternative languages/toolchains (especially in a work context) has always been uncertainty around tooling and peripheral support. Questions like:

- Am I going to get a network stack with this, and will it be as battle-tested as lwIP? What about support for USB, CANopen, etc? Will the USB stack look like it's working on a quick test but then have weird intermittent failures in the field? (hello stdperiph)

- Am I going to have a sane story for bootloading and in-system programming with this platform?

- What is debugging/logging going to look like with this platform? Will I be able to use tools like Tracealyzer without doing a ton of integration work myself? Is something that looks like GDB/OpenOCD with a standard JTAG dongle going to more or less just work?

- Quite apart from barriers in learning the new language itself, will it be a pain to get the tools set up for other developers on my team? Will people be building stuff from source and/or will I have to do packaging work?

Admittedly, some of these don't have great answers in the gnuarm world either, but to the extent that I've hacked around them already, it's a sunk cost. Anyway, I say all this not to be a downer, but to open a discussion about these kinds of issues and whether others have been impacted-by or have overcome them.

Having followed scores of these projects, the answer for all of them is likely no unless you do the work yourself.

There is an interesting gap: the C code for the HAL/stdlib of a device is typically machine generated from the VHDL and register descriptions. If you could get at that machine description, or e.g. use clang to parse the headers, you could make some good inroads into this.

As it is I typically avoid microcontrollers because of all the pointless plumbing I am required to do.

SVD is this machinine readable description, and is available for most ARM micros, as it is needed for the peripheral register view in debuggers.

svd2rust [1] is an project that generates a (very low level) Rust API for a specific micro from this file.

Generally the file generated from this is known as the header files (as it is just C headers to access the registers directly) and the HAL is an abstraction layer on top, and is actually written manually by the microcontroller designer as it contains higher level functions (e.g. a function to calculate the clock settings to get a specific UART baudrate).

The STDLib is often supplied by the compiler vendor instead, or is an open source project like picolibc [2]

[1] https://github.com/rust-embedded/svd2rust

[2] https://github.com/picolibc/picolibc

If you look it seems like portions of the STM HALs are autogenerated in some way, even if it's by stitching pieces of code together. If not there is a lot that could be automated, and my general complaint is there is a lot of manual work that is unskilled and no fun to do to get an MCU target up and running.

The Rust project is a step in the right direction.

Reply on news.ycombinator.com