svd2nim VS nephyr

Nim's maintainer agrees with you I believe, and the API is as you suggest (volatileLoad and volatileStore): https://nim-lang.org/docs/volatile.html

However, under the hood, Nim compiles to C. So these are macros that typecast to volatile, does the read (or write), then casts back to non-volatile.

(Small plug for my nim project that is somewhat related to OP: https://github.com/EmbeddedNim/svd2nim)

C++ has decent industry acceptance in embedded nowadays, or at least that has been my impression.

After C++, rust is likely the most popular, quite a lot of effort has been put into running rust on embedded, see eg https://github.com/rust-embedded. However, once again to my understanding, industry acceptance is still highly marginal.

After that, there's a bunch of toy-ish efforts to run other languages. Zig, nim, python and javascript variants, etc. Usually anything that has C ABI compatibility should be possible to get up and running (without writing a compiler backend from scratch). I've had fun with some toy projects using nim for ARM cortex-M targets (https://github.com/EmbeddedNim/svd2nim, https://github.com/auxym/nim-on-samd21, https://github.com/EmbeddedNim/picostdlib).

Using Nim (and eg svd2nim to generate the equivalent of CMSIS headers for register access in pure nim), it would be entirely possible to write even the low level stuff (SPI drivers and whatnot) in 100% nim, with the same performance as C and better safety (better static type system and compile-time checks, etc). Runtime (eg overflow) checks and garbage collection are available (at the cost of some performance) but optional. See eg. a pretty basic higher-level API for GPIO access, that provides native performance, since the abstraction is implemented as macros (compile-time abstraction): https://github.com/auxym/nim-on-samd21/blob/master/src/port....

Any chance your MCU is ARM? If so check out my project to generate the register mappings from CMSIS SVD files: https://github.com/EmbeddedNim/svd2nim

To be clear: Ratel isn't my project, just something I'm following due to interest.

In the interest of shameless self promotion :), my own experimentations are :

https://github.com/EmbeddedNim/svd2nim

https://github.com/auxym/nim-on-samd21

And I've used and contributed to picostdlib (https://github.com/beef331/picostdlib), the rp2040 support library.

All just as a hobby, but it's interesting to learn that some companies are actually looking into Nim for firmware! Embedded seems like such a slow moving industry. I believe the author of Nesper and Nephyr also developed them for professional work.

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

If you're curious, I have this in MVP status at the moment: https://github.com/auxym/svd2nim

I use Nim on embedded precisely for that reason: https://github.com/elcritch/nesper

I wtapped much of zephyr as well but that ones less used: https://github.com/embeddednim/nephyr

It's funny how something like Zig's comptime of C++'s constexpr get 90% of the way to solving most compile time issues, but can't knock out that last 10%. Compile time database types sound like one of those cases. F# had a feature for compile time types via "type providers". It seemed _really_ cool at first, but in practice is was a bit fragile.

Though on the other hand I'm using compile Nim code to parse CMake files and provide static types for configuration values. It's super easy in Nim between macros and const's. Here's a ~170 lines of code where I'm compile time checking that my Nim code can compile time check against the current build configuration of Zephyr RTOS https://github.com/EmbeddedNim/nephyr/blob/main/src/zephyr_c...

Nesper author here, unfortunately I haven’t had time to fix the compile issues on all the esp-idf branches. Please feel free to file an issue as I don’t use es-idf/Nesper often now but I’ll respond to issues. The main branch should be more stable too.

I’ve been moving development to Zephyr RTOS since it supports many more boards and is more stable. I’d recommend trying it out but note it’s a WIP. I haven’t figured out templated examples yet. I’ve covered lots of api areas but not all. My goal is to make it into a broad MCU platform for Nim — Nephyr: https://github.com/EmbeddedNim/nephyr

But yah Nim can run on most anywhere you can compile C to. Some people just got Nim CMSIS working. I’m hoping to get more people involved at github.com/EmbeddedNim project to support more mcu’s. Testers are welcome!