A library to support SSD1680/1 e-paper displays on I2C, using a I2C-SPI Bridge.
This library is based heavily on the SparkFun Qwiic OLED Arduino Library and includes the same fonts and graphics support.
It has been tested on the GoodDisplay GDEY0154D67 1.54" (200 x 200) and GDEM0097T61 0.97" (184 x 88) e-paper displays.
The I2C to SPI Bridge is configured as a I2C peripheral with five registers: Single Control (Register 0x00), Control (Register 0x01), Data (Register 0x02), Final Data (Register 0x03) and Reset (Register 0x04).
- A single control byte written to Register 0x00 is bridged to SPI with the D/C# pin held low. CS returns high after the write.
- All data written to Register 0x01 is bridged to SPI with the D/C# pin held low. CS remains low after the write.
- All data written to Register 0x02 is bridged to SPI with the D/C# pin held high. CS remains low after the write.
- All data written to Register 0x03 is bridged to SPI with the D/C# pin held high. CS returns high after the write.
- A write to Register 0x04 causes RST to be pulled low briefly.
- I2C reads return bytes containing the e-paper BUSY flag in the LSB.
The MSP430FR2433 and STM32G03 folders contain example I2C-SPI Bridge firmware, tested on the:
- TI MSP430FR2433 on the MSP-EXP430FR2433 dev board (using TI Code Composer Studio)
- ST STM32G031K8T6 on the NUCLEO-G031K8 dev board (using the Arduino IDE and the STM32 Arduino Board package)
- ST STM32G030F6P6 on a generic dev board (using the Arduino IDE and the STM32 Arduino Board package)
In the above demo animated gif, the hardware is:
- SparkFun Thing Plus - ESP32 WROOM (USB-C)
- Running Example04_184x88_Rotated_Clock
- Connected via Qwiic (Wire) to:
- A generic "STM32G030F6P6 Mini Development System Board" - available from online retailers
- Running the STM32G030_I2C_SPI_Bridge
- Programmed using an ST-Link V2 programmer and STM32CubeProgrammer software
- The GoodDisplay DESPI-C02-CV0097 0.97 inch e-paper 24-Pin to 18-Pin adapter board
- Set the sense resistance switch to 2.2 Ohm
- The GoodDisplay GDEM0097T61 0.97 inch e-paper display
Please see WIRING for the connections
- /MSP430FR2433 - Example I2C-SPI Bridge firmware for the TI MSP430FR2433
- /STM32G03 - Example I2C-SPI Bridge firmware for the ST STM32G030F6P6 and STM32G031K8T6
- /examples - Example code
- /src - Source code
- Wiring - wiring for STM32 programming and display adapter connections
- GitHub Repo - TODO: Update URL and description
- Hookup Guide - TODO: Update URL and description
The GoodDisplay GDEY0154D67 (1.54", 200 x 200, SSD1681) and GDEM0097T61 (0.97", 184 x 88, SSD1680) e-paper displays both use SSD168x Ping-Pong Mode. If you read the OTP Display Option using command 0x2D, you will find that Bit 6 of Byte F is set, indicating ping-pong mode is enabled. We believe this is to allow the displays to better support partial updates. The RAM banks are used to identify which pixels have changed from the previous update. It causes some interesting issues...
If you 'clear' the display - (e.g.) set all the pixels white and do a full update - the white pixels are written to both BW RAM and RED RAM. GoodDisplay calls this the "BaseMap" or "background color function". If you then set a group of pixels black and do a partial update, those pixels are displayed - as you would expect. If you then set a different group of pixels black and do a second partial update, only the second group are displayed - the first group are hidden. If you then set a third group of pixels black and do a third partial update, the first and third groups are displayed - the second group is hidden. We believe this is caused by the SSD168x "ping-pong" mode - automatic switching of the RAM banks.
One solution is to re-write all pixels before each partial update. But that takes time - especially over I2C.
This library is based on the concept of "dirty pixels". Only pixel areas which have actually changed are written to the display. This means the ping-pong mode can cause some interesting 'blinking' or 'flashing' effects.
Our solution is to record which group(s) of pixels have changed for the current partial update, and to record which group(s) were changed during the previous partial update. The "dirty pixel" areas are expanded to cover both the latest changes (m_pageState) and the previous changes (m_pagePrevious).
This product is open source!
Please review the LICENSE.md file for license information.
If you have any questions or concerns on licensing, please contact technical support on our SparkFun forums.
Distributed as-is; no warranty is given.
- Your friends at SparkFun.