Yet Another Display Refactor Post
Last Updated: 2022-02-11 09:00:00 -0600
It’s not necessarily what you’d expect me to be working on in the weeks immediately following getting my hands on the prototypes of the rear expansion board, but it turns out that implementing at least a proof-of-concept version of the alert drivers took about four hours, and I’m ready to move on to something that was done wrong the last time it was implemented; the display refactor. Click through to the full article for some details.
Such Alert Primative, So Blinkenlights, Much Beep
I’ve talked before about the flaws in the PETI Rear Expansion Board RevB, but I got so hung up on them that I never really had the chance to talk to you about the things that have gone right, which was virtually everything else about the board design besides the voltage control being entirely absent.
Among those things were two delightful little devices that serve as the hardware basis for PETI’s ability to get your attention - the Alerts System. One of the on-board LEDs, intended to be blue, is set aside specifically for acting as a visual alert mechanism, and there is a small piezoelectric speaker that operates at a fixed pitch.
I implemented some primitives for the firmware - as well as what I can only describe as an Alerts API (which functions as a wrapper to the primitives) that permits a few basic functions: light the LED, clear it, and play either a single long beep or a single short beep. For the version 0.1.0
hardware, which is the intended firmware to go out with the first round of orderable dev kits, this is all that will be implemented, but I have plans for both LED patterns and audio “tunes” (which will still be fixed to one note).
These primitives also obey the state of a hardware switch to determine if the speaker should be able to play, and eventually the settings menu will contain an options to control if the audio is muted or not. All of this took the better part of maybe 5 hours to implement and test, and it’s sufficiently primative that the planned enhancements should be able to be built directly atop it instead of requiring a full refactor. For once.
So What’s This About A Display Refactor?
Back in November, I talked about having done a display refactor that happened to coincide with the last actual version release, 0.0.6
. The refactor universalized most of the print functions into one single parent print API that took in a bunch of special arguments to use a general set of code, making scene development easier because it could all be done in structure definitions rather than implementing a bunch of special handling, and optimizing our use of the limited RAM available to us. At the end of that refactor, I mentioned that no effort was made to refactor the current Demo mode, and for good reason: I planned to retire it rather than refactoring it.
For obvious reasons, I wanted the debug menu enhancements I had planned to be included in 0.1.0
. People shouldn’t have to dive into the internals and flash fresh firmware just to test things, right? Part of those debug menu enhancements was the ability to set the STAGE_ID value to anything I want, and by doing this, I’ve effectively recreated the only feature of Demo Mode that mattered; the ability to view animations for any stage of the Pet’s life.
Since that’s now working I can throw demo mode overboard completely, and retire all the deprecated display code. This is the perfect excuse to do a second refactor to the code to allow for multiple fonts to be used for each text size. This will effectively remove the available “sprites” cap in each font by raising it to the theoretical limit of the FRAM on the device, which is about 2 MB if I am recalling correctly.
This can be achieved by “multiplexing” font addresses into the directives argugments, so there’s no added complexity on that score, or at least no added memory consumption. Where we might get ourselves into trouble is in needing to define what font is being referenced in certain data structures like Stage definitions and Food definitions.
This might create a mess down the road from a code generation perspective but in the short term it’s probably an even lighter lift than the original display refactor, and that itself only took a weekend to figure out, so I’m going to include this refactor in 0.1.0 as well.
Development Kit Timeline
I effectively only have that display refactor and a few minor bugfixes left to do before 0.1.0 is mostly validated, but that doesn’t mean I can make the development kit available straight away. As we’ve seen, I’m pretty bad at this hardware design stuff, and I can’t even guarantee that the next round of development kit boards will be any better.
So here’s my plan. By the middle of march (or so, maybe early april) I want to have ordered the parts for, and done breadboard validation of, the power management changes. If that’s successful, which I anticipate it will be, I’ll go ahead and order in a set of “revision C” boards by may.
And if those are good, I’ll take “prototype” off the silk screen, solve some logitics problems, finish the manuals, and offer these for sale starting around August.
So, stay tuned for updates!
PETI is a major project intended to design and construct a virtual pet from Open Source Hardware and Software, and to encourage others to modify and tinker with similar projects. If you would like to support the development of this, or any of the other projects I’m working on for Arcana Labs, and you wanted to show your support financially, your best avenue is via my Github Sponsors account or by making a one-time donation to Arcana Labs via Ko-Fi.com or through other avenues detailed here. Github Sponsors also get access to a special patrons-only section of the Arcana Labs Discord Server, where we talk about the ongoing super-secret project.