[HN Gopher] MicroZig: Unified abstraction layer and HAL for Zig ...
___________________________________________________________________
MicroZig: Unified abstraction layer and HAL for Zig on several
microcontrollers
Author : homarp
Score : 162 points
Date : 2024-02-28 17:14 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| nippoo wrote:
| The 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 wrote:
| fyi 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/
| the__alchemist wrote:
| 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.
| KallDrexx wrote:
| 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.
| MatthiasPortzel wrote:
| I 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 wrote:
| I 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 wrote:
| I'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.
| Cyberdog wrote:
| I 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 wrote:
| In 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 wrote:
| 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.
| Cyberdog wrote:
| 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.
| jakewins wrote:
| Agreed! I've similarly had good experiences with Rust on the
| rp2040, using embassy which builds on the rust HALs.
| KerrAvon wrote:
| God, yes. Ruby is also at least somewhat usable in the space,
| FWIW; I've done RPi hacking with it in the past.
| cnln wrote:
| I 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
| dang wrote:
| That'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 wrote:
| Great, thanks!
| unwind wrote:
| Meta: you have typod the name of the microcontroller as
| _RP4020_ twice, might be worth fixing. Nice post,
| otherwise!
|
| Edit: typos, ironically. Mobile phone text editing ~ftw.
| cnln wrote:
| Thanks, I'll fix that
| sgt wrote:
| Isn't it better just to repost with a query parameter like
| ?foobar ?
| dang wrote:
| Oh 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 wrote:
| You know what you doing! Move Zig for great justice.
| just_steve_h wrote:
| YOU HAVE NO CHANCE TO SURVIVE MAKE YOUR TIME
| spiritplumber wrote:
| Are there any plans to put this on the Parallax Propeller as
| well?
| UncleOxidant wrote:
| Are there similar efforts for other languages? Or could this be a
| starting point for a language-neutral, multi-
| board/microcontroller HAL?
| skybrian wrote:
| There 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 wrote:
| 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.
| TimSchumann wrote:
| Word on the street is the badges at the next Software You Can
| Love conference will be running this.
| jeff_ciesielski wrote:
| 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 wrote:
| > _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"
___________________________________________________________________
(page generated 2024-02-28 23:00 UTC)