tmc5240

I wrote a Zephyr driver over the past week or two for the tmc5240 (Perry's project). It speaks SPI, adheres to a new stepper API Perry is involved with, and provides device-specific functionality such as pipelined SPI transactions, full register load/dump, and a Kconfig-urable shadow register file.

I did this to help Perry out and because he's offered to give me access to some of his boards, which look like a good test and demo platform for interstice.

zephyr reflections

It's basically like Linux kernel dev. Everything is Kconfig, it's based on device tree, the functions look POSIX-y (all of this intentionally, I'm sure). This is nice in that the API and general conventions are known / comparable, but not-so-nice in that the knowledge barrier is huge and implicit. Yes, there are manuals to rtf, but they're really there to guide you on the presumption that you're already mostly familiar with the environment. For embedded, having consistent abstractions and not a vendor hal is great. Device-tree remains a lesser evil.

I'm glad I did this to see what it's like, and I think if you're writing embedded C in anger, Zephyr's probably one of the absolute best options. I probably wont pick it up for a personal project, though, unless I'm armtwisted into it (e.g. if I really need the nRF Connect SDK) — Rust is just too expressive by comparison, especially for the kinds of things I have planned on embedded. I think I could have written this driver in substantially less than half the time in Rust, with better ergonomics, and for a non-vendor-locked interface abstraction (embedded_hal_async::spi::SpiDevice).