Variegated Coffee

2024-09-17: Project log and status update

Posted on Sep 17, 2024

I’m introducing this new project log, in order to offer some transperancy into the work I’m doing. This first entry is going to be a little longer, but the plan is that going forward, I’ll aim to post an entry every other week or so, summarizing what’s happening in the project and where my focus is right now.

Let me know in the Discord if there’s anything in particular that you’re excited to hear more about.

Current Focus areas

  • Embassy compatible PIO implemented I2C
  • Serial bootloader (for OTA updates)
  • New pump mount for FG200/300/400 pumps
  • New load cell drip tray grate design for Lelit Bianca

Recent findings

Gicar 9.0.25.02G

I’ve recently had the opportunity to play around with a Gicar manufactured flow sensor, a Gicar 9.0.25.02G, which I’m intending to install into my Rancilio Siliva. The flow meter expects 5V power supply, and sadly doesn’t do too well with a 3.3V supply. It’s designed for 5V CMOS logic levels, so with a 5V supply, \(V_{OH}\) is at 3.6V. Undervolting it with a 3.3V supply, \(V_{OH}\) is at about 1.8V. Passing 3.6V into a RP2040 pin should be fine (the absolute maximum rating is IOVDD + 0.5), but it’s a little too close for comfort, and because the minimum \(V_{IH}\) at IOVDD = 3.3V is 2V, 1.8 V would be undefined.

On the positive side, a FG Filter board should be able to handle the level shifting splendidly.

Some notes on the current project status

Circuit boards

I’m actively looking in to the usefulness of using an RP2350 instead of a RP2040 in both the All-Purpose Espresso Controller and in the Open LCC. At the moment it’s mostly at the thought-experiment stage, for a number of reasons:

  • The RP2350 isn’t available to order as a plain IC
  • Library support in Embassy (and in he Embedded Rust ecosystem in general) isn’t mature yet
  • The RP2350-E9 errata is a little annoying, so I’m hoping for a new stepping which fixes this issue.

The RP2350 does bring some advantages, with more power, more GPIO, PSRAM compatibility and 5V tolerant IO pins, so it is an interesting upgrade from the RP2040. The general concept would be to replace the RP2040 with the more powerful RP2350, and meanwhile replace the ESP32-S3 with the less powerful but cheaper and Zigbee/Thread compatible ESP32-C6.

Obviously the RP2350 and the ESP32-C6 are different microcontrollers than the RP2040 and ESP32-S3 respectively, but they are similar enough to their counterparts that most of the code written for one of them can be easily ported to the other. In fact, given proper library support, most code should just need a recompile.

In a sense, this would mean standardizing on the RP2 and ESP32 platforms rather than the RP2040 and ESP32-S3 specifically.

This does hinge on being able to drive a reasonanbly sized display from the RP2350, so that is something that I’m investigating.

The time frame for any new revision of the APEC is that it’s at least 6-12 months away. I want to really flesh out what, if any, sort of limitations on firmware development the current R0D/R1A revision imposes before making a new hardware revision.

As for the Open LCC, I am planning a new revision of that too, but the time frame is TBD. I want to get rid of the debug board, and move the USB connector and SWD connection onto the board itself.

I’ve also had the opportunity to test the Gravity R2A board, and it seems to be working great, so that’s exciting.

Firmware

The Rust firmware project is going well but slow. Several IC driver crates are nearing stability, and should be able to be published on Crates.io within the not too distant future. Since these are some of the first things I wrote in Rust, I will be giving them a once-over first though, and I will try to see what, if anything can be ported to embedded-hal-async, instead of depending on embassy-rp.

At the moment I’m writing some of the more complicated crates; a serial bootloader to be able to update the RP2040 firmware using the ESP32-S3, and a PIO I2C driver for the embassy-rp HAL, in order to allow the use of two NAU7802 ICs simultaneously on the Gravity, while still allowing one of the hardware I2C channels to be dedicated to communicating with the APEC or Open LCC.

Firmware architecture

I’d also like to take this opportunity to write a little bit about the architecture of the new Rust-based firmware. Considering the bredth of hardware-accessory-machine combinations I want to support, I’m going for more of a build-your-own-firmware kit rather than a single firmware.

At its lower levels, there are drivers for ICs like the ADS124S08 or the FDC1004, a PIO frequency counter, a PID algorithm crate, and similar crates. The basic building blocks of an espresso machine firmware. All of them are made for use with Embassy.

One middle layer is a generic controller library, with a standardized closed control loop; 1. Read sensors, 2. Run one or more controllers, 3. Update actuators, as well as a mechanism to change settings and to expose the machine state.

Another middle layer (and this one is particularily up in the air since I discovered the assign_resouces! crate) is board definitions, to handle that different boards have different pin assignments.

The top layer is the machine definition. This is the actual runnable executable. For a standardized setup, like using the Open LCC in a Lelit Bianca, this can be an entirely pre-made firmware, but if you’re using the All-purpose Espresso Controller, you’ll need to write your own machine definition.

Espresso Machines and other hardware

The current goal is to get the APEC into my old Rancilio Silvia. I’m still waiting on some fittings, but I hope to have everything assembled in a week or two. This will allow me start actually using the hardware and firmware in a real machine.

I’ll also be creating a new pump mount as well as a new revision of my load cell drip tray grate. The Silvia needs a lower pump mount than my current hacked-together solution if I want to be able to fully assemble it, and if I have to have custom parts made, I might as well make sure the fit the Bianca as well.

Once I’ve used the Silvia for a month or two, my hope is that I’ll have the firmwares ready enough to install a FG pump, the APEC, some pressure transducers and a flow sensor in my Bianca. My plan is to initially have the APEC emulate the Gicar board protocol, and then start moving over the Open LCC firmware to the Rust code base.