Major check-in of a lot of code used to support the 108-module display at Code:ART 2021. Big changes:
Add new chainlinkBase build target
Implement BaseSupervisorTask which monitors and controls all the Chainlink Base-specific electronics: master power relay, power channel load switches and voltage/current monitors
Updated display code to make it easier to define a module layout algorithm depending on how you arrange modules plugged into each Chainlink Driver
Major rewrite of serial interface
Moved serial interface out of SplitflapTask
Created SerialLegacyJsonProtocol to maintain backwards compatibility and provide a simple plaintext/json control interface for basic control and debugging
Started migrating some JSON generation to use json11 instead of hand-constructed strings (remnants of the original Arduino Uno code)
Created SerialProtoProtocol which is the next-gen serial interface:
Messages (in both directions) are protobuf, and encoding/decoding on the ESP32 is done via nanopb with type-safe code generation
Framing is COBS (PacketSerial library) along with a CRC32 checksum wrapping the protobuf data
2 types of control messages to the splitflap are supported:
SplitflapCommand - basic control of each module to either no-op, move to a flap index, or reset and home. This is simple, as you do not need to remember/re-send the positions you've set previously, but it's not ideal for programmatic control since you cannot idempotently set the state of all modules (if you send a GO_TO_FLAP again, the module will do a full rotation). Higher level nonces allow these to be retried safely, but you can get out of sync between what you think is showing and what is actually showing if you are not careful to retry every non-acked packet or if the controller restarts for any reason.
SplitflapConfig - this is the recommended and fully idempotent control message. It includes the desired state of every module, and uses additional nonces to allow for commanding a full-rotation back to the same flap or re-homing a module. It is not possible to get out of sync with the splitflap controller this way even if you don't retry non-acked packets (any dropped packet would simply be ignored, by you'll get back in sync the next time a SplitflapConfig packet is received successfully)
(this protobuf interface is currently disabled in code, until a mechanism for switching from legacy to proto is implemented, but it is fully functional if enabled)
Created UartStream based on ESP32 uart driver to replace the standard Arduino Serial implementation which uses a hardcoded small rx buffer that prevented reliable receipt of large protobuf packets at high baud rates
New software to interface with the splitflap controller from a computer:
Typescript library (software/js/splitflapjs) using protobufjs to send and receive data
Provides basic encoding and decoding of protobuf state messages and command/config messages, with a callback interface to listen to data from the controller
Handles limited queueing/retries in case messages are not received/acked by the splitflap controller
Typescript example (software/js/example) of how to use the typescript library to run some simple animations
Python library using standard protobuf-generated data types (incomplete and not well tested yet)
Major check-in of a lot of code used to support the 108-module display at Code:ART 2021. Big changes: