I just put the finishing touches on the initial PD Buddy Sink console configuration interface. It's based on the ChibiOS command shell, but with some changes I feel make it much nicer. First, it has PD Buddy branding, rather than the ChibiOS branding the original had. The help text has been improved, providing a short synopsis for each command rather than simply a list of commands. There's also no way to exit the shell, because I really don't know why that would be necessary in this application. After all, when you're done configuring the Sink and your changes have been written to flash, there's no harm done by just unplugging it.

The new code has been pushed to the main firmware repository. This brings the PD Buddy Sink much closer to being fully functional, so I'm really happy about it. Next, I think I'll work on the GUI before returning to the firmware.

Some implementation details follow, as well as next steps for the firmware.

As is common with Cortex-M microcontrollers, there's no EEPROM here, only flash. That means the configuration has to be stored somewhere in flash, so the last page makes sense to me. Only a few bytes of flash are needed to store the configuration, but since I had to reserve a whole 2 KiB page for it anyway, I figured I might as well go ahead and do some wear leveling. The page is used as an array of 128 structs, each beginning with a magic value indicating its status. An empty struct is identified by the magic value 0xFFFF (naturally), the one that currently stores the configuration is identified by 0xBEEF, and old ones that aren't being used right now are 0x0000. As the configuration is updated, the page fills from low to high addresses, until eventually it's completely full. Then on the next update, it's automatically erased before the new configuration is written. The flash in the STM32F0s is rated at a minimum of 10k cycles, so with my wear leveling, the Sink can be configured at least 1,280,000 times before the flash might wear out. That should be far more than anyone ever needs.

There's enough space left over in the struct for a few new features as well, but they're not implemented yet. One half-word is set aside for flags, which will eventually include at least whether we should enable GiveBack and whether we can get power from batteries and variable power supplies. GiveBack support would allow the power supply to temporarily remove power if another device needs extra power, and would be mostly useful in the PD Buddy Sink for battery charging applications. Support for drawing power from batteries and variable supplies requires specifying a voltage range, and they will be lower priority than fixed supplies.

(N.B. "Variable supply" in USB PD parlance is really just a euphemism for "poorly regulated supply", not the kind of variable power supply you're probably thinking of. For those, USB PD 3.0 support is needed, and they're called "programmable". I'm not aware of any programmable USB PD power supplies on the market yet, but if I've just missed them, please let me know!)