|
|
|
|
|
by girvo
1099 days ago
|
|
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 ?