8-cylinder TFT display

Sports car in disguise…

With its 8-bits parallel interface under the hood, this cheap MCUFriend 2.4″ TFT Arduino shield is like a V8 powered Aston Martin, disguised as a Volkswagen Beetle.
I wondered how fast an ESP32 could drive it, especially when using the TFT_eSPI library.

These popular 320×240 ili9341 TFT displays are usually equipped with an SPI interface, but the TFT_eSPI library supports their 8-bits parallel version as well. I adapted the corresponding user_setup file for wiring the shield to a LOLIN D32 Pro board (see below), connected the required 15 wires (including two power lines*) and ran the same benchmark sketch that I had previously used in this post. The result was quite impressive.

The complete benchmark test (without the final text loop) completes within 0.8 seconds!


The following table quantifies the considerable speed gain in comparison with the SPI version at 27 MHz and 40 MHz (no DMA).


Here’s my user_setup file for a LOLIN D32 Pro board. It leaves GPIO pins 16 & 17 (used by PSRAM on WROVER boards), standard SPI pins 18, 19 & 23 and UART0 pins 1 & 3 free.  Adding the line #define DMA_BUSY_CHECK fixed a compile error.


This is a great display for projects that require ultra fast screen updates and don’t mind spending 13 GPIO pins. Now I’ll go after the 3.5″ version with 480×320 pixels, hoping it will be less sensitive to solderless wiring than my HX8357D 3.5″ display in 8-bit mode.

* For my shield to work, I had to power its 5V pin from the ESP32’s 5V output pin.

Unripe (Ada)fruit?

I’ve always been an Adafruit fan, gladly supporting their open source contributions by buying their products. But recently, I was very disappointed by the bad performance of their TCA9548A 1-to-8 I2C Expander.

I had bought it to be able to drive two identical SH1106 OLED displays without having to solder on one of the displays in order to give it a different I2C address.

First I ran an I2C scanner, and the result looked promising: all connected I2C devices were detected with their correct I2C address. But then, driving a single display only worked if it was connected to channel 0 of the expander. And even then, the display would often show errors.

Then I tried a DS3231 Real Time Clock, because there’s very little I2C traffic involved in reading  the time from this simple and reliable chip. Even when connected to channel 0, setting the clock didn’t work well and readings of a correctly set clock were mostly  messed up. Since this expander seemed unable to reliably drive a single device, there was no sense in trying to connect multiple devices.

[UPDATE 15-01-2020] quite unexpectedly, I found the *solution* on an Adafruit forum! The multiple-sensor example sketch in Adafruit’s tutorial for this product misses an essential line. After putting the line Wire.begin() in setup(), that is: before the first call of tcaselect(), the module works fine! Wonder why they don’t correct this in their tutorial.


Mini MP3 Player

This little €4 module filled my entire weekend, mainly spent on finding the right documentation and a library that will work on Arduino, ESP8266 and ESP32. It’s a DFPlayer Mini MP3 Player from DFRobot (or, more likely, one of its many clones).

It can play MP3 and WAV files, stored on an SD card in the onboard card reader or from an attached USB drive. So far, I only tested MP3 files from SD.

You can connect one (4 Ω) speaker to the (quite impressive) onboard mono amplifier. Stereo line output is said to be provided on the DAC_R and DAC_L pins.

The main control method of this player is via commands over the module’s 9600 baud serial port. A subset of most commonly used commands can also be executed by means of two GPIO pins and/or two resistor-sensitive ‘ADKEY’ pins.

I made a false start by testing it on an ESP32 over hardware serial. That didn’t seem to work, so I tried an ESP8266 over software serial. That didn’t work either, and I had reached the point of giving up, assuming it was just another Chinese fake, when I gave it one more try on my good old Arduino Uno. With a quick & dirty 1K resistor for level shifting the module’s RX pin, the example sketch of one of many libraries finally made the little guy play me a song! In the end, it was the power supply that made the difference.

Some important things that I learned so far:

  • The module works best when powered by a stable 5 Volt. My Arduino Uno and Wemos D1 R2 could deliver it from their 5V pin, smaller ESP8266 and ESP32 boards couldn’t. In that case: use a separate 5 Volt power supply.
  • Wiring as suggested here caused a shutdown of my laptop’s usb port! I’m still searching for a way to connect the module to ESP32.
  • The module operates on 3.3 V logic level, so make sure to level shift the connection to the module’s RX pin when using a 5 V microcontoller.
  • Startup noise disappeared after I connected both GND pins from the player to ground.
  • Although it’s for a Flyron FN-M16P module, this excellent manual/datasheet has more and better written information than DFRobot’s own poorly translated summary. Apparently both modules use the same commands and probably have the same chip.
  • Getting stereo ouput from the DAC pins is still a problem. According to the manual, DAC is enabled on startup, but is it? Explicitely enabling it by sending 0x0000 to memory address 0x1A made no difference while sending 0x0001 instead (supposed to turn it off) started a terrible noise…
  • I tested quite some libraries from github, most of which have issues [update: starting sketches with delay(1000); solved most of them] and seem unnecessarily complicated to me. An exception is this simple and transparent library that is basically just a wrapper for sending serial commands. It can easily be extended with additional methods, even by unexperienced C++ programmers. You just have to lookup the command- and parameter bytes for the desired function in the datasheet and create a new function to send them (see example at the bottom of this page). [update: the author of the library has meanwhile added more commands]
  • The module has an SPK_1 and an SPK_2 pin, with a GND pin in between, which could suggest that it has a stereo amplifier. Although the documentation clearly says it’s mono, someone actually published a wiring diagram with two speakers connected. This person may own a different version of the module, but mine definitely has a mono amplifier. So the two wires of a single speaker should go to the SPK pins.

[ Wiring for Arduino Uno, with SoftSerial on pins 10 and 11; don’t forget the 1K resistor! ]


The location of files and their names is also very important because of the way commands address them. All information can be found in the datasheet, but here’s a summary:

  • The SD card’s maximum size is 32 GB. It must be FAT or FAT32 formatted.
  • There can be up to 3000 .mp3 (or .wav) files in the root directory of the SD card, named 0001.mp3 to 3000.mp3.
  • The root can have up to 99 subdirectories, named 01, 02, … 99. Each of these subdirectories can hold up to 255 files. Their names must start with 001, 002, … 255,  but you can append decriptive titles to these files, e.g. 007_James_Bond_Tune.mp3.
  • You can have a special subdirectory in the root named MP3. This can hold up to 3000 files, named 0001.mp3 to 3000.mp3.
  • You can also have a subdirecory ADVERT in the root. Special commands are available for making tracks in this folder interrupt currently playing tracks from the MP3 folder (for advertisement puposes). The rules for the MP3 subdirectory apply here as well.
  • Don’t create subdirectories inside subdirectories.
  • The module does not actually use file- or directory names, but the order of files and directories in the SD card’s FAT. The previously mentioned naming conventions just try to give you control over that order. If you properly organize your audio files in a folder on your PC first, and then copy that entire structure to a freshly formatted SD card, then (in theory) the FAT order should match the file- and directory numbering. See also this tool

Apart from adding some extra functions to the above mentioned library, I still have to find out how to reliably receive and read the module’s response to commands and queries. Once that I’m in full control over this (for its price) remarkably versatile module, it will be useful for a couple of ‘talking’ projects that I have in mind. Probably just mono and not ESP32 driven, but anyway: lots of fun for just €4.


Here’s an example of a function that I added to the DFPlayerMini_Fast library. Calling play_in_dir(2, 5) will play file 005.mp3 in subdirectory 02.

Using an existing function as a template, I first added my new function to the DFPlayerMini_Fast.cpp file:

Then I added these two accompanying lines to the DFPlayerMini_Fast.h header file:

and (inside the code for the class):


Explanation: according to the datasheet, the 10 (hexadecimal) bytes that have to be sent (by the sendData() function) to play track 005.mp3  in directory 02 are:

7E FF 06 0F 00 02 05 xx xx EF

7E FF 06 are the first three bytes for every command. The following 0F is de code for ‘play a file in a direcory’, the following 00 means ‘no confirmation feedback needed’ and is followed by the two parameters for the desired directory- and file number: 02 and 05. Then comes xx xx which are two checksum bytes that will be calculated and replaced by the findChecksum() function of the library before the command is sent by sendData(). Finally, every command has to be closed by EF.

As you can see, my newly added function play_in_dir() takes two parameters only, corresponding with two bytes in the command sequence. All other bytes of the sequence are either fixed or calculated by the findChecksum() function.



LOLIN TFT-2.4 Shield

Here’s a well designed new display from Wemos Electronics. They call it a (D1 Mini) Shield, but instead of going on top of a Wemos D1 Mini (Pro), it lets you plug in the Mini at the back of the 2.4″ TFT touch screen display, leaving all GPIO pins accessible, thanks to double header rows. Very useful!

This table shows the internal pin mapping when used as a shield. For TFT_LED, TFT_RST and TS_CS, this mapping can be changed by closing solder bridges at the back of the display (default NC for TFT_LED means “backlight always on”).

The default pin mapping leaves I2C pins D1 and D2, as well as D4, A0, TX and RX available for other purposes. With my Wemos Mini Pro v2 plugged in, this shield has become my first choice for battery powered esp8266 projects that require a display.



But there’s more. All pins are also broken out to a breadboard-friendly header and to a TFT connector. Connecting the display to a D32 Pro (that also has a TFT connector) now requires only one (special) cable! The picture shows the connector’s pinout.


The 320×240 display uses the well-proven ili9341 chip, for which I already wrote a lot of sketches, both for esp8266 and esp32 boards. The XPT2046 library can be used to drive the touch screen.

I tested several sketches on a plugged-in Mini Pro, as well as a TFT cable-connected D32 Pro, and everything worked fine. Example sketches on the Wemos site use Adafruit’s ili9341 library, but I prefer the much faster TFT_eSPI library with built-in touch screen support.

Here’s a video showing the display in action:


Conclusion: this is a well-thought product that makes solderless wiring very convenient and stable. Recommended!



Quest for Fire

By no means a gamer myself, I’ve always been interested in the math behind the graphics in video games. A previous post showed how simple clouds can be produced by the Diamond-Square algorithm, running on an esp8266. That algorithm can generate maps and landscapes as well.

Another visual effect on my todo list was algorithmically simulated fire.


The video shows my first attempt on a small TFT display. I had to write a relatively simple algorithm, because it needs to run on a microcontroller. Some further experimenting with the color palette, weighting factors and randomization, as well as adding Perlin noise, will hopefully result in a more realistic fire. I also plan to add a rotary encoder for regulating the ‘fire’.

[Update: a newer version is here]

Busy Beaver

Today I discovered that Langton’s Ant is not the only Turing machine that’s nicknamed after an animal. There’s also the Busy Beaver [sic], invented by Tibor Radó. Despite its chaotic behaviour and unpredictable* outcome, the machine itself is extremely simple and can easily be simulated on a TFT display by an Arduino.

[video shows the final 3 steps of the busiest of all 4-state, 2-symbol beavers]

The beaver’s workflow is: read cell color -> lookup instructions for current [cell color/system state] combination  -> adjust state -> adjust cell color -> move head -> start again, unless state equals X.

In general, the components of a Turing machine, as described by Alan Turing in 1936, are:

  • an infinite tape, divided into an infinite number of cells, each of which can contain a symbol from a finite set of characters, including a ‘blank’ (the alfabet)
  • a head that can read and optionally change the content of a cell, as well as optionally move to the next or previous cell on tape
  • a finite set of n possible states that the system can be in, plus at least one additional state that marks the end of the process
  • a finite set of instructions that, based on the current state and the currently read symbol, decides about: (1) whether the symbol will be erased, overwritten or left as is; (2) whether the head will move one cell (left or right), or keeps it position over the tape; (3) what the next system state will beome.

The alfabet in my sketch consists of 0 (‘blank’, white cell) and 1 (blue cell). The four system states are represented by A, B, C and D. Note that this 4-state machine has a 5th state X, the exit state. A beaver must have exactly one (1) exit state. Also, all of its instructions must include movement of the head.

The algorithm could (in theory) simulate any 4-state, 2-symbol Turing machine on a 480×320 TFT diplay, but my sketch is initialized for simulating the ‘busiest’ of all possible 25,600,000,000** 4-state Busy Beavers: the one that stops with the maximum numbers of ‘1‘s on tape (13, after 107 steps). Luckily, it will not run out of Arduino’s limited virtual tape during the process (‘real’ Turing machines have an infinite tape, that’s why they can only exist as mathematical models).

It would have been impossible to simulate the busiest 5-state 2-symbol beaver, since several super computers and my Arduino 😉 are still searching for it. So far, ‘we’ have found one that has 4098 ‘1‘s on tape when it stops.

* Turing proved that no single algorithm can exist, that’s capable of predicting the outcome of all possible beavers. Apart from the trivial ones, you’ll simply have to run them…

**In a Busy Beaver Turing machine, the head will always be moved. That reduces the number of possible [color, state, move] instruction triplets for a 4-state, 2-color beaver to 2x5x2 = 20 (remember the 5th X state). We have to provide instruction triplets to 4×2 = 8 state/color combinations (state X doesn’t need one), so there are 208 different 4-state, 2-color Busy Beavers.



Tic-Tac-Toe trainer

Turning an Arduino into an invincible Tic-Tac-Toe master is hardly a challenge, but I wrote a sketch for it anyway because I need it for a more ambitious project. For that project, I also had to design a couple of flawed Tic-Tac-Toe strategies with different levels of ‘vincibility’.

Next, I’ll have two Arduinos play matches against each other and analyse the outcome for all combinations of competing strategies. Now the strategies can be ordered based on their success rate.

The final goal is to make the Arduino act as a Tic-Tac-Toe trainer for beginners. While guiding their learning process by letting them play against increasingly better strategies, I can monitor their progression and compare it with the learning process of an Artificial Neural Network (ANN), for which I’m currently writing a sketch. Will 2,000 bytes be able to keep up with 100,000,000,000 human neurons?

This is a work in progress. For now, the video shows the Arduino in invincible mode, with me playing at the level of a befriended nation’s president. I even managed to put myself in a lost position after my very first move. It definitely takes some skills to loose this game…




Newton fractal

Here’s another famous fractal that I wanted to try on Arduino: the Newton fractal. It’s named after Isaac Newton’s iterative method for finding roots of functions. The classic example applies the method to function f(z) = z3 – 1 , where z is a complex number. This function has three roots in the complex plane.

classic newton fractal

The sketch that produced this picture loops over the pixels of a 480×320 display, mapping each of them to a complex number z0, that will serve as the initial value for Newton’s iteration process:

zn+1 = zn – f(zn) / f'(zn)

The basic color of a pixel (red, green or blue) depends on to which of the three roots the process converges. Its color intensity depends on the number of iterations that were needed to reach that root within a pre-defined precision. It’s just that simple!

Apart from playing with different color mappings (always essential for producing visually appealing fractals), I wanted to use modified versions of Newton’s method, as well as to apply them to different functions. The Arduino core has no support for complex calculus, and a library that I found didn’t even compile. So I wrote a couple of basic complex functions and put them in a functions.h file. There must better ways, but it works for me.

Once you have a basic sketch, the canvas of complexity is all yours!



f(z) = z4 – 1


This is my functions.h file. It must be in the same folder as the fractal sketch.


And here’s the Newton fractal sketch. Note the #include “functions.h” on the first line.



VS1053 + Matrix keypad


The VS1053b is a popular chip, used in many MCU controlled audio projects. It surprises me that nobody seems to use its eight GPIO pins, controllable over SPI by the master MCU. These GPIO pins enabled me to control my esp8266 based Internet radio by means of a matrix keypad, despite the fact that the esp8266 had only one free pin left.

The cheap 12-key membrane keypad shown in the picure uses 7 of these pins, wheras a 16-key matrix keypad uses all of them.


Adafruit’s VS1053 library has basic functions for adressing the chip’s GPIO pins. I wrote a simple demo sketch that prints the pressed key. In a real project, this information would typically be used to control other functions of the VS1053, like changing audio source or adjusting volume.


Make sure that pin definitions in the demo sketch match your MCU and connect RST to your board’s RST.

The VS1053_GPIO wiring for the demo sketch is different from what the picture shows. This is what I used for my 12-key membrane matrix keypad:






The connector’s column/row mapping for these particular keypads is usually as follows (from left to right in the picture): row0 – row1 – row2 -row3 – col0 – col1 – col2. The sketch can easily be adapted for a 16-key matrix keypad.

The basic idea of the sketch is:

  • keypadListen() sets all four row pins to INPUT with value 0; it sets all three column pins to OUTPUT with value 1. In this idle state, GPIO_digitalRead() will return B00000111 (decimal 7).
  • In loop(), we check GPIO_digitalRead(). A value higher than 7 means that one of the row pins has changed from 0 to 1 because it got connected to one of the column pins. This happens if a key on that row was pressed (that’s how matrix keypads are wired). We call keypadRead() to find the responsible key.
  • keypadRead() searches the row that caused the GPIO_digitalRead() > 7 condition, by checking each row pin until it reads 1. This gives us the row of the pressed key: R.
  • Next, it finds the column pin that is connected to row pin R by setting all column pins to INPUT with value 0 and row pin R only to OUTPUT with value 1. Checking each column pin until it reads 1 gives the column of the pressed key: C.
  • Now, keymap[R][C] holds the value of the pressed key (10 and 11 for * and #).
  • A simple debouncer is added for, well, debouncing.


Stream it!


The purchase of this versatile breakout board from Adafruit immediately made me put on hold all my ongoing projects. May the stream be with me!


This breakout board, built around the VS1053B chip, decodes various digital (stereo) audio formats such as MP3, AAC, Ogg Vorbis, WMA, MIDI, FLAC, WAV (PCM and ADPCM), and sends the analog signal to a female headphone plug (included as a breadboard friendly separate part). It can also record audio in both PCM (WAV) and compressed Ogg Vorbis format. All functions can be controlled over SPI.

Other features of the breakout board are:

  • microSD card holder for storing audio files
  • works with 3.3V and 5V boards (5V compliant pins)
  • 8 digital GPIO pins (not 5V compliant)
  • Volume, bass and treble control
  • a microphone input port
  • MIDI mode (reads MIDI data on the UART pin)
  • Additional functions (e.g. spectrum analyzer and VU meters) available via plugins

I had noticed the board before, but what made me decide to purchase it was this very simple esp8266 Internet Radio sketch on the Adafruit site. The fact that the VS1053 chip can handle mp3 live streams, delivered by an esp8266, means that it can be used for building a music streamer/internet radio! Since the esp8266 is capable of acting as a web client and a web server at the same time, it should be possible (in theory) to control the player with any web device (apart from several additional options, like buttons, IR remotes, rotary encoders, keypads, joysticks…).

After soldering the included header pins, I started with some simple MP3 playback from an SD card. My vintage Sennheiser Ovation was impressed! Then, with great expectations, I ran the Internet Radio sketch…. No sound! Not even debug messages on the serial monitor. Although Adafruit only, my hardware wasn’t from their new Feather/Wing line, for which the sketch was written. After quite some desperate attempts, almost losing hope, out of the blue came Bob Dylan’s “there must be some way out of here“. How appropriate (just as “something is happening, but you don’t know what it is” would have been). What did the trick was connecting the RST pins of the VS1053 and esp8266 boards, although the Adafruit example sketch suggests otherwise in the following line:


Here’s what I plan to do next:

  • Add a display (probably SPI, claiming two additional esp8266 pins; only one left…)
  • Make the esp8266 run a web server, listening to commands via a web page, very similar to the one I wrote for controlling my Transporter
  • Add manual control (buttons, IR, keypad?). The board’s own GPIO pins can be used for simple high/low devices like buttons
  • Support a list of selectable presets, pointing to internet radio stations
  • Make it possible to switch between radio mode and file mode (play ‘local’ music files)
  • Implement a larger (cyclic) buffer for more stability