====== Addition notes on Arduino displays ======

These are relevant only to my various and changing needs, so you maybe ignore this?

====== Suitable for AVR ======

===== Graphic LCDs =====

**1.54%%"%% 128x64 FSTN** ([[https://www.buydisplay.com/1-54-inch-white-128x64-graphic-lcd-display-module-spi-for-arduino|this]]) with 30 and 46 size fonts using the 4-wire SPI interface is **acceptable**. The illumination is even, the angles are good, the update speed is good and the artifacts are acceptable. The contrast could be better, but it's not a deal-breaker.

**2.9%%"%% 128x64 FSTN display** (probably [[https://www.buydisplay.com/3-3v-5v-graphic-display-128x64-serial-lcd-display-st7920|this]]) with large double digits is a **tad too slow** with a 24 size font using the 4-bit interface. It may be acceptable with smaller fonts. Another pain point is the manual adjustment of contrast -- with a trimmer that doesn't inspire confidence. ★ Is SPI faster?

**2.9%%"%% 128x64 STN display** (probably [[https://www.buydisplay.com/lcd-display-serial-graphic-display-128x64-st7920-white-on-blue|this]]) with large double digits had **too many artifacts**. It may also be too slow using the 4-bit interface.

★  Order and test other candidates?

===== Character LCDs =====
There are three challenges with using character displays.

The first challenge is finding a **display with good appearance**, esp. when the display updates. The inexpensive one I tried doesn't look good enough when switching. [[https://www.buydisplay.com/3-3v-or-5v-lcd-module-16x2-1602-character-display-i2c-arduino-wide-view|This]] or [[https://www.buydisplay.com/arduino-code-lcd-20x4-i2c-character-display-module-wide-view-angle|this]] might be good though.

The second challenge is adapting a **library to implement BigFont/BigCrystal** with I2C or serial register. I seemed to get close by adapting BigCrystal to LiquidCrystal_PCF8574, but it's not working (yet?).

One idea to address the above is to create a **dedicated controller** that has a parallel connection for the LCD and an SPI or other serial receiver that accepts data to render. The formatting and display of the data would be handled by the controller.

The final challenge is whether BigFont/BigCrystal is aesthetically acceptable.

====== Other Microcontrollers ======

There are lots of TFT displays that experience has shown look good and with something like a [[arduino:stm32_blue_pill|Blue Pill]] fast enough. Whether this is a workable solution depends on whether the [[https://github.com/olikraus/ucglib|ucglib library]] works with a core that supports the microcontroller. ''Ucglib'' doesn't seem to document what boards it supports, so experimentation and some hope that updates won't bork things is the only way to do.

Candidate μCs are covered below.

===== STM32/BluePill =====

Using Roger Clarke's now unsupported [[https://github.com/rogerclarkmelbourne/Arduino_STM32|Arduino_STM32]] core works with a modified ''ucglib''. The required modifications are described in [[https://github.com/olikraus/ucglib/issues/87/|this]] bug report. Specifically: 

> In order to add support for stm32duino platforms the following definition is needed:
><code cpp>
#if defined(__arm__)
#ifndef __NOP
#define __NOP __asm volatile ("nop")
#endif
#endif
</code>Adding the definition to the file ''Ucglib.c'' worked with a maple mini clone and a ST7735 TFT:<code cpp>Ucglib_ST7735_18x128x160_HWSPI ucg(/cd=/ PA2 , /cs=/ PA4, /reset=/ PA3);</code>

The [[https://github.com/stm32duino|STM32duino]] project still seems to be active, but I have not tested ''ucglib'' with it.

 ★ Work needs to be done here to see whether the unmodified or modified ''ucglib'' works with the STM32duino core. 

===== RP2040 =====

There are two different cores that let you use the RP2040: [[https://blog.arduino.cc/2021/04/27/arduino-mbed-core-for-rp2040-boards/|Arduino Mbed Core for RP2040 boards]] is an official Arduino project, but it kinda seems Earle Philhower's [[https://github.com/earlephilhower/arduino-pico|arduino-pico]] gets more attention.

★ Work needs to be done here to see which is the more promising option.

==== ESP32 ====

ESP32 support in Arduino has a long history. But standard boards don't really seem to exist, and it's not clear whether s/w disabling BT and WiFi is good enough. I think working through the previous two options first is the more promising path.