5 ms·

I used Zig (not MicroZig, just rolled my own HAL) for the bootloader and firmware on a soft RISC-V SOC + custom peripherals recently and had somewhat mixed, tho

I used Zig (not MicroZig, just rolled my own HAL) for the bootloader and firmware on a soft RISC-V SOC + custom peripherals recently and had somewhat mixed, though positive feelings about it. On the positive side: - As a 'safer c', getting things up and running was a breeze, writing code largely felt intuitive. - The additions to C (slices/iterators, enhanced structs, arbitrarily sized integers) are excellent - It produces fairly small firmware images (useful when stuffing a boot rom in logic/EBRAM) - Easier (than C IMO) to get up and running with formatted IO vs retargeting libc - Comptime is neat, and you can build some decent low-cost abstractions with it (ex: I built a comptime heavy write-through cache for key-value storage that required very little overhead and largely self-generated based on a simple struct) - I really enjoy the use of structs for function+data organization. It maps well to hardware instances, giving you an 'object' like feeling without OOP ick. On the negative side: - The compiler is still a seriously moving target. Upgrading sometimes meant rather large refactors. - Documentation is somewhat poor IMO. - As a long time user of Nim (including on really lean embedded targets), compared to hygienic macros, comptime falls way short. - The lack of first class interfaces/traits/typeclasses is not my favorite. The currently suggested alternatives are so un-ergonomic I'd almost call them hostile. All-in-all, I'm excited to see where Zig ends up. After nearly 20 years writing embedded code I'm really (really really really) tired of C. The embedded systems community really needs to embrace better tools.

AceJohnny2 3y ago
> After nearly 20 years writing embedded code I'm really (really really really) tired of C. The embedded systems community really needs to embrace better tools. Hear hear, brother! I get particularly frustrated about the second point, and I've made it my career goal to get my teams to update their tools and processes. For example, when I joined my current team, they didn't compile debug symbols and didn't know how to use a debugger on our system! Hell, in 2024 I still have colleagues who prefer to use a .dis and .map file than leverage the debug symbols... "What is this "mixed code and disassembly" display you speak of"
- staunton 3y ago
  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;
  - AceJohnny2 3y ago
    Oh deer god. We've never been that bad, but we are still using macros for registers instead of block structure pointers, which we have access to... (although I'll grant that structures can be risky due to undefined packing rules)
  - the__alchemist 3y ago
    So, my favorite pattern in Rust for this is to use a u8, (or u16 etc)-repr Enum for register addresses and values. So, you'd do something like, assuming a direct register API vice a wrapper: write_register(Reg::Config as u8, value) Where `value` may be constructed from variables or, wait for it... Might be a binary literal because it's easier to compare to the datasheet if it's a one-off vice a general API. If it's a general API, it is probably handled with a config struct etc, where each field is a u8-repr enum. Code like this should IMO always have a reference to the relevant DS table in comments, and probably an explanation of why you're setting the bits that way.
cgh 3y ago
> The lack of first class interfaces/traits/typeclasses is not my favorite. The currently suggested alternatives are so un-ergonomic I'd almost call them hostile. The use of anytype as a sort of universal interface is my least favourite part of Zig. I’ve seen enough griping about it that I’m hopeful something happens here.
wredue 3y ago
>- As a long time user of Nim (including on really lean embedded targets), compared to hygienic macros, comptime falls way short. In what way? Comptime should be generally capable of anything macros are. >- The lack of first class interfaces/traits/typeclasses is not my favorite. The currently suggested alternatives are so un-ergonomic I'd almost call them hostile. Terribly difficult to implement without breaking a major language tenant of “no hidden control flow”. 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)
- jeff_ciesielski 3y ago
  > 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.
bsder 3y ago
> - As a long time user of Nim (including on really lean embedded targets) Could you expound on how you used Nim on "really lean embedded targets"?
- girvo 3y ago
  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.
vrinsd 3y ago
Hey Jeff, Can you share what your experience has been like with Nim on embedded targets? Both Nim and Zig are on my wishlist to try out for embedded but I'm doing C and RTOSes for the next few projects. Ada with Ravenscar seems like another "seems like it solves a lot of common problems intelligently" but I haven't had much time to try it being a simple proof of concept.
- girvo 3y ago
  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?
  - SV_BubbleTime 3y ago
    Do neither of these languages have better concurrency tools than porting FreeRTOS?
    - davidzweig 3y ago
      iirc the os needs to have processor specific task switching code in assembly, Freertos must have tons of ports already. Nim supposedly has nice FFI for C. The niceness of freertos is then mostly about it's.. system call design. If it's good, then you could probably progressively rewrite freertos in nim. Never used nim and been a while since I did any embedded.
    - bsder 3y ago
      OS is not the same level of abstraction as a language. This is an active problem in embedded. Cheap microcontrollers can have multiple cores that are not even the same architecture. This means that just to get "blinky" running, you need to choose a (language, OS) tuple. And, given that "language" is generally "C", that means that your abstraction choices for OS are lousy. Side question: last I checked, FreeRTOS didn't do a great job when multiple microcontrollers were involved--especially if the communication channels or synchronization were hardware-based. Has this changed?
GuestHNUser 3y ago
> - The lack of first class interfaces/traits/typeclasses is not my favorite. The currently suggested alternatives are so un-ergonomic I'd almost call them hostile. Personally, I don't see this as a problem. I like implementing an interface in Zig the same way I implement one in C -- I use a function pointer that takes a packet that defines the operation to execute with that packet data. Zig's exhaustive switch statements make these even better to work with. Here is some pseudocode to illustrate what I mean: fn doThing(ThingPacket p) switch(p.Opcode) MyInterfaceFunc1_Opcode => return MyInterfaceFunc1(p.Func1Params); MyInterfaceFunc2_Opcode => return MyInterfaceFunc2(p.Func2Param); ... default => error.InvalidOpcode;

AceJohnny2 3y ago

> After nearly 20 years writing embedded code I'm really (really really really) tired of C. The embedded systems community really needs to embrace better tools. Hear hear, brother! I get particularly frustrated about the second point, and I've made it my career goal to get my teams to update their tools and processes. For example, when I joined my current team, they didn't compile debug symbols and didn't know how to use a debugger on our system! Hell, in 2024 I still have colleagues who prefer to use a .dis and .map file than leverage the debug symbols... "What is this "mixed code and disassembly" display you speak of"

staunton 3y ago
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;
- AceJohnny2 3y ago
  Oh deer god. We've never been that bad, but we are still using macros for registers instead of block structure pointers, which we have access to... (although I'll grant that structures can be risky due to undefined packing rules)
- the__alchemist 3y ago
  So, my favorite pattern in Rust for this is to use a u8, (or u16 etc)-repr Enum for register addresses and values. So, you'd do something like, assuming a direct register API vice a wrapper: write_register(Reg::Config as u8, value) Where `value` may be constructed from variables or, wait for it... Might be a binary literal because it's easier to compare to the datasheet if it's a one-off vice a general API. If it's a general API, it is probably handled with a config struct etc, where each field is a u8-repr enum. Code like this should IMO always have a reference to the relevant DS table in comments, and probably an explanation of why you're setting the bits that way.

cgh 3y ago

> The lack of first class interfaces/traits/typeclasses is not my favorite. The currently suggested alternatives are so un-ergonomic I'd almost call them hostile. The use of anytype as a sort of universal interface is my least favourite part of Zig. I’ve seen enough griping about it that I’m hopeful something happens here.

wredue 3y ago

>- As a long time user of Nim (including on really lean embedded targets), compared to hygienic macros, comptime falls way short. In what way? Comptime should be generally capable of anything macros are. >- The lack of first class interfaces/traits/typeclasses is not my favorite. The currently suggested alternatives are so un-ergonomic I'd almost call them hostile. Terribly difficult to implement without breaking a major language tenant of “no hidden control flow”. 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)

jeff_ciesielski 3y ago
> 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.

bsder 3y ago

> - As a long time user of Nim (including on really lean embedded targets) Could you expound on how you used Nim on "really lean embedded targets"?

girvo 3y ago
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.

vrinsd 3y ago

Hey Jeff, Can you share what your experience has been like with Nim on embedded targets? Both Nim and Zig are on my wishlist to try out for embedded but I'm doing C and RTOSes for the next few projects. Ada with Ravenscar seems like another "seems like it solves a lot of common problems intelligently" but I haven't had much time to try it being a simple proof of concept.

girvo 3y ago
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?
- SV_BubbleTime 3y ago
  Do neither of these languages have better concurrency tools than porting FreeRTOS?
  - davidzweig 3y ago
    iirc the os needs to have processor specific task switching code in assembly, Freertos must have tons of ports already. Nim supposedly has nice FFI for C. The niceness of freertos is then mostly about it's.. system call design. If it's good, then you could probably progressively rewrite freertos in nim. Never used nim and been a while since I did any embedded.
  - bsder 3y ago
    OS is not the same level of abstraction as a language. This is an active problem in embedded. Cheap microcontrollers can have multiple cores that are not even the same architecture. This means that just to get "blinky" running, you need to choose a (language, OS) tuple. And, given that "language" is generally "C", that means that your abstraction choices for OS are lousy. Side question: last I checked, FreeRTOS didn't do a great job when multiple microcontrollers were involved--especially if the communication channels or synchronization were hardware-based. Has this changed?

GuestHNUser 3y ago

> - The lack of first class interfaces/traits/typeclasses is not my favorite. The currently suggested alternatives are so un-ergonomic I'd almost call them hostile. Personally, I don't see this as a problem. I like implementing an interface in Zig the same way I implement one in C -- I use a function pointer that takes a packet that defines the operation to execute with that packet data. Zig's exhaustive switch statements make these even better to work with. Here is some pseudocode to illustrate what I mean: fn doThing(ThingPacket p) switch(p.Opcode) MyInterfaceFunc1_Opcode => return MyInterfaceFunc1(p.Func1Params); MyInterfaceFunc2_Opcode => return MyInterfaceFunc2(p.Func2Param); ... default => error.InvalidOpcode;