Interesting you use Nim, would you have some resources/pointers for using Nim on embedded devices.
Do you use a native compiler or cross-compile it for this (RISC-V) chip ?
So the S3 is actually a Xtensa LX7 processor rather than a RISC-V one, but the process is the same: “--compileOnly” to output C sources from Nim, and point CMake to that nimcache output folder.
With #line macros injected into the compiled C output source files, JTAG debugging and other tools just work, which is quite nice.
That said, if I was on the C3 or any of the RISC-V chips I’d look at using the C toolchain directly: you can easily have “nim c main.nim” call out to a specific C compiler with your specific build and linker flags!
The one annoyance in all of the embedded toolkits when trying to use non-C/C++ languages is always CMake; companies build component systems and such on top of it which a naive C compiler usage can’t really leverage, which means you end up rebuilding the whole build toolchain again.
Easier to just stick within CMake and use Nim’s C output instead, at least for now (until I get some time to write a nimscript parser for a subset of ESP-IDF’s CMake file format…)
I also use Nim quite a bit on linux/windows for machine-learning purposes.
But even on these systems, It is generally a pain to try to trick Nim into using a compiler not directly supported, as some original hard-coded flags would be incompatible with the one i am trying to use,for example NVCC .
Follow up question, Do you generally use Nim on ESP like chips which run some form of a RTOS, or also on bare-metal micro-controllers ?
Yeah, we deliberately have a fork of Nim that is purely for adding workarounds when we hit small internal things like that — though most of our changes are upstreamed proper now which is nice!
To answer your follow up question; both - we’re in the process of bringing up firmware for the STM32G0 and L4 microcontrollers, and CubeMX is such a pain to try and bind as-is, we started to play with svd2nim and see if we can’t bring up peripherals that way instead. That’s a less well tread path of course, but it’s promising so far. Only downside is that’s more like Rust’s approach of rebuilding the world, but oh well
With #line macros injected into the compiled C output source files, JTAG debugging and other tools just work, which is quite nice.
That said, if I was on the C3 or any of the RISC-V chips I’d look at using the C toolchain directly: you can easily have “nim c main.nim” call out to a specific C compiler with your specific build and linker flags!
The one annoyance in all of the embedded toolkits when trying to use non-C/C++ languages is always CMake; companies build component systems and such on top of it which a naive C compiler usage can’t really leverage, which means you end up rebuilding the whole build toolchain again.
Easier to just stick within CMake and use Nim’s C output instead, at least for now (until I get some time to write a nimscript parser for a subset of ESP-IDF’s CMake file format…)