OneVariable Newsletter - 2021-12-15
2021-12-15🥳🥳🥳 Hardware has arrived! 🥳🥳🥳
This article was originally featured on the OneVariable Applied Research newsletter. If you'd like to get early access to these reports, you can sign up for the newsletter here. Newsletter emails are sent every Wednesday.
Articles are posted on my blog one week after appearing on the newsletter.
Abstract and Results
The most exciting news this week: The Powerbus Mini hardware and expansion cards arrived!
I've started setting up the firmware project, and validating the main hardware components.
This weeks newsletter is full of fun progress pictures :). If you're new to Powerbus, you can read a project summary here from my first newsletter.
Powerbus Mini and Extension Boards
![Semi-populated circuit boards showing the Powerbus Mini and extension board](../images/nwsltr-2021-12-15-1.jpg)
So far I've been focusing on the main board, and have successfully tested:
- Basic MCU programming and debug
- The internal and external RGB LEDs
- The 5V USB-C power input
- The INA180-based current usage sensor
So far so good, with a few small notes for improvement in the next revision. I've only assembled one board, but I think it looks pretty slick!
Assembled Powerbus Mini
![A fully populated Powerbus Mini board](../images/nwsltr-2021-12-15-2.jpg)
First Blinky Lights (internal and external)
![A Powerbus Mini board with connected external LED string, with on-board and external LEDs lit](../images/nwsltr-2021-12-15-3.png)
I've also been working hard on the software side of things, merging many of the components from the Powerbus repository into a new binary project specific for the Powerbus Mini.
I plan to keep all of the reusable software components in the public Anachro Powerbus repository, though I'll be keeping the main firmware project private until a later date.
defmt-bbq: Look ma, no debugger!
I also got inspired to implement defmt-bbq, a global logger for the Knurling-rs defmt logging framework.
Typically, defmt logs are sent using RTT, an SWD (debugging interface) based transport. However, I plan to send device logs over the RS-485 instead. By placing the logs into a queue, I can instead send them out over the Anachro network without being attached to a debugger.
Oops, I forgot one pull-up resistor
![A close-up of the Powerbus Mini PCB, showing a through-hole resistor bodged on top of the memory chip](../images/nwsltr-2021-12-15-4.jpg)
As a test, I wrote an implementation of defmt-bbq that logs messages over the nRF52840's USB port. This implementation lives in the examples folder of the defmt-bbq repository.
Powerbus Cases
I'm still waiting on the laser-cut cases for Powerbus, but I dropped off the material last week, and they should be here before the end of the week. Stay tuned for more pictures of fully assembled boards with cases in next week's newsletter!
Background Information
Previously, I did write most of a prototype bootloader implementation for Powerbus, though this was tricky, as it was based only on the internal flash of the nRF52840, which causes the processor to freeze while erasing or writing sections.
In order to avoid this problem, and to allow a firmware image to use the whole 1MiB of the internal flash, I've included a 16MiB external QSPI flash chip on the board.
This external flash will be used for storing firmware update images, non-volatile settings, and compiled A4 scripts.
This will probably require writing an anachro-compatible QSPI driver, and moooostly rewriting the bootloader, but this is my next priority.
The combination of a bootloader and the ability to send logs over the network is a big and important step, as it will allow me to "deploy" devices around my house, without requiring to be attached to every device via a debugger.
The bootloader already has a couple of cool features, including poly1305 signatures, and the ability to automatically roll-back in case the update fails, either on a quick "immediate fault" condition, or on a slower "cannot connect to the network" fault condition.
This should lessen the likelihood of a bad update occurring, but at least for now, walking over with an SWD debugger shouldn't be TOO annoying, in the rare emergency cases. At least until the first one is mounted on my ceiling.
Suggestions for Future Research
Although the bootloader and QSPI driver are the highest priority, I'll very quickly want to have the full (or at least mostly working) Anachro network stack available to send and receive logs and firmware updates.
Initial work on updating the network stack has gone well, and luckily required less work than I thought it would! The previous network stack was AGGRESSIVELY zero copy, which required some really hard to work with lifetimes.
Luckily, most of the complicated code lived in the SPI-based transport layer, which I won't be using for Powerbus.
I've moved the network stack crates into a new repository, and will be integrating the network interfaces on top of my existing uarte-485 driver, which is what Powerbus will use.
The Anachro protocol is pretty transport-agnostic (mostly just sending and receiving raw frames, which uarte-485 already supports), so I don't expect any huge obstacles. Fingers crossed!
I'm also looking forward to working on the expansion boards, though that's lower on the priority list.
If you have any ideas for cool expansion boards, or any particular sensors or actuators you'd like to see, just reply to this email! I'd love to hear from you. Especially if you want to be an early Powerbus tester!
A quick request!
I'd super appreciate it if you could share this newsletter with other folks who are interested in hardware, tooling, or embedded Rust.
Sending it along in your favorite Discord or Slack channels, on Twitter or other social media, or just forwarding the email would help me out a lot!
If they are interested in subscribing (or if you had this forwarded to you), they can subscribe to the newsletter here! I also post these newsletters a week later on my blog, which has an RSS feed you can also subscribe to.
Thanks again for subscribing and following along :)