Arduino sketch for TFT display rendering using serial commands

I've been using a Seeed Studio Wio Terminal as an external display for a Raspberry Pi. I initially wrote an Arduino sketch that took high level, application-specific commands over serial and rendered appropriate display elements. This has the disadvantage that adding UI features required updating the Arduino code, which is more of a pain and slower to iterate on.

Instead, I'm now planning on sending rendering commands over the serial interface - turning the microcontroller into a general purpose rendering device.

I've thrown my initial code up on GitHub here:

github.com/mikeoliphant/SerialTFT

It currently only supports a small set of commands for rendering rectangles and text. I'll be adding more features as I need them.

Speeding up Arduino TFT (TFT_eSPI) writes

 I've been recently playing around with "Arduino" microcontroller stuff - specifically a Seeed Studio Wio Terminal.

Playing around with the TFT display, I noticed that drawing to it was pretty slow. After doing some research, I found out that direct TFT writes are indeed quite slow. But there is an easy way around it.

The TFT_eSPI graphics library, a modified version of which is used by the Wio Terminal, provides a Sprite class that can be used to do quick TFT writes. If you have enough memory (which the Wio Terminal *just* barely does), you can create a full screen-sized sprite.

The Sprite class supports the same drawing API as the main TFT class, so it is pretty easy to convert code that is writing directly to the TFT to use a Sprite instead.

To initialize it, do this:

TFT_eSPI tft = TFT_eSPI();

TFT_eSprite screen = TFT_eSprite(&tft);

In your setup(), after initializing the TFT, do this:

screen.createSprite(tft.width(), tft.height());

Then, use "screen" instead of "tft" for all of your drawing calls. When you want to update the TFT with the current state of your sprite, do this:

 screen.pushSprite(0, 0);

That's it! The result is a display that will update *much* faster.

One caveat is that this method uses up the vast majority of the Wio Terminal's RAM. It works fine for me, since my application is not otherwise particularly memory hungry. More complicated applications (using WiFi, for example) may run into problems. If that happens, a good (if more complicated) solution would be to use a smaller screen area sprite and do targeted writes to sub-areas of the screen.