A Grab Bag of PETI Updates

Last Updated: 2025-10-20 00:00:00 -0500

I’m usually the first to admit that the transition from late summer into autumn is one of my least productive periods of the year. This isn’t to say I’m doing nothing, but it’s a time when my thoughts tend toward gathering rather than producing. This is (after spring), the season for tidying, and laying in the “winter store” of inspirations and plans that will get me through what hopefully will be a minimally unpleasant time. That said, quite apart from what was said back in June, I have actually had odd time, in between workplace service calls or in the weird hours of the morning, to think through some problems with PETI and how you’d solve them if, for some reason, you wanted to keep going on a major project you’d left half-finished.

Improvements in the Development Environment

A bit of an obstacle to getting PETI going again has been a growing distate for spending any more time than is absolutely necessary in the space I’ve come to think of as “the lab”. My lab, such as it currently is, is a third or so of a very small second-bedroom in my apartment, and this cramped and usually disorganized space is also the environment from which I “do the needful” for my day job. Accordingly, come the evening and afternoon, I usually avoid coming back up here if I don’t have to. The problem is, though, that PETI is a firmware development project, and I need access to the development kit hardware to do much more than modify the documentation. This lead me to contemplate two possible solutions:

Build an Emulator, which is both extremely doable and a massive lift. Perhaps surprisingly, there’s no stock emulator floating around for the MSP420FR5994, and even if there were, we’d still have to wrap a whole whack of “peripheral” interpretation logic around the system. I put some thought into it, and if that core emulator existed, it would have been worthwhile. It would be extremely convenient to me personally (and to hypothetical future code contributors) to have an emulator they could run builds against. That could even be a stepping stone into some automated testing.
Better Development Hardware. The current development kit hardware in circulation is what we’ve been calling the “Revision C” kit (due to the revision of the back-board component of the dev kit). It’s not without its flaws, so much so that I’ve been talking about a possible revision D now for at least a year. Most of these flaws, I thought, were logistical, but the more I’ve spent time with the Dev Kit, and the harder I’ve thought about it, the more I realize that, actually, it’s a big problem.

Ultimately, what I’ve decided to do is to pursue a redesign of the development kit in parallel to continuing the firmware development. The Rev C kit is “portable enough”, but designing a better version of the kit would really liberate the development process.

The “Single Board Development Kit”

So, the current avenue of progress on the PETI project has become the pursuit of this new design development kit: the SBDK, I’ve been calling it. The idea is simple:

Simplify the design of the development kit hardware to make it more robust
Make these new kits sturdy enough for “backpack carry”
???
Enjoy working on the project from my couch, kitchen table, or out and about.

And, of course, to talk myself into it: by using the Single Board Development Kit it’s now easier for a hypothetical Developer to obtain the hardware, move around with the hardware, and generally Have Fun Designing The Software.

Why Single Board?

The current development kit (Rev C.), as well as the past-postulated “Rev D”, design, was actually going to use three accessory boards on top of the TI “Launchpad” that made up the core of the pet:

A TI “Booster Pack” that hosts the Sharp mLCD display
A somewhat-sketchy “controller” board of my design, and
The PETI “Backplane”.

By switching to a single-board design, I’m hoping to solve a few problems:

Easier assembly for the Developer (if ordering as a self-assembled kit) or Myself (since I do the assemblies)
Mechanically-sturdier design (for slinging in a backpack or what-have-you for moving it around)
Minimal Part Ordering - the ability for me to sell the maximum number of the project’s components in a single kit, and have a developer need to seperately order just the TI Launchpad.

Why not Single Board? (Problems in the SBDK Project)

Of course, if this was necessarily simple, I would have done this in the first place, right? Designing a development kit currently distributed across several boards, all designed and manufactured in different ways, is a fun and exciting new challenge, which also means it’s sort of untested territory. I have problems to solve I haven’t currently considered:

Power Management
Part Pitches and Selection
Addressing Unsolved Problems from the Revision C Design

SBDK Power Management: Won’t somebody help me budget this amperage, my batteries are dying?

Currently, since I’m not making many changes to the codebase, a lot of my time spent with PETI is spent trying to play with it as though it were an actual toy. There’s just one problem: it doesn’t stay in operation long.

When I equip with with a pair of rechargable AA NiMH batteries, I get around “an afternoon” of playtime out of it. This is in part because my batteries are pretty old and well-used. On spec, I’d get about 55 hours out of it, but… that’s still not really enough playtime for a charge, is it?

This means I have a few questions I need to answer:

What individual components are most responsible for power drain?
Based on that information, is there anything we can do from the firmware side to lower standby power drain?
If not, what alternatives do we have?

This becomes a massive sidequest when it comes time to develop the new SBDK, doesn’t it? I don’t particularly want to get all tooled up to make a dozen of these development kits if I’m once again baking into hardware technical problems I have the opportunity to solve now. While the development kit isn’t meant to be run like the eventual standalone toy, it’s not unreasonable to want similar performance out of it. If the best I can do is “roughly a weekend” on a single pair of AA batteries (which are already much higher capacity than the button cells I was hoping to use in the final toy design), we are miles away from “solved” when it comes to power. If I can’t get the power consumption down, I need to get the onboard power storage up, or consider the possibility of in-situ charging, a capability I considered years ago and abandoned for its complexity.

And all of these things require repeated experimentation in breaking out existing circuits onto breadboards to take in-situ current draw readings while the device is operating under various firmware states, so it will be by no means a matter of whiteboarding the problem for a couple afternoons. It’s probable any work I do on PETI for the rest of the year is consumed with these three questions.

Size Matters: Technology and Pitch in New Parts

As I alluded to earlier, space becomes all the more at a premium if I take the approach of trying to re-create the current footprint of the backboard, but with all the desired functionality of the other accessory boards on-board with it. This is all the truer depending on other choices I make in selecting parts. Currently, all the PETI development kits are using almost entirely “through-hole” components, a choice I made as much for my ease and comfort in assembly as I did out of concern for the same in end users. THT parts are cheap, easy to place correctly, and easy to solder down. However, they occupy much more physical space.

Somewhere along the way I have to decide how much of that technology to replace with “surface mount” parts that simply float on a pad. This allows taking a more double-sided approach to the board design, and to be honest, is more in line with modern manufacture methods. SMD was always the direction the final toy version of the toy was going go in, but that was never intended to be end-user assemblable.

This is purely a “design for manufacture” problem with no immediately correct answer, and I need a larger peer group to discuss it with before I made a decision.

This question was actually the original impetus for looking at the battery problems: the AA battery holder is too big to include in an SBDK design without making that single board physically larger (in terms of footprint) than it already is. That still might be what we have to do, but I want that decision to be made in a considered, thoughtful way.

Unsolved Problems

Revision C was already retired almost before it became available to others. That’s why only the original manufacturing run of five pairs of the boards were ever sold on our Tindie Shop: the intent was always to almost immediately replace it with Revision D. The Revision D design already includes two changes from the revision C board other than minor tweaks to the layout:

A wholly different audio signalling circuit, using a simple transistor like an amplifier to play PWM audio, and;
A different pack of setting-selection switches that eliminated an unused 4th switch from the design for the sake of efficiency.

But these aren’t really the only areas for improvement in the board as a circuit. For example, it would be supremely convenient if the board could also mate over the “ez-FET” jumper headers on the TI Launchpad. That would let us build in some simple safety circuits to stop the battery power from trying to drive the ez-FET side of the launchpad’s board, which it doesn’t really have the “juice” to do. Setting that up the right way around could make switching from USB to onboard battery power as easy as unplugging the micro-USB programming cable from the device.

Ongoing Firmware Development

There’s still an active-ish branch of firmware development and there are still dozens of features left to be implemented in the toy. In theory, if this was the only thing to occupy my time, I could easily work on PETI hardware and PETI firmware roughly in parallel. The headspace needed to write good code and to solve problems in copper are two different headspaces.

In practice though, I have a day job, and one that involves (decreasing, but still significant) amounts of solving technical problems, so it’s unlikely I pick the firmware back up until I’ve solved at least enough of the hardware problems I’ve left myself out. For certain, I don’t think I’d release a 1.0 version of the firmware until the SBDK exists, at least in terms of being a set of workable schematics. Technically the version of the toy I have now is perfectly adequate for developing in the living room instead of the lab. In practice, the short battery life and cumbersome nature of the toy means it’s not well suited to play testing, which the game desperately needs more of between major firmware revisions.

So we’ll see. Either way, let me know what you think in the comments below.

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.