picostdlib VS nesper

Heres the rp2040 wrapper someone else did: https://github.com/EmbeddedNim/picostdlib

As a workaround, you might be able to just get Nim to output the c sources (nim cc), and set up your own build system (make or whatever) to build and link it. This is the approach taken in https://github.com/EmbeddedNim/picostdlib. If you do this, you might want to pass in --cpu:m68k or some other supported 8-bit arch, though I'm not sure that --cpu is used for anything else than selection the C compiler exec and flags.

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....

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.

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

Nim supports both since it compiles with pretty much any C89 C compiler. Also https://github.com/elcritch/nesper :)

Checkout Nim! I've used it to great effect for embedded programming. It has memory management system based on non-atomic reference counting (arc) so its fast and deterministic. It has optional cycle collection too (orc). Its easy to mixin manual memory as well.

I used F# a bit and learned a lot from it, and the same with Elixir. Nim is procedural it has an "enlightened procedural" take that feels like functional programming in some ways. Partly thats due to the very powerful type system - for example Nim lets you define custom distinct (not aliased) number types just like F#. Nim also inherits a fair bit from Pascal and so shares points with Ada like ints with custom ranges. Theres some rough points, but largely its made me enjoy programming again.

The esp32 is a good route since they're easy to setup. I wrote a wrapper for esp-idf which is used in production in at least two embedded shops: https://github.com/elcritch/nesper

You can run it on Arduinos as well. Theres a pure Nim setup called Ratel and a rp2040 wrapper too. :)

You should checkout Nim! I use it extensively on embedded. Nim is fantastic to program in if you're an experienced C/C++ developer. Its safer and smarter but not not pedantic about it.

Nim compiles to C or C++ so its easy to use on any embedded platform and compiler suite. Thats still huge for embedded. Rust forces a type-trait centric programming style which makes interfacing hardware/embedded harder as you have to make type heavy HALs everywhere -- hence the lack of rtos & library support despite its relative popularity).

Its pretty trivial to re-use any C/C++ libraries which gives a big boost to the native ecosystem. I wrapped most of the esp32 idf in a few weeks: https://github.com/elcritch/nesper

The new GC (ARC) is basically a built in `shared_ptr` or `Rc`. You can also do stack-based programming too and the compiler enforces a safe memory accesses. The performance is great and can match or beat C/C++ if you do a few hours of tuning. Though its easy kill performance if you're lazy (e.g. parse json into a bunch of heaps objects), but that can have its place.

I would really like to see more work on improving the use of Nim for programming microcontrollers. I stumbled on to https://github.com/elcritch/nesper recently and it looks neat, but I had issues getting my code to compile. Improved support for other MCUs like the esp8266 and atmega32u4 would be really cool and useful. It would be nice to have Nim as a higher level alternative to micropython or lua in the embedded world (your only other real alternatives being C/C++ or Rust).

I also found this https://disconnected.systems/blog/nim-on-adruino

Well no language is perfect, but Nim can be used in almost every domain because of it's compilation targets(C, C++, JS) and it's fast compile times(who needs interpretation when compile times are that fast!):

* Shell scripting, I still assume most people will just use Bash tho: https://github.com/Vindaar/shell

* Frontend: https://github.com/karaxnim/karax or you could bind to an existing JS library.

* Backend: For something Flask-like: https://github.com/dom96/jester or something with more defaults https://github.com/planety/prologue

* Scientific computing: the wonderful SciNim https://github.com/SciNim

* Blockchain: Status has some of the biggest Nim codebases currently in production https://github.com/status-im?q=&type=&language=nim&sort=

* Gamedev: Also used in production: https://github.com/pragmagic/godot-nim and due to easy C and C++ interop, you get access to a lot of gamedev libraries!

* Embedded: this is a domain I know very little about but for example https://github.com/elcritch/nesper or https://github.com/PMunch/badger for fun Nim+embedded stuff!

Most of the disadvantages come from tooling and lack of $$$ support.

Not quite sure if I follow what you're saying. As in Tasmota/Berry do or do not do more than provide I2C/SPI?

> If one wants to do serious stuff they would use an appropriate RTOS and program it in C.

It's unfortunate, but still largely appears to be the case. I find C very time consuming to program, so I ported Nim to FreeRTOS [1]. It's _very_ nice being able to go from writing highly optimized ISR functions to high level JSON parsing in one language. Add in defaulting to memory safety but with no pause-the-world GC. I tried Rust but it seems more difficult to integrate into existing world RTOS'es, flashers, Swagger debuggers, etc.

Though, I've been curious what running a WASM VM would be like? One could integrate any language: C++, C, Nim, Rust, etc. Would be interesting.

> MongooseOS does more than this if we're talking ESP32, also other devices, Javascript, C, C++, commercial support, cloud based OTA upgrades and integration with AWS, Azure, Google and IBM Watson IoT cloud services.

MongooseOS does seem interesting, but very targeting a niche market with prebuilt needs? For future RTOS'es I think ZephyrOS [2] has a lot of potential given it's now supported by NXP [3], TI, and others but is independent of any given (cloud) vendors or other IoT companies. Some might not like the CMake based build system, but in my view all the RTOS build systems are terrible in their own special way.

1: https://github.com/elcritch/nesper