Softer Side of Darwin

As Bradley mentioned in his debut post, sometimes you gotta build something to really understand how to build that thing the right way. Unfortunately, it’s not at all uncommon with software to find that the version that was written as a prototype to get user feedback and prove a concept ends up being the animal that you take with you into production. All software developers are familiar with the terror of feeling like they’re building an airplane while it’s flying.

During the 2018 field season I maintained a fairly long running list of things that I wanted from the firmware that weren’t critical enough to implement but would be incredibly useful as the platform matured. The two most important where:

1. A very slick and flexible firmware upgrade process that was as end-user friendly as possible – from the beginning. The latter part is very important, because this means we could distribute stations to friends and family and be testing and supporting them. I started this work and mentioned it in early blog posts, but there were still some significant gaps, most notably in how the firmware was compiled and run that made certain upgrades tricky. Also, I desperately wanted the ability to upgrade from our mobile app.
2. Actual tasks/threads as part of a minimal real-time operating system. A lot of work and effort was expended with the first version of the firmware trying to make tasks non-blocking and asynchronous so that multiple systems could be “active” and cooperate while running concurrently. This made many things more complex than necessary and therefore, more brittle.

A side effect of deciding to overhaul the microcontroller situation was an opportunity to make significant improvements to the firmware. I can’t stress how happy I was the first time I ran code on the SAMD51 and saw that I had more than 256k of RAM at my disposal. Life on the SAMD21 was getting extremely cramped and I didn’t feel like I had the room to do the kinds of things I really wanted. Not just from a RAM perspective. The SAMD21 has 256k of FLASH memory and with the architectural changes around modules this simply wouldn’t be enough to work comfortably going forward.

Because the modules no longer had their own microcontrollers, the firmware to drive those had to live on the core SAMD51.

On that chip we have 1MB of flash memory, ignoring the QSPI memory Bradley added. This was more than enough room to store additional module firmware for our first modules.

In the beginning, the module firmware would simply be compiled into the core firmware as a kind of super-binary. Long term, this would need to be handled in a more flexible way, for a few reasons:

1. FieldKit is a modular system that is intended to grow beyond the offering we are able to anticipate, so the firmware handling situation needs to allow firmware from sources other than Conservify and the initial FieldKit team.
2. Upgraded module firmware needed to be possible, independent of the core firmware.
3. Modularity means that over time it will become impossible for all firmware for all available modules to live on a single device, so juggling and maintaining that firmware becomes the responsibility of the core firmware preinstalled on the hardware.

So, while I waited patiently for the new hardware I started to lay the foundation for these things. I spent a considerable amount of time at home writing some small, focused libraries to deliver on this extra functionality. Oh, and yes testing on Adafruit’s Grand Central M4 🙂