Variegated Coffee

2024-10-05: Slow flow

Posted on Oct 5, 2024

First up, I wanted to loop back regarding the discussion of the Flow sensor from the last post. I was able to get ahold of two Digmesa Nano-brass flow sensors. They’re quite a bit nicer than the Gicar flow sensor. They’re a lot smaller, have a wide operating voltage (\(2.8 - 24.0 V_{DC}\)), and they’re open collector, rather than CMOS or TTL, so they’re quite easy to interface.

The good people of W.E. Coffee have also been looking in to the Sensirion SLF3S-4000B, which is an awesome sensor. Sadly, it’s using barbed fittings, which makes it inappropriate for being on the high-pressure side of a pump. If it’s used with a tank, you can just put it on the low pressure side, but if you (like me) are using a Flo-jet (or line pressure), it’s just not an option. An interesting sensor nonetheless.

Current focus areas

  • OTA flashing the RP2040 via the ESP32-S3
  • variegated-board
  • Restructuring the variegated-rs repository(/ies)

Progress since last update

Side note: Dev rig work

I have two espesso machines at home, a Lelit Bianca (with an Open LCC) that is my daily driver, and a Rancilio Silvia, which is my Variegated dev rig.

Right now the Silvia is partially disassembled and there are wires everywhere. My overall plan for my machines is this:

  1. Get to a state where I can close up the case and put everything inside
  2. Develop the APEC firmwares, testing things out
  3. Put an APEC in the Bianca
  4. Move the Open LCC firmwares over to Rust
  5. Put a gear pump in the Bianca (and additional sensors)

I may switch 4 and 5, but this is the general plan. There’s also the Gravity, which I’ll slot in somewhere in here.

These past weeks I’ve finished up the plumbing work on the Silvia. The next steps is to get to a point where I don’t need physical access to the APEC board to work on the firmware (i.e. OTA updates), put the board in an enclosure, wire everything up, and close up the Silvia.

Rust firmware - variegated-board

Initially I had an idea of publishing a separate crate as a kind of board support package for that particular board, but over time, I’ve realized that is overly cumbersome, especially with regards to setting up the interrupt vector table.

As an example, when running as a controller, I want to use a particular UART bus asyncronously, but in the bootloader program, I want it to be buffered. I want which UART (i.e. UART0 or UART1) I’m using to be configurable, and the asynchronous and buffered UARTs have different interrupt handlers.

Instead I’m working on a different, and I think better, solution. The plan is for pin configurations to be made in a TOML file. That TOML file is the parsed at compile time into cfg attributes, which in turn is used to split up the Peripherals and generate type aliases.

This has the additional benefit of simplifying configuration for something like the APEC, where you might have different pin mappings for the same board in different machines.

I’m taking a lot of inspiration from other crates in the Rust ecosystem here. First and foremost, there’s the assign-resources crate, which is the Embassy-recommended way of splitting up the peripherals. There’s also a Procedural Overhaul PR that I’m looking a lot at (since this will be a procedural macro).

As a side-note, that PR was spun off into a separate crate, but that crate is GPL-3 licensed, which is incompatible with the MIT license used in the Variegated firmware, and as such, that’s not a crate that I’m looking at.

There’s also the more general toml-cfg crate, which allows you to configure anything const.

ESP32-S3 firmware adventures

Up until now I’ve been very focussed on the RP2040 firmware. This has actually been the case even before I started moving to Rust; the current ESP32-S3 firmware is actually based on ESPHome, just because it’s a convenient way to get started.

Getting started with ESP32 development on Rust has been an… interesting process. Basically, you have two options, esp-idf-hal or esp-hal. Both of these have distinct quirks, and I’m still not entirely sure which to use.

The main advantage to using esp-idf-hal is that you get access to the ESP IDF services. Things like their HTTP Server/Client, MQTT, Websockets. Nice-to-haves, basically. More importantly, you also get access to the ESP-IDF OTA mechanism. For the things like HTTP servers, I’d rather use embassy-net, and from my experiments, that doesn’t play too nicely with esp-idf-hal. Esp-hal is a lot slimmer, it’s no_std (esp-idf-hal is std), which to be honest is kind of nice when your device has 512K of on-chip RAM (I don’t want frivolous allocations).

On the other hand, I really don’t want to have to write my own OTA mechanism.

I’m also not in love with the Xtensa support for Rust. Being a tier 3 target, Xtensa isn’t a part of standard Rust builds (as opposed to Armv6-M, Armv8-M and RiscV32 IMAC, which are all tier 2 targets), which means you have install an entirely separate toolchain to build Xtensa firmwares.

At any rate, getting the ESP32-S3 on the APEC up an running is one of my current priorities, since that’s one of the major next steps to getting my dev rig closed up.

Upcoming repository split

Right now there’s a single variegated-rs repository. It’s a workspace repository so it contains multiple crates with both binaries and libraries. I’ve come to the decision to split that up.

The idea is to keep variegated-rs for the libraries, but to split out all the binaries to separate repositories. The reason is quite simple. When I started adding ESP32 targets, it suddenly got a lot more cumbersome to work with the workspace, because the binaries have different and incompatible targets (not to mention toolchains).

Some libraries (like variegated-board) will also get its own repository (because it’s a procedural macro), but those are exceptions.

New revision of Gravity - R2B

I’ve made a new revision of the Gravity board. Thus far, it’s an unproduced revision, but it is a minor revision. The changes are adding a Raspberry Pi 3-pin Debug connector (in addition to the ARM 10-pin connector), adding the ability (via solder jumper) to switch one of the NAU7801s to I2C0 (which is otherwise usually reserved for upstream connection), and some additional test points.