Follow me down the optimization rabbit hole

Introduction E-paper displays come in many forms, both in terms of size and how the pixels are controlled. For this article I'm going to focus on the less expensive serial interface type (SPI bus) which have a built-in controller (COG = chip on glass) and come with their own framebuffer memory. Since the panel itself has the necessary memory to hold all of the pixels it displays, it's possible to do quite a lot without needing any RAM on the MCU side. For those familiar with OLED displays like the popular 128x64 SSD1306, the memory of these e-paper panels can be managed in a similar way. Bufferless Limitations Working without a local copy of the graphics presents some challenges. You can define a memory window (a smaller rectangle of the display) of any number of bytes (not pixels). This means that in one direction, you only have access to 8 pixels at a time, since the memory planes are each 1-bit per pixel, packed 8 to a byte. Some e-paper controllers allow you to read the con...

Intro This is a brief first look at an idea I've been ruminating on for along time. Actually, it's two ideas - tweaking CCITT Group4 (T.6) image compression and compressing font data for use on microcontrollers. Why do either of these things occupy space in my head? CCITT Group 4 Many years ago, a standard was created for the digital FAX machine. It specified not only the audio transmission method over POTS , but also a new bitonal, lossless digital image compression scheme. The 3rd meeting of these experts (Group3) created a one-dimensional run-length encoding scheme using statistical coding (Huffman) to shrink the most common run lengths for black text on a white background. Not long afterwards, at a 4th meeting, some clever person/people added a 2D component to it to take advantage of similarities between the current line and the one above it. They called this Group 4 compression The compression ratio increased quite a bit (up to 20:1), but so did the complexity of the code...

Intro For a client project I was asked to collect samples from an IMU at a high rate. For practical reasons, we chose the Seeed Studio Xiao nRF52840 Sense  as a prototyping platform. It has a Nordic nRF52840 64MHz Cortex-M4 with a STMicro LSM6DS3 6-axis IMU on board (and digital microphone). The cost, size, and ready made product made it a natural choice to get started with the project. The IMU consists of a 3-axis accelerometer and 3-axis gyroscope. For our use case, we only need one axis of accelerometer for vibration detection. It has a built-in 8K FIFO capable of collecting the samples at a high rate (up to 3200 samples/sec). This sample rate was most likely designed for use with the SPI interface (we'll soon see why this is the case).  I2C Speed Limit? The I2C interface of the LSM6DS3 can probably run much faster than its stated max of 400Kb/s, but with the nRF52 series, we're basically stuck with that as the top speed because the I2C clock can't be set higher (based o...

A few years ago, a Chinese electronics vendor (Sunton) started selling an inexpensive PCB with a ESP32 module, QVGA touchscreen LCD display, microSD card slot and (misconfigured) audio amplifier. More recently, these boards have branched out into a large collection of permutations of ESP32 MCU + LCD that has been collectively called the "Cheap Yellow Display" because of the PCB solder mask color and low price. Due to the variations in the display types, GPIO connections and MCUs, one program can't be used on all of them without significant modifications. I've been collecting and testing these boards and have tried to make life easier for people using them by adding the unique configuration info into my bb_spi_lcd library. The Frustrations Let me back up a bit and describe what I'm trying to fix. The LCD displays used on these boards are generally supported by multiple Arduino libraries, but in order to use them you need to know the display type, GPIO connections a...