2025-04-26: An addendum on timelines

One question that has come up in the Discord lately is the project timeline. Looking at this project as someone who’s just found it, this is of course one of the most interesting questions, yet it is a hard one to answer. At the moment, and for the forseeable future, Variegated Coffee is a hobby project. The amount of time I can and am willing to commit to the project is going to depend a lot on what else is going on in my life.

For this reason I am both unwilling and unable to commit to a timeline, but that being said, I do have an ambitional timeline. One of the reasons I’m doing this project is simply because I want to be able to use it in my own espresso machines, and I do have some idea of when I want to be able to do that.

Because of that, let me break down my ambitional timelines a little. As you’ve probably already figured out, this is entirely subject to change or slippage, and I won’t be updating this project log entry if that happens. This is just as it stands as of the time of writing.

Hardware

Open LCC

Not too much to say here. As I mentioned in a previous entry I do have a long term plan to A) remove the need for the debug board and B) standardize on EyeSPI for the display connector. Because this isn’t so much a functional update, it does have a low priority, and as such, it’s unlikely to happen this year. Let’s call this 2026+.

Gravity

I’ve been experimenting with adding battery support on the optional back side. Thus far it’s been difficult, due to the compact nature of the board and me not wanting to route things too close to the analog section. Adding layers and/or using microvias could be an option, but of course adding layers increase the price, and JLCPCB (which I typically use for manufacturing) don’t support microvias yet (they are planning to though). As of right now, this is on ice.

APEC SoM

This is the interesting one, isn’t it? As I mentioned in my previous entry, I have ordered carrier boards to be able to start validating the EV1 boards more extensively. I have also secured components to be able to do a 20 board EV2 run, but - due to that run being fairly expensive - I don’t want to have that run built until I’m very confident that I’m not going to find any further issues in the EV1 run.

EV1 validation

As such, the next step for APEC SoM hardware is twofold. First off, I am going to try my hand at 0201 rework, to switch to stronger pull-downs (as mentioned in the previous entry) on an EV1 board. In addition, because the WPU values of the ESP32-C6 aren’t specified in the datasheet (and as such subject to change), I may also consider changing the FET to one with a higher \(V_{gs(th)}\) just to give myself more headroom. This too is something I’d test out by reworking EV1 boards. This is something that I will (be attempting to) do in the near future. We’re talking weeks, not months.

Secondly, I am going to be building my carrier boards and use them for some firmware development. The Dev Rig carriers (along with the Femtoprobe) are currently on their way from China, and should be arriving next week. Of course, waiting for the boards (or even assembling the carrier) isn’t the major time sink here - it’s the development work. My ambition is to have a firmware that kinda-sorta works (and thus can work to validate the EV1 revision) for the Dev Rig some time in Q2.

I was also able to increase component size on the Bianca carrier, so I also went ahead and ordered those boards (as unassembled PCBs). The dev rig doesn’t have any capacitive water level probe, so I also intend to use the Bianca carrier to validate the capacitive sensing some more. This will also give me more of an indication as to what sort of parasitic capacitance I can expect. While the Bianca carriers aren’t arriving at the same time as the Dev Rig carriers, the timeline here is the same - some time in Q2.

This likely means that the EV2 run is going to be produced some time late Q2 or early Q3.

After EV2

As for the future after the EV2 run - I am unsure. It depends on a couple of different variables. One of them is the community interest in the board, and another is upcoming RP2350B steppings. EV1 has been, and EV2 will be produced using the A2 stepping of the RP2350B, which contains the somewhat dreaded E9 erratum. My assessment is that E9 shouldn’t matter too much in an espresso machine. It does mean that if you want pull-downs on GPIO pins, you should add discrete components for that instead of relying on the GPIO pad’s pull-down, but pull-downs are by far less common than pull-ups. This being said, any further production run after EV2 will wait for a new RP2350B stepping. Raspberry Pi has provided no timeline for a new stepping, but I have a feeling they’ll be moving faster than me anyway.

As I said another important factor is the community interest in the board. As of right now, all of the plans are for engineering samples. If there is a lot of interest in the board, I may start looking for a partner to productize the board (I’m unlikely to do that myself). That being said, there are significant costs associated with productizing a board like the APEC SoM, specifically in terms of compliance, so the interest would have to be large.

Of course, even if the board isn’t productized, it is still open source, and you can still produce your own boards (at your own risk) and use those.

Firmware

Enough hardware, let’s talk firmware. As I’ve written about previously, the next generation of Variegated Coffee firmware is written in Rust, using the Embassy framework. One of the major advantages with Rust compared to something like C or C++ is the Cargo package system. This allows for a substantial amount of code reuse between projects, and is what is going to allow for two entirely different espresso machines, with different peripherals, different carrier boards and different IO assignments to still share a substantial amount of firmware code.

Indeed, even a firmware for something like the Open LCC will be able to share a substantial amount of code with the firmware for a controller based on the APEC SoM.

This being a hobby project, the firmware (and the matching crates) will essentially be written in lock-step with the projects it’s supporting. As such, the plans for the firmware essentially match the plans for the hardware, with a few notable exceptions.

Current state of the Rust firmware

We actually have one released and “stable” package, variegated-board-cfg! I use the word stable in quotes, because it is technically version 0.2, so BC breaks are possible. To quote the docs, “the idea of (variegated-board-cfg) is to be able to store pin and peripheral configration in a config file, and then use that configuration to split the Peripherals struct into smaller, more purpose-built structs.” Due to this being a proc-macro, it lives not only in its own crate (which is natural), but in its own repository.

As for the other crates, they all live in the variegated-rs repo. That repo is definitely not stable, and in fact, in my local repo I’ve been going on a bit of a cleaning-and-upgrade spree. A few of the packages in the repo are going away, and those that remain will be upgraded for Embassy 0.4.0. Most notably, anything to do with board definitions are going away. Instead, board configuration should be handled using variegated-board-cfg. Once the crates start to become more and more stable, I will be tagging them and uploading them to crates.io.

Looking at the future

Once I get the Dev Rig board set up, I will be writing enough firmware to get that working. This includes a new basic firmware architecture. I’m not particularily happy with the general design of variegated-controller-lib. I don’t have any concrete plans on how to fix it, but I have some loose ideas.

Once the basic architecture is there, there’s already enough supporting crates (for e.g. the ADS124S08 and the FDC1004) that I should be able to have a basic firmware put together fairly easily. As for the timeline (and as mentioned above), I’m hoping for something at least a little usable some time towards the end of Q2. Of course, even after I have something a little usable, there’s a matter of making it even more usable. Things like a UI (the dev rig has a display and a rotary encoder) and proper integration with the ESP32-C6.

Also in the near-term future, I’m hoping to get a more 1.0-ish firmware for the Gravity, which right now is closer to that “somewhat usable” stage. Since I want to use the Gravity in at least the Bianca, and possibly even in the Dev Rig, that’s gonna have to change. Hoping for Q3 for this one.

Of course, I haven’t forgotten the Open LCC here. One major long-ish term goal for variegated-rs is to have feature parity with the C++ based Open LCC firmware. I’m hoping this could be sometime towards the end of 2025. At that point I’m going to be writing a Rust-based firmware for the Open LCC, which I’m hoping to help Open LCC users transition to.