Very cool for Zephyr, I've been interested in checking it out since I heard one of the devs on the Embedded.fm podcast.
> Interesting, did you go with the C-struct model or use the setter/getter > pattern you discussed before? Setters/getters. For a few reasons. (1) C doesn't map closely enough to Nim to make the raw structs work "just as in C" as in this case, which would have been the main draw to that approach. I have to admit I came out of the exercise with an appreciation of C's ergonomics for this specific use case, which was somewhat surprising to me. (2) Accessors is what svd2rust does, so I took some inspiration from there (including the `read`/`modify`/`write` naming). And (3) it's way more flexible in leveraging Nim's type system for safety (read/write permission enforcement, compile-time range checks on bitfields, etc). I could consider providing a CLI switch to make the raw pointers public if people really want it, but I haven't seen the need yet in my stuff. The API section in the readme shows a lot of samples of generated code. > any thoughts on hardware you'd like to test? I plan on testing svd2nim on Atmel SAMD21 to start with. It's a pretty small CM0+ device with a nice assortment of peripherals, and pretty popular on arduino-ish dev boards (Arduino Zero, Adafruit Feather, Sparkfun, etc). Not sure if it's a good candidate for Zephyr though, it has limited ram/flash. As I mentioned previously, the other h/w I'd like to play with Nim on would be Teensy 4.1, though supply has been limited lately. As for CMSIS, to get this stuff running on the samd, I was planning on writing a wrapper (or minimal rewrite, if it's too macro-heavy) for the `core_cm0plus.h` CMSIS header, which provides control for interrupts (NVIC) and other common stuff like the systick timer. As I understand, the rest of CMSIS is: 1\. Cortex-A stuff, which TBH if I use a Cortex-A it's probably going to be running linux, so anything Nim should not be an issue. 1\. A common (C) interface for higher-level peripheral drivers, which are device-specific and provided by vendors. Probably not super relevant here. 2\. An RTOS, and you've already got work going on Zephyr. 3\. A DSP stdlib, which is interesting but TBH I've never dug into it, mostly write my own (simple) stuff from scratch. 4\. A neural network stdlib. 5\. Pack/Build which are logistics specs for vendor pack distribution and build systems 6\. The DAP debugging protocol 7\. Zone, which I'm not very familiar with, but I think it's an abstraction layer for MPUs and similar memory-safety hardware?
