MicroZig: Unified abstraction layer and HAL for Zig on several microcontrollers

I know people who insist on putting register addresses (in hex) in their code rather than make a variable because "it's easier to debug by comparing to the user guide. If it was a variable, you would have to look up its value every time". It looks somewhat like this:

   *(int*)(0xf003) |= 39;

> In what way? Comptime should be generally capable of anything macros are.

I started to reply to this with 'Comptime is generally capable of doing anything that Nim's templates can accomplish (but not it's macros)', but I stopped myself because even though Zig's comptime is more akin to Nim's templates than its macros (in my opinion), Nim templates are more powerful as they allow you to embed arbitrary blocks of code to implement constructs similar to python's context managers (which I'm fairly certain you can't do with comptime).

W/R/T Macros vs Comptime, you can't create arbitrarily complex DSLs with comptime the way you can with a Nim's macros as you don't have full control over AST generation.

All that said, the power you'd get from a Macro or Template system like Nim's don't really jive with Zig's whole "no hidden control flow" thing.

>Terribly difficult to implement without breaking a major language tenant of “no hidden control flow”.

I dunno if I agree with that, even very simple rust-like traits that simply enforce that a struct implemented a given interface at compile time (static dispatch only) would go a long way without compromising obvious control flow IMO.

>But I found that once I left behind OO style of thinking, I haven’t missed this all that much. For the rare time I do generalize like this, you can literally just check at comptime that the passed in type provides the necessary decls. It’s not terribly complex or hostile (although tooling could use some work around it)

Respectfully, I don't view it as OO thinking (I think typeclasses come from SML...). Making polymorphism reasonably ergonomic goes a long way towards code reuse and (again, only my humble opinion here) would help with what some of the folks in this comment section are talking about w/r/t code re-use and generalizing a HAL layer in a consistent way without forcing users (or library authors) to write a bunch of ad-hoc code to check that functions exist on a given struct, or manually implementing dispatch tables.

Nim is “just C” at the end of the day, so by leveraging the —-compileOnly flag you can use Nim anywhere you can use C

Now that arc/orc are the default memory management strategy, it’s even possible to keep some of the niceties from the standard library when doing so — but that will depend on your target of course.

Even going the “no heap allocation” route is totally feasible, you sort of end up using Nim as a nicer C syntax with extra features. All of the libraries we write for work have two interfaces, one that returns (possible heap allocated) results, and one that takes a buffer pointer (as a var openArray[T] param) in instead.

I use Nim at work for embedded firmware development right now, and we evaluated Zig but it was a year and a half ago when we started the project, Zig just wasn’t as far along as it is now.

I’m currently in the process of writing a nice HAL/dev framework agnostic FreeRTOS binding in Nim, which maybe you’ll find useful once we can post it?

Like any time you get off the beaten path, there are rough patches, but to paraphrase another comment in this thread "Nim is just C", so anything that felt a little awkward just meant using an `importc` pragma and doing whatever I needed to do in an environment I felt more comfortable (you can also have C code compiled with a {.compile: "foo.c"} pragma, so if a module required something be done in C, you didn't have to monkey about with the build system to include it, it 'just worked')

The biggest negative I ever hit was that early on, Nim didn't have support for `volatile`, which meant it was a non-starter for doing anything with MMIO (I ended up being the one who added volatileLoad/volatileStore to Nim's stdlib so I could use it on a Cortex-M without having to drop into C so much).

For the most part though, if you're reasonably comfortable with embedded toolchains (i.e. you understand how to write linker scripts, understand what happens between a reset and actually getting into `main()`, etc), it's not much of a hurdle to set up a simple build system to compile your Nim code to C, link appropriately, and then sort of forget about it.

It's been a while, but IIRC I also got step-through debugging working with OpenOCD by having the nim compiler generate `#line` pragmas and including debug symbols, which was pretty neat.

This was all pre ARC/ORC, so I did have to make sure to be careful not to use ref objects, but ultimately it felt pretty seamless. I still tend towards fully manually managed memory on embedded projects, but I'd be curious to give it a go.

Sounds great in theory (writing MCU-agnostic libraries for peripherals), but I've found it unusable in practice due to the clunky API and incompatibility with DMA, interrupt-based-flow, least-common-denominator functionality etc.

The new direction that library and related is Async with Embassy, which... is also not something I want to use.

Despite my day job involving rust, I struggled pretty hard getting Rust working adequately for my little GPU project on both pi pico and an esp32s3. Both had debugg-ability issues, missing features that would have required advanced FFI integrations to be added, and things just wouldn't even work. I spent a week on it making no progress, and with only an hour an evening I had to do anything it was frustrating.

I then spent 2 days brushing up on C and got things up and running with ESP-IDF painlessly. I've been iterating really fast on C just fine, and the few times I wish I had Rust's features have been eclipsed by the advanced ESP-IDF api's I've needed to use that didn't have support in the Rust HALs.

That works… sometimes. Just doing a quick search in the Rust book, 0 results for “rustlang”, 30+ results for “rust”.

Yeah I remember reading about it's relation to LLVM issues etc. I also think there was another (languishing) fork of the entire zig repo which had some support for Xtensa which I couldn't find at the time, but I found it.

https://github.com/ominitay/zig/tree/xtensa

Edit: I see you are the same kassane from the GitHub thread. Thank you for your efforts on Xtensa support! Would be great to have it out-of-the-box at some point.

it's true that micropython doesn't compete with zig, but zig is simple enough/no-fuss enough (imagine deployment strategies baked with one line in a build.zig) that it might compete with micropython.

You're right of course, but if you pick up a 2040 and you're a newbie to microcontrollers (as I am), all of the documentation and first-party tools push you towards using Python, which I've never been too fond of and I started looking for alternatives as soon as I finished the last chapter of the manual. The alternatives are always there but they presume a level of experience (and C skills) that I just don't have. Having experimented with Zig I was glad to eventually find MicroZig. I remember that using it wasn't quite as easy as "push button, watch LED blink" as it was when I was using Python and Thonny but if a n00b like me could figure it out, anyone can.

BASIC, Pascal have been doing it for decades already, to the point the likes of Mikroe and Parallax don't have any issue staying in business selling compilers.

Great, thanks!

Isn't it better just to repost with a query parameter like ?foobar ?

It's not langauge-neutral. But I suppose one could imagine zig at the bottom level on the bare metal and other languages being able to call into that zig layer.