6 ms·
MicroZig: Unified abstraction layer and HAL for Zig on several microcontrollers
- nippoo 3y agoThe fragmented state of the microcontroller market is pretty dire. Especially as there's more higher-level features being baked in to modern micros, every different manufacturer is implementing different APIs to do the same basic thing (whether that be I2C or things like MIPI-CSI). Having a unified API would really help portability (and would enable people to build workable emulators!)
- ComputerGuru 3y agofyi since you seem to be interested in this: rust has a few options including the embedded_hal crate with impls for everything from various microcontrollers to desktop linux. https://docs.rs/embedded-hal/latest/embedded_hal/ https://docs.rs/embedded-hal/latest/embedded_hal/
- the__alchemist 3y agoSounds 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.
- KallDrexx 3y agoDespite 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.
- ComputerGuru 3y agoMy experience wasn’t stellar but it wasn’t like yours. There’s of course no comparison between the speed of getting up and running with the official sdk and toolchain, but it wasn’t so miserable.
- petra 3y agoModm.io is a a unified API for microcontrollers.
- MatthiasPortzel 3y agoI started a new project with MicroZig just the other week. It’s working (with the RP2040), and that alone is a huge deal, since writing Zig is much more ergonomic than C with Arduino. It makes cross-compiling for testing in simulation locally trivial as well. However, the project is still not very mature. They just refactored into the repo you see since I started using it. Support for RP2040 is good, but the HAL for other microcontrollers seems less supported. (And it seems to be written in such a way that code isn’t shared between HALs for different microcontrollers.) It’s targeting stable Zig (instead of HEAD), which is an unusual choice for Zig projects, since Zig is also in an immature state and updates rapidly. There’s zero documentation except for the source, but that’s par for Zig projects. Zig has the potential to be huge for embedded, once these APIs are fleshed out and stabilize. It’s already more enjoyable than writing C.
- wredue 3y agoI just recently switched off stable to 0.12 and I honestly didn’t run in to too much in the way of changes. It is a bit unusual for zig projects currently BUT zig changes are slowing. Additionally, Andrew himself has stated he wants 0.12 to be a version where zig devs should feel comfortable pinning to stable. I know stable now is 0.11, but the changes are not egregious at the moment. Not sure if that’s still the deal.
- mikepurvis 3y agoI'm interested in this too, though I've had mixed experiences in the past using third party HALs for microcontrollers only to discover that they have gaps in API coverage or can only expose the most common use-cases. There was always lot of examples and documentation for the "easy" stuff like GPIOs, timers, ADCs, serial port, etc, but once you got into USB, Ethernet, or RTOS integration then things rapidly got much scarier.
- tredre3 3y agoArduino is C++, not C! Of course that changes nothing to what you said :) .
- zamalek 3y ago> Support for RP2040 is good, I've done a fair bit of stuff with embedded Rust and the main reason for this is manufacturer documentation. The RP2040 is really in its own tier of documentation quality, nothing comes close. Other chipsets are so bad that the Rust SVD codegen has a way for maintainers to fix errata. I've concluded that I'm only going to use RP2040s going forward.
- Cyberdog 3y agoI got this working on a RPi 2040 during my most recent microcontroller phase several months back. I know Zig can be oddly divisive here on HN but can we at least agree that it's a good thing to have alternatives to Python in this space?
- nrclark 3y agoIn the microcontroller space, I think Zig is more of a replacement for C/C++. It's a compiled language, intended to produce optimized code that hits cost/performance targets. Micropython and friends are well-suited for education/hobby use, protoptyping, and maybe some commercial applications that aren't sensitive to cost or realtime characteristics. But since they don't really compete with C/C++, they also don't really compete with Zig.
- throwawaymaths 3y agoit'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.
- Cyberdog 3y agoYou'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.
- pjmlp 3y agoBASIC, 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.
- cnln 3y agoI literally just posted on my blog about my adventures writing an OLED driver in MicroZig, it was a really fun little project https://news.ycombinator.com/item?id=39540761 https://news.ycombinator.com/item?id=39540761
- dang 3y agoThat's great and if you email hn@ycombinator.com in, say, a couple months*, we can send you a repost invite for it. * i.e. enough time to flush the hivemind caches so the thread won't feel repetitive
- cnln 3y agoGreat, thanks!
- sgt 3y agoIsn't it better just to repost with a query parameter like ?foobar ?
- dang 3y agoOh the issue isn't a technical one. It's that once there's been a big discussion about a topic (in this case MicroZig) the community appetite for a second thread about roughly the same thing (in this case, another MicroZig thread) drops off sharply. However, if you wait long enough then it becomes fresh again and a new thread is ok. That's what I facetiously call letting the hivemind caches clear.
- spiritplumber 3y agoYou know what you doing! Move Zig for great justice.
- just_steve_h 3y agoYOU HAVE NO CHANCE TO SURVIVE MAKE YOUR TIME
- spiritplumber 3y agoAre there any plans to put this on the Parallax Propeller as well?
- UncleOxidant 3y agoAre there similar efforts for other languages? Or could this be a starting point for a language-neutral, multi-board/microcontroller HAL?
- skybrian 3y agoThere are lots of similar efforts, but they tend to be half-finished on many platforms that they supposedly support. (Also, how is this one language-neutral?)
- UncleOxidant 3y agoIt'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.
- TimSchumann 3y agoWord on the street is the badges at the next Software You Can Love conference will be running this.
- jeff_ciesielski 3y agoI 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 agoI 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;
- 22c 3y agoESP32 and STM32 support is very welcome! I have been following https://github.com/ziglang/zig/issues/5467 https://github.com/ziglang/zig/issues/5467 for a while and progress seemed to have slowed significantly
- kassane 3y agoUnfortunately, the upstream zig toolchain (LLVM codegen) does not support the Xtensa architecture (opaque CPU features), but it is possible to use riscv32 for esp32 from the C2/C3/C6, H2 and the new P4 release. I'm currently working on a fork of the zig toolchain with espressif-LLVM to support Xtensa.[1] It is now possible to test with esp-idf instead of microzig for baremetal (Blink) yet. [1] https://gist.github.com/kassane/7bdb782a1984d0c6581ae7b44e1fc0c2 https://gist.github.com/kassane/7bdb782a1984d0c6581ae7b44e1f...
- 22c 3y agoYeah 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 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.
- kassane 3y agoSo don't wait. Tarballs already available for testing[1] and an example using esp-idf.[2] [1]: https://github.com/kassane/zig-espressif-bootstrap/releases https://github.com/kassane/zig-espressif-bootstrap/releases [2]: https://github.com/kassane/zig-esp-idf-sample https://github.com/kassane/zig-esp-idf-sample
- roland35 3y agoI appreciate that zig is an easily searchable name for a programming language. You’d think after Java and python that’d we’d have better options, but no! Now there is Go, Rust, etc etc
- Ar-Curunir 3y agois it that much more difficult to append a `lang` after go, rust etc?
- roland35 3y agoThat works… sometimes. Just doing a quick search in the Rust book, 0 results for “rustlang”, 30+ results for “rust”.
- extraduder_ire 3y agoI do hope that someone balls this up into an arduino core so it can be used with the arduino IDEs, it even supports the atmega328P already. Purely for making it easy to try out without too much setup. e.g. click a button in the boards manager, and everything should just work. This saved my ass when I was able to switch to a third-party AVR core which allowed changing the clockspeed so I could have working serial on a chip running slower than 16mhz and get a demo out of an otherwise busted board.