4 ms·

This is a big step forward. And it took him 4+ years, clearly a labor of love. There is a large gap between Ada applications and BSPs. For example, you need bi

This is a big step forward. And it took him 4+ years, clearly a labor of love. There is a large gap between Ada applications and BSPs. For example, you need bindings to the underlying hardware which are part of the vendor BSP: CubeMX from STM, SimplicityStudio from SiLabs, SmartSnippets from Dialog. Having to do that on your own is painful, it's a little better than an FFI, but you still need to prototype the object files you are binding to in Ada. This is what often stalls me. Fortunately TinyUSB is supported on all the major STM Lx parts. I'm seeing bits and pieces of Ada on Arm showing up on the web, but without BSP support it isn't going to go very far. It will be a while before Ada can become a first-class embedded language on commodity parts, but this is a big step.

R0b0t1 5y ago
I'd say it is far worse than FFI. To chip vendors this is a totally automated process: the tool that configures and synthesizes the ARM core also generates the C headers and some of the driver implementation HAL, if not the driver implementation as well. Many BSPs, under the hood, are repetitive boilerplate because they can be. Getting rid of the manual adaptation will be necessary for this to really take off. The faster we can get to RISCV the better, because we can have a FOSS layer that turns core description into source code, or maybe something better. I used to be far more interested in MCUs than I am now because I realized how much busywork there is.
- elcritch 5y ago
  Many vendors provide svd files which describe the hardware registers. It's possible to convert the svd automatically like they do for C. Here's an example for Nim [1]. Rust has one as well. Though I agree that MCU's currently involve a lot of busy work. It's why I'm working on building a nice system building on Zephyr using Nim [2]. It's pretty great to write a few dozen lines of concise memory safe code to do somethinguseful, and then be able to run it on dozens different MCUs. It'd be great if there was more Ada core in these systems, as Zephyr is all built in C. At least it's modern clean C and well tested. 1: https://github.com/EmbeddedNim/svd2nim https://github.com/EmbeddedNim/svd2nim 2: https://github.com/EmbeddedNim/nephyr https://github.com/EmbeddedNim/nephyr

R0b0t1 5y ago

I'd say it is far worse than FFI. To chip vendors this is a totally automated process: the tool that configures and synthesizes the ARM core also generates the C headers and some of the driver implementation HAL, if not the driver implementation as well. Many BSPs, under the hood, are repetitive boilerplate because they can be. Getting rid of the manual adaptation will be necessary for this to really take off. The faster we can get to RISCV the better, because we can have a FOSS layer that turns core description into source code, or maybe something better. I used to be far more interested in MCUs than I am now because I realized how much busywork there is.

elcritch 5y ago
Many vendors provide svd files which describe the hardware registers. It's possible to convert the svd automatically like they do for C. Here's an example for Nim [1]. Rust has one as well. Though I agree that MCU's currently involve a lot of busy work. It's why I'm working on building a nice system building on Zephyr using Nim [2]. It's pretty great to write a few dozen lines of concise memory safe code to do somethinguseful, and then be able to run it on dozens different MCUs. It'd be great if there was more Ada core in these systems, as Zephyr is all built in C. At least it's modern clean C and well tested. 1: https://github.com/EmbeddedNim/svd2nim https://github.com/EmbeddedNim/svd2nim 2: https://github.com/EmbeddedNim/nephyr https://github.com/EmbeddedNim/nephyr