Lab Notes: Autumn Cleaning Edition
Last Updated: 2021-12-01 05:00:00 -0600
What’s it been, the better part of a month? Three weeks? Time flies. A lot has happened around the lab in those three weeks: PETI got a new version, I broke some stuff, and I fixed some stuff. Hop in to see the full update.
PETI v 0.0.6: The “Display, But the Way We Meant It” Update
During the last post, I talked about wanting to do a refactor of the PETI codebase to eliminate some magic numbers and alleviate a condition that existed only in my mind - I thought we were a lot closer to the memory limit for RAM than we actually were. Oops.
One of those items, in particular, was:
Fixing the DisplayFrame. Currently every scene instantiates its own DisplayFrame object. At about a hundred bytes a piece, reducing these all to one shared DisplayFrame object (as was the original intent) will reclaim a lot of memory.
This actually mis-stated the problem, and it relied on another false assumption - that I understood the differences between how display.c implemented
DisplayFrame and what was actually intended.
DisplayFramestructs are a single struct that contain strings (in the sense of arrays of
char) that tell the display what to do.
DisplayFramestructs are a struct of magically-named
pointersto those arrays.
This, and not the stated duplication of display frame objects, was actually the memory consumption problem. In spotting it, I was able to fairly extensively rewrite both the struct itself and the functions that consume it, such that we now no longer need to manually compute refreshes, and that the whole object is effectively iterable. This is a general purpose post so I won’t get into the specifics - you can read about the structs and their usage here. So far this change has saved about 400 Bytes of operating RAM. Once the current demo mode (the last legacy scene on the old structure) is either refactored or removed, we’ll save about 200 more. This is not counting the additional efficiencies in FRAM from being able to eliminate the much more complex older print and display functions from the codebase once they are no longer needed, though we also aren’t anywhere near exhausting the FRAM capacity of the device either.
This was the bulk of my november - playing with this and redocumenting. The next nicremental update, 0.0.7, will be the first gameplay update, implementing the hunger system which I’ve only got a vague specification for and a few floating ideas.
GOTO 10: Measure Never, Order Twice
The other big update where PETI is concerned is a mistake I made. I took the previously-designed daughter boards for PETI - the “Rear Expansion Board” that adds the battery, speakers, alert LEDs and some other hardware - and made a few updates to make sure that they matched the circuits as tested on the Loaner Device, then ordered them through a new-to-me-vendor, PCBWay.
I want to stress right up front that I’m very impressed with PCBWay. My turnaround was about a week order-to-door for ten boards with, frankly, really decent build quality for prototypes. I had a wide choice of features including solder mask color, treatment materials, and so on. What happened is absolutely not their fault.
That being said, I ordered the parts with the same 1.1mm pitch header connectors I accidentially used on the first iteration of the control daughterboards. As a result, these ones are scrap. Earlier this week on my weekly lab live stream I redesigned the back boards and will be ordering them in short order.
Never one to waste an opportunity, though, I’ve been offering the Limited Edition Revision A PETI Rear Expansion Board Collector Card as a collector’s piece, only five ever made. Three are spoken for, but two are still available at the time of writing.
I’m still assembling a cost list as well but the size of my board orders is due in part to the desire of other people to own development kits for PETI. Of the development kits, I will also have two available for sale that aren’t accounted for. If you’re interested in getting involved with that, drop me a line. I’m selling them more or less at my cost to produce, plus shipping, and I can send them out to you as a DIY kit, fully assembled, and with your choice of with or without the TI components.
End of an Era: Polaris is No More
Polaris is (was, I suppose) a ~12-year-old Acer Aspire laptop that served as the primary web-facing server in my lab environment. Via a network of containerized nonsense, it served as the primary webserver for a bunch of functions the Lab provided, such as this website, the (now outdated) Sanity Line website, several individual mediawiki instances, and a few internal-only things, such as the development constructs for Whizzbang.
Recently it had been acting increasingly flaky - the network interface would occasionally die, requiring a power cycle to come back up, and over the last couple days it was also just flat out powering down at random intervals, with syslog not being much help. Given its internals were not the best, and its age, last night I decided to put it out to pasture.
We’ve replaced it with Corvus, the former workstation-laptop that got me through the entire development of Tapestry and many other technical projects early on. She’s got her own problems, but I’m confident I’ve worked around most of them. Over the coming days, I’ll slowly bring other functions that Polaris used to provide back online, time and good mood providing.
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.