They're doing great! Nim has proven surprisingly stable, which was a fear I had at first. The core team has improved compiler support and I've not run into any issues updating so far. It bolster's my confidence in Nim.
Even if Nim development were to suddenly "stop" tomorrow, it'd easily be useable for embedded for a decade or more. There's improvement to be made in Nim, but it's a resilient system design. If the same were to happen to Rust or Crystal, for example, you'd have issues keeping the compiler up to date with LLVM, etc. Compiling to C gives a lot of stability for embedded work. Sort of similar to how Delphi Pascal is still useable today.
One surprise came when I had to do some optimizations and went from `-d:debug` to `-d:release`. The debug code added enough overhead it fixed some timing issues with the high end ADC we're using. Moving to release mode made it too fast and required adding the required delay (it was in the ADC datasheet but forgot it). Easy to solve, but it's worth noting.
> Do you have futur plans for the new esp32 riscv processors?
If a risc-v processor supports C, then it already supports Nim! The real question is libraries and/or build support for the target. An afternoon of work can get the Nim build setup to work with almost any C/C++ build system. Really, Nim on risc-v just requires a target board and someone to sit down for a few hours. It's a fun "hacking exercise" :-)
As a side tangent, I'd like to make a first class "pure" FreeRTOS library as it's the most widely used RTOS. That's after dealing with a lot of annoying race conditions in the `esp-idf` and seeing the incredible amount of hacky C code in embedded systems.
Building on FreeRTOS but introducing esp32-like libraries for vfat/files/networking/etc that'd work across microcontrollers would make for an incredibly productive environment (for embedded work).
There's also the possibility of using DrNim [1] to add formal verification for certain algorithms! Nim's effect system is very flexible. Really useful would be using the "guards and locks" [2] to write and prevent deadlocks (and maybe avoid locks?) when writing resource management and device drivers. A lot of the esp-idf issue I've run into are race conditions or slow speed since even `echo`/`printf` must have a lock to protect the system UART. Those are open questions/problems, and I'm starting a new job next month so it depends on what the needs there end up being.
That’s very insightful. Thank you. Some more questions since you are the person which shows up for esp32 and nim in the whole wide world :)
Did you try out the esp-idf 4.3 release yet? I think you mentioned somewhere to not use 4.2. but 4.3 gives you the esp-managed Mqtt service on Aws (rainmaker)
Do you have any thoughts on Freertos vs Zephyr whilst using Nim?
> That’s very insightful. Thank you. Some more questions since you are the person which shows up for esp32 and nim in the whole wide world :)
You're welcome. lol, no one else did it so there you are.
> Did you try out the esp-idf 4.3 release yet?
No, my work requires stability so I haven't tried any of the new esp-idf releases. Nesper does compile with 4.2 if you pass the flag for it, but it's not well tested. If none of the major API's have changed 4.3 should work.
It would be good to wrap the mqtt aws service. Don't know if I'll have time for it though. But it's really not too hard to wrap using `c2nim` on the header files. PR's welcome! :-)
> Do you have any thoughts on Freertos vs Zephyr whilst using Nim?
I would like to try Zephyr sometime. FreeRTOS is used by AWS and the esp32 so it seemed a good start.
