PETI Single-Board Dev Kit, Consumerism, and Unusual Delays
Last Updated: 2026-01-21 04:00:00 -0600
Last October, I took the time to share some updates about PETI, which at that point was more a project-in-concept than something I was hands-on-keyboard “working on”. That’s not really true anymore; over the last couple weeks, I’ve been actually working on our favourite virtual pet again. Specifically, on the new Single Board Development Kit (SBDK).
Gordian-Knotting the Battery Capacity Problem
One of my big concerns last October was whether or not I could reassemble the development kit in a way that all the various daughter cards currently part of the development kit could fit on one board with roughly the same footprint as the TI Launchpad that would form its brain. A big part of that concern came from the battery that drives the development kit.
The current Development Kit, with Revision C of the “backplane” board, uses a 2x AA cells-in-series battery to drive the toy. Since these are NiMH batteries, they provide about 2.4v DC for about 1200 mAh, and even with some care and attention paid to cutting certain circuits out of the flow when running on battery power, that wasn’t really enough to play “more than a day or so” of PETI. This made the obvious size solution - replace the AAs with button cells - undesirable, because any version of that I could pursue would (a) replace secondary recharagable cells with primary single-use cells and (b) lower the overall power capacity even further.
I spent multiple hours chasing possible efficiencies around the circuit in terms of the amperage only to come up with something that made me feel kind of unhappy: the only time the power draw is even remotely high anywhere on the toy is when an LED is flashing or for the brief moment that a button was being pressed.
Brief Sidebar: in the video linked above, I conclude without ever resolving something that was left as an open mystery: why disconnecting the LCD board lowers power consumption device-wide by 6 mA, even though I don’t actually measure that amount of current on any signal or power pin. During a later session, which is linked below, I make the discovery that one of the pins on the LCD panel happens to be tied directly to ground in the stock configuration of the toy. That pin is also a GPIO pin. I suspect the current fall is coming from the LCD no longer pulling a GPIO pin to ground, since the way I have that GPIO pin configured makes it a pull-up-resistor pin. 6 mA happens to be the rough maximum rating that the GPIO pins can provide for this microcontroller.
By the end of all my investigating I ultimately realized that there wasn’t going to be a change in firmware that would meaningfully lower power use, beyond possibly changing the timing and duty cycle of the LED flashes for the alert and low battery LEDs (which should probably also have their resistances increased). That meant I had a real problem: the AAs are too big for a single board design but no button cell existed that could even come close in capacity, even with many wired in parallel, without losing their advantage in compactness.
Enter, please, Lithium battery chemistry. Many lithium battery configurations exist with some real advantages here. For one, both Lithium Ion and Lithium Polymer batteries are rechargable, meaning that we don’t have to lose the advantage in waste management we had from working with NiMH. Second, most LiIon and LiPo cells that I can find output a voltage of 3.7v nominal. This means that even a battery with slightly less nominal capacity (in mAh) will last longer than the NiMH battery, because there’s a loss in capacity caused by stepping the 2.4v NiMH up to the 3v3 rail, whereas the lithium chemistry is actually stepping down. (Ohm’s law. It’s not just there to give your high school physics teacher something to make you memorize.)
Originally, PETI was going to explicitly have an integrated Lithium battery pack. It was 2019! Who ever heard of a toy that needed batteries? No no, you just plug that thing into the wall overnight while you weren’t using it anyway! As a beginner at this sort of thing, I had a healthy appreciation for Risk, so when I started to realize I was having difficulty fully understanding the circuitry needed to safely charge an on-board battery and regulate its voltage (all while managing the way voltage is being supplied to the toy, on top of which!), I balked. Let’s take the rechargable battery off the board, said I.
Well, I’ve talked myself back into it. This way, we can achieve parity or possibly even surpass the AA battery pack, if not in terms of actual electrical capacity, then in wall-clock uptime. And, if nothing else, we can just plug the darn thing in to charge it.
Restarting Schematics from Scratch
With that decision ‘made’ (for values of made), we could then set about the work of pulling the existing circuits knowledge from the RevA/C Development Kit and creating schematics for the new SBDK. This is the humbling exercise of going over all the pre-existing (and frankly horrendously drawn) schematics for the PETI Rear Expansion Board, the BOOSTXL-SHARP128 LCD module from TI, and the “control daughterboard”, breaking them all apart into their relevant circuits and schematics, and then recording those into a fresh KiCAD project. Most of that is incredibly straightforward, actually. I would argue that there are no complex circuits in PETI, which is where the humbling part comes in - this is 5+ years of my hard-won hobbyist EE experience and the most complicated circuits on the whole board are the pinout for the LCD header (which is just a bit of power, a bit of decoupling, and some SPI signal lines), or the pinout for the power converter (which we aren’t even keeping for the current redesign!).
Fully redrawing all the circuits we’re actually keeping from previous hardware revisions took about an hour and a half, and a goodly part of that hour and a half was the distraction of chat banter, or the occasional hiccup with KiCAD. From there though, the supposedly fun part - settling on a specific battery to use in the design so that we can pick an appropriate charging IC and an appropriate power management IC and start wiring together all the power circuitry, from the two battery terminals to the 3v3 and ground rails.
Sidebar again: I had a thought to possibly not bother designing the USB connection for the charging circuit at all on the SBDK but instead to use the 5v rail to supply the “charging” voltage to the battery charging portion of the circuit. This 5v rail comes from the 5v of the Ez-FET subsection of the launchpad board, which itself is supplied via USB. Why spec in a connector we don’t need?
The problem I ran into there is that for reasons currently passing my understanding, neither of the suppliers I normally turn to for components on these projects - DigiKey and Mouser - were willing to sell lithium batteries in Canada. Mouser explicitly says this when you look up the parts; in DigiKey’s case, they just appear as “unavailable in your currency”.
So now I’m kind of hung up on the problem of choosing the battery, which brings everything else to a crashing halt.
Where to Go from Here
While it’s unquestionable that Lithium chemistry batteries are hazardous to ship (as are, if we’re being honest, almost all batteries), I am not ecstatic about the leading solution to the problem of sourcing the battery - that is, ordering one (1) battery for myself at retail prices from somewhere, and building the spec around it. These are sort of a specialty good (not that the development kit isn’t), so there’s that problem. But also, the SBDK’s design considerations are all around “easy adoption” of the development kit by someone who wants to use this project as a launchpad to get into this kind of development. Eliminating the LCD module by moving the display onto the SBDK is explicitly about shortening the overall BOM for the new user. Making them responsible for buying a slightly exotic battery is not really progress.
The other problem is that it’s also just annoying. It’s patently absurd that almost any J Random Toy Manufacturer on Wish can ship you something with a battery in it, but for some reason I can’t.
Finding a supply of these batteries - possibly now from a vendor overseas (which, let’s face it, is where they were being manufactured anyway) is obviously the next step for hardware development on PETI, but hardware development on PETI isn’t only part of this project. The revision C development kit still exists, and I still own one.
So while I ruminate on battery choice, I’m going to keep working on firmware version 0.6.0, which is an update comprising of a more advanced evolution system that ties in with an all-new pet health system. I rather frustratingly stopped development in the middle of that update so I’m not entirely sure where the state of it stands, but that’s what git and notes are for.
And, in keeping with the new stream schedule, I will at the minimum be working on the pet in public on Tuesdays at 7 PM Atlantic/Halifax time on my Twitch livestreams.
PETI is an ongoing project to develop a 90s-style virtual pet using mostly modern microcontrollers and other hardware. It’s one of Arcana Labs’ longest-running projects, and the project materials have been available as FOSS and OSHW (to the limitations of licensing agreements with other vendors) since the project’s beginning. For over 5 years at this point, the project has largely been a one-person passion project to make a particular object exist, and in doing so hopefully do some small part to democratize that process. Your support of the project is greatly appreciated.