Follow me down the optimization rabbit hole

Intro I'm working on a new PCB project with a SSD1306 128x64 OLED display and was curious to try using 3-wire SPI mode. It's not a new subject for me, but I wanted to try using it to gain speed rather than have it slow things down (e.g. bit banging the protocol). Some background information is required before I share the project details. Small Displays Small displays like the SSD1306 and color LCDs like the ST7789 from Sitronix support updating their internal display RAM over a serial (SPI) connection. The display controllers understand "commands" and pixel data. The commands serve to configure the controller and move the write pointer (where the pixel data gets written). In order to know if incoming serial data should be interpreted as commands or pixels, the controllers have a D/C (data/command) signal. This can either be a separate signal wire or encoded into the data stream. When it's a separate signal, this is referred to as "4-wire SPI". The 4 wire...

Background Monochrome liquid crystal displays have been in existence for many years. The original use case was for super low power segmented displays on calculators and watches. Each display segment was directly controlled by the microcontroller and required a tiny bit of power to hold it in the 'on' state. Over time, APA (all points addressable) aka dot matrix displays were created to show images and more complex data. The traditional method of creating a dot matrix LCD display is to have a dedicated controller (simple MCU), RAM and a communications interface. This is how almost all modern dot matrix LCDs are made (see Sitronix LCD controllers). This allows for very high resolution displays to be managed with a simpler command interface and the dedicated controller chip is responsible for scanning the rows and columns to keep the LCD pixels current with the RAM contents. Dedicated dot matrix LCD controllers simplify utilizing these displays in products, but they come at a cos...

Intro Most of my previous posts have been focused on software topics. I'm going to stray a little into hardware for this article. At the end of 2022 I made a promise to myself to learn how to use KiCad so that I could design my own printed circuit boards. I have some experience with electronics and I thought that I could design some relatively simple PCBs for my own use. I found this 100 minute YouTube tutorial and it provided enough practical info to get me started. This blog post is not about learning KiCad; instead I'm going to walk through all of the steps and equipment necessary to build my Pocket CO2 sensor project. The KiCad files and firmware can be found here . (SMD) Surface Mount Soldering is Easy? After seeing videos of professional makers such as Seon "Unexpected Maker" Rozenblum use pick-n-place machines to build complex PCB boards with impossibly small components, I wrongly assumed that SMD soldering required expensive equipment and lots of expertise. ...

  The "CO2" Project By Larry Bank Environmental sensing and air quality have always been fascinating to study. I've tested various sensors over the years that, until recently, cost next to nothing. The COVID pandemic increased my curiosity (and concern) about indoor air quality, CO2 levels, and shared air. In the past, I tried to save some money and use the "eCO2" value from several inexpensive sensors, but the results were unreliable and unsatisfying. eCO2 is an "equivalent CO2" value generated by some VOC ( volatile organic compound ) sensors. The idea is that human breath contains lots of VOCs and if you detect them, you're also detecting CO2. The flaw in this thinking is that a lot of other things generate VOCs and have nothing to do with CO2. A good example of a false positive is food preparation. Bring your VOC sensor into the kitchen when you're cooking and it will tell you that the air has a toxic level of "eCO2". I've bee...

Background In addition to code and power efficiency challenges, I occasionally find other challenges that attract me. Not long ago I started working with Aaron Christophel on his various electronic shelf label and e-paper projects. One of the ideas I had was to put more autonomy in the MCU boards controlling price labels so that they could do more than just receive images wirelessly from a server. The original project used a price label with an ARM MCU and plenty of RAM. I was able to run my TIFF G4 decoder on it and have the entire resulting image in RAM before sending it to the e-paper display: The MCUs in Aaron's more recent (and larger) collection of devices contain an 8051-type CPU with limited FLASH space and a much more limited amount of RAM. I thought it would be a good challenge to see how much independent functionality (text/GFX) I could run on those 8-bit CPUs. The Problem Let's start with an example e-paper display - a 2.9" black and white with 128x296 pixels....

Intro I've been fascinated with pixels and digital displays as long as I can remember (a very long time). Over the last few years, I've written and published a few libraries for microcontrollers to talk to various types of low cost displays. I'm constantly adding support for more displays, but lately I've been focused on making my code easier to use. I've had my share of frustrations connecting and using all of these displays, so I can sympathize with people who are new to microcontrollers. The point of this blog post is to help you avoid many of these frustrations. Start from the beginning Choosing the right display for your project is a subject for another blog post, instead let's address a few of the common impediments to having things just work.  Here are a few sources of frustration: Voltage / signal mismatch Solderless breadboard flaky connections I2C/SPI wiring problems I2C/SPI bus initialization problems Voltage / signal mismatch For many years, 'Ar...