Follow me down the optimization rabbit hole

Intro DMA ( direct memory access ) is a topic that's similar to pointers in C - it's not easy for everyone to visualize how it works. My goal for this blog post is to explain, in the simplest way possible, how it works and why your project can benefit from proper use of it. What's it all about? DMA is a useful feature for a CPU/MCU to have because it means that data can move around without the CPU (your code) having to do the work. In other words, DMA can move a block of data from memory-to-memory, peripheral-to-memory or memory-to-peripheral independently from the CPU. For people used to programming multi-core CPUs with a multi-threaded operating system, that may not sound very special. For those of us familiar with programming slow, low power, single threaded, embedded processors, it can make quite a difference. Here's a practical example - sending data to an SPI device (e.g. a small LCD display): Without DMA <prepare data1 - 10ms > <send data1 to SPI - 10ms...

Intro Most of my blog posts share info about a general topic or highlight something interesting that I've discovered. This post will be essentially a tutorial or "how-to". Users of my display libraries probably know that they support Windows BMP files as a source of graphics. My latest eink libraries (both SPI and parallel - bb_epaper, FastEPD) both support this format in addition to a special lossless compression format I call Group5. It's challenging to describe in a few words what type of images will work correctly in both of these formats, so this article will walk through the steps needed to prepare graphics for eink projects. What's inside of the file? One of the first challenges of working with any image file format is that each file format can support quite a long list of different types of data within it. The two main variables are bit depth and compression options. Bit depth is probably the most confounding issue because it can be hidden in plain sight. ...

Intro We're all familiar with Kindle-type e-book readers. They've been around for enough years and have been copied by enough competitors that we've seen or used one over the last 10 years or so. What these devices have in common is that they make use of a high speed eink display which is controlled over a parallel data bus. These displays can handle 8 or 16-bits of data sent at up to (and beyond) 20MHz. This allows them to have very high resolution and support fast updates. What has typically been controlling these displays is a powerful 32 or 64-bit Arm processor running Android or Linux. People have made an effort to hack these devices to run their own code, but that path is not always practical or cost effective. How does parallel eink work? For people familiar with SPI epaper displays like the small ones found in supermarket shelf labels, the larger parallel ones work on the same principal. Charged pigment particles are suspended in a clear oil between two conductors a...

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...