It might be nicer to start constructing a framed protocol from the beginning so we don't have to deal with heads exploding from arbitrary complexity.

I propose a framing similar to [s3g/x3g](https://github.com/makerbot/s3g/blob/master/doc/s3gProtocol.md#packet-formats) as well as using actual binary data rather than confusing-as-hell ASCII-decimal.

| Offset |  Description |
|---------|-----------------|
| 0x00  | Frame start - constant 0xAD |
| 0x02  | Message length - 0x00-0xFF With the upper bound being unlikely |
| 0x03... | Data. Starting at byte 0x03 and for N bytes |
| 0x03+N | Checksum ([CRC8](https://github.com/whpthomas/GPX/blob/master/gpx.c#L633-L672) or something) |

Then treating the `message` part of the frame as

| Offset | Description |
|---------|----------------|
| 0x00  | Operation |
| 0x01+ | Args |

Potentially using something like this to set an individual LED to red at `(5, 5)`

| Offset | Value | Description |
|---------|---------|----------------|
| 0x00    | 0xAD  | Start  |
| 0x01    | 0x04   | Length of message |
| 0x02    | 0x01   | Set LED State |
| 0x03    | 0x05   | X position 5 |
| 0x04    | 0x05   | Y position 5 |
| 0x05    | 0x01   | Color value in LSB, 0x01 red, 0x02 green, 0x04 blue |
| 0x06   |  0x??   | CRC8 checksum, or not, whatever. |

It's a bit noisy, but at a marginally sane baud rate a full-screen of data would take ~2.5KB, and we shouldn't be sending those very often, and can probably find a more dense format to pack it in when we do. And we end up with a "protocol" that we can add messages to without having to worry about as much.