Lmst

Drive 1024×600 Pixels via I2C with an ATtiny85 https://hackaday.com/2026/01/08/drive-1024x600-pixels-via-i2c-with-an-attiny85/
#ATtinyHacks #Microcontrollers #ATTiny85 #Graphicslibrary #LT7683 #RA8875 #TFTdisplay

Arduino with Multiple Displays – Part 3

Whilst messing around a little more with my Arduino with Multiple Displays – Part 2, I’ve optimised the code a little and found out a bit more about these displays!

In this part, I’m actually using a PCB that can hold four displays, powered by a Waveshare Zero device. More on that here: Waveshare Zero Multi Display PCB Design.

Warning! I strongly recommend using old or second hand equipment for your experiments. I am not responsible for any damage to expensive instruments!

These are the key Arduino tutorials for the main concepts used in this project:

If you are new to microcontrollers, see the Getting Started pages.

Parts list

A Waveshare Zero format board or similar
4x 0.96″ ST7735 60×180 SPI TFT displays.
Built Waveshare Zero Multi Display PCB
Breadboard and jumper wires.

Recall that I’m using displays that look like this – note the order of the pins.

Although even with displays that look exactly the same, it appears there can be differences in how they are used software wise. More on that later.

The Circuit

For two displays, I can reuse the circuit from Arduino with Multiple Displays – Part 2. For more displays, it is possible to cascade more displays using jumper wires, but I’ve used my PCB.

The pins to be used for various Waveshare Zero boards is covered in part 2.

The Code

Whilst using these displays, I found that the colours can be inverted in some of them compared to others. Typically, I’ve found that I might have to use either of the following two options to drive them correctly:

tft.initR(INITR_MINI160x80);
tft.initR(INITR_MINI160x80_PLUGIN);

These represent different Adafruit displays as before, but they generally work for me.

However there is another thing to watch out for. These displays are 16-bit colour displays, which means each colour value is a 16-bit word with red, green and blue elements represented by 5, 6 and 5 bits. This means two of the colours have a resolution of 0 to 31, and one has 0 to 63.

But the ordering seems different for different displays. The default Adafruit library appears to assume RGB ordering, but my displays seem to be BGR. This means that if I use the provided short-cuts for colours, the red and blue elements are swapped.

Consequently, I defined my own colours along with a macro to allow me to provide RGB values and turn it into the device-specific 16-bit value as required.

In the following, I define the bit-shift number for each of red, green and blue and the use that in a macro “ST_COL” shifting the value to the correct place in the 5-6-5 format. Red and blue are the 5-bit colours and green is the 6-bit colour, so in each case I take the most significant bits which means each colour can still be defined in terms of 0..255 RGB values.

// Format is 16-bit 5-6-5 B-G-R
// Allow 0..255 in component values, by only taking
// most significant bits (5 or 6) from each value.
//   bbbbbggggggrrrrr
#define ST_COL(r,g,b) (((r&0xF8)>>3)|((g&0xFC)<<3)|((b&0xF8)<<8))
#define ST_BLACK   ST_COL(0,0,0)
#define ST_GREY    ST_COL(64,64,64)
#define ST_WHITE   ST_COL(255,255,255)
#define ST_BLUE    ST_COL(0,0,255)
#define ST_GREEN   ST_COL(0,255,0)
#define ST_RED     ST_COL(255,0,0)
#define ST_YELLOW  ST_COL(255,255,0)
#define ST_MAGENTA ST_COL(255,0,255)
#define ST_CYAN    ST_COL(0,255,255)

I’m also building up to seeing if I can drive more than four displays, so I’ve also changed the code to allow me to iterate across a number of displays.

#define NUM_TFTS 4
int tftTypes[NUM_TFTS] = {
 INITR_MINI160x80, INITR_MINI160x80,
 INITR_MINI160x80, INITR_MINI160x80,
};

int tftCS[NUM_TFTS] = {SPI_SS, 6, 5, 4};
#define TFT_RST     7
#define TFT_DC     11

Adafruit_ST7735 *tft[NUM_TFTS];

void setup() {
  int rstPin = TFT_RST;0
  for (int i=0; i<NUM_TFTS; i++) {
    tft[i] = new Adafruit_ST7735(&MySPI, tftCS[i], TFT_DC, rstPin);
    rstPin = -1;
    tft[i]->initR(tftTypes[i]);
    tft[i]->setRotation(3);
    tft[i]->fillScreen(ST_BLACK);
  }
}

void loop() {
  for (int i=0; i<NUM_TFTS; i++) {
    unsigned long time = millis();
    tft[i]->fillRect(10, 20, tft[i]->width(), 20, ST_BLACK);
    tft[i]->setTextColor(ST_GREEN);
    tft[i]->setCursor(10, 20);
    tft[i]->print(i);
    tft[i]->print(":");
    tft[i]->print(time, DEC);
  }
}

Each instance of the display code is now created dynamically and stored in an array which can then be iterated over when it comes to putting things on each display.

Notice how the reset pin definition is set to -1 after the first initialisation. This ensures that subsequent instantiations won’t reset displays that have already been set up.

The final code actually allows up to eight displays to be included by setting NUM_TFTS at the top to two or four.

The GPIO usage being assumed is described here: Waveshare Zero Multi Display PCB Build Guide.

Find it on GitHub here.

Closing Thoughts

Approaching the code in this way allows me to experiment more easily with more than four displays.

If my PCB works as I’m hoping I should be able to cascade them to get eight displays – assuming the Waveshare Zero is up to driving eight of course.

Kevin

#arduinoUno #define #esp32c3 #ESP32s3 #rp2040 #st7735 #tftDisplay #WaveshareZero

Arduino with Multiple Displays – Part 2

As I mentioned in my last post on Arduino with Multiple Displays I’m going to look at other microcontrollers too. This post takes a wander through my Waveshare Zero and similar format boards that each support one of the RP2040, ESP32-C3 or ESP32-S3.

Warning! I strongly recommend using old or second hand equipment for your experiments. I am not responsible for any damage to expensive instruments!

These are the key Arduino tutorials for the main concepts used in this project:

If you are new to microcontrollers, see the Getting Started pages.

Parts list

A Waveshare Zero format board or similar
2x 0.96″ ST7735 60×180 SPI TFT displays.
Breadboard and jumper wires.

Once again I’m using displays that look like this – note the order of the pins.

The Circuit

All circuits are a variation on the above, requiring the following ideal connections:

DisplayFunctionRP2040ESP32-C3ESP32-S3BLKBacklight control
(not required)N/CN/CN/CCSChip select
One per display.5 or any SPI0 CS1010DCData/Command888RESReset1499SDAData (MOSI)3 or any SPI0 MOSI6 or 711SCLClock (SCLK)2 or any SPI0 SCLK4 or 612VCCPower3V33V33V3GNDGroundGNDGNDGND

For the explanations of the pin choices, and what it means for the code, see the following sections.

ESP32-S3 Zero

In the Arduino IDE, using board ESP32-> Waveshare ESP32-S3-Zero.

There are several SPI buses on the ESP32-S3, but they have fixed uses as follows (see the ESP32-S3 Technical Reference Manual Chapter 30 “SPI Controller”):

SPI 0: Reserved for internal use.
SPI 1: Reserved for internal use.
SPI 2: General purpose use – often called FSPI in the documentation.
SPI 3: General purpose use – often called SPI or SPI3.

Sometimes the two SPI buses are called VSPI and HSPI but I think that is really terminology from the original ESP32 rather than the ESP32-S3.

The ESP32 Arduino core for the Waveshare ESP32-S3 Zero variant defines the following:

// Mapping based on the ESP32S3 data sheet - alternate for SPI2
static const uint8_t SS = 34;    // FSPICS0
static const uint8_t MOSI = 35;  // FSPID
static const uint8_t MISO = 37;  // FSPIQ
static const uint8_t SCK = 36;   // FSPICLK

By default the Adafruit libraries will use the boards default SPI interface, as defined in the variants.h file – i.e. the above.

When it comes to assigning SPI devices to GPIO there are a few considerations (see the “ESP32-S3 Technical Reference Manual, Chapter 6 “IO MUX and GPIO Matrix”):

In general, any GPIO can be mapped onto any SPI function. However…
Some GPIO have special “strapping” functions so are best avoided.
Some GPIOs have a default SPI function that bypasses the GPIO MUX routing, so allows for better performance (see section 6.6 “Direct Input and Output via IO MUX”).

From my reading of the reference manual I believe the following are default “non-MUX” SPI connections:

In the previous table, where SPI3 is mentioned, then the entry for “Direct IO via IO MUX” is set to “no”, so I’m guessing that isn’t available.

But now we can see why the Arduino core is using GPIO 34-37, but we can also see that GPIO 10-13 would be an alternative (fast) option too.

The problem is that not all of GPIO 34-37 are broken out on a Waveshare ESP32-S3 Zero, so I need to use the alternative pinouts. Aside: this makes no sense to me that these are the defaults in the Waveshare ESP32-S3 Zero’s “variant.h” file, but anyway…

To use a different SPI interface requires using a constructor that passes in an initialised SPI instance. There is an example in the ESP32 core for setting up multiple SPI buses here: https://github.com/espressif/arduino-esp32/blob/master/libraries/SPI/examples/SPI_Multiple_Buses/SPI_Multiple_Buses.ino

This leads to the pins as defined in the previous table, and the code below to setup one of the displays.

#include <Adafruit_GFX.h>    // Core graphics library
#include <Adafruit_ST7735.h> // Hardware-specific library for ST7735
#include <SPI.h>

#define SPI_SS     10
#define SPI_MOSI   11
#define SPI_SCLK   12
#define SPI_MISO   13
SPIClass MySPI(FSPI);

#define TFT_CS      SPI_SS
#define TFT_RST     9
#define TFT_DC      8
Adafruit_ST7735 tft = Adafruit_ST7735(&MySPI, TFT_CS, TFT_DC, TFT_RST);

void setup() {
  MySPI.begin(SPI_SCLK, SPI_MISO, SPI_MOSI, SPI_SS);
  pinMode(SPI_SS, OUTPUT);
  tft.initR(INITR_MINI160x80_PLUGIN);
}

ESP32-C3 Zero

In the Arduino IDE, using board ESP32-> ESP32C3 Dev Module.

Again there are several SPI buses on the ESP32-C3, with the same fixed uses as follows (see the ESP32-C3 Technical Reference Manual Chapter 30 “SPI Controller”):

SPI 0: Reserved for internal use.
SPI 1: Reserved for internal use.
SPI 2: General purpose use – sometimes called GP-SPI in the documentation.

The ESP32-C3 also has a very similar SPI arrangement to the ESP32-S3, in that whilst any pin can be configured for SPI usage, there are certain hard-wired optional arrangements that bypass the GPIO routing matrix.

The faster (direct to IO MUX) pins are as follows (more here):

CS0 – 10
SCLK – 6
MISO – 2
MOSI – 7

Curiously, the general ESP32-C3 Arduino variant defines them as follows:

static const uint8_t SS = 7;
static const uint8_t MOSI = 6;
static const uint8_t MISO = 5;
static const uint8_t SCK = 4;

From the Technical Reference manual, we can see that the default Arduino definitions above, do not support the non-routed, direct-to-IO MUX pin mappings, which from the table below do indeed map onto GPIO 2, 6, 7, 10.

In terms of using a Waveshare ESP32-C3 Zero, both combinations would be supported on the broken out GPIO, so from a software point of view, the Adafruit libraries could be used “as is” with the default mapping, or with a custom SPI definition (as shown above) with the more bespoke, but faster, mapping.

RP2040 Zero

This is using the (unofficial) RP2040 core from here: https://github.com/earlephilhower/arduino-pico, where this is an entry: RP2040 -> Waveshare RP2040 Zero.

The RP2040 has two SPI peripherals and the SPI functions are mapped onto specific sets of GPIO pins. This gives a range of flexibility, but not arbitrary flexibility. The board definition file for the Waveshare RP2040 Zero provides this as a default:

// SPI
#define PIN_SPI0_MISO  (4u)
#define PIN_SPI0_MOSI  (3u)
#define PIN_SPI0_SCK   (2u)
#define PIN_SPI0_SS    (5u)

#define PIN_SPI1_MISO  (12u)
#define PIN_SPI1_MOSI  (15u)
#define PIN_SPI1_SCK   (14u)
#define PIN_SPI1_SS    (13u)

Note that the SPI1 pins for the Waveshare RP2040 Zero are not all on the standard header connections, some are on the additional pin headers across the bottom.

Using a bespoke configuration is possible using a series of calls to set the SPI pins as shown below.

  SPI.setRX(SPI_MISO);
  SPI.setCS(SPI_SS);
  SPI.setSCK(SPI_SCLK);
  SPI.setTX(SPI_MOSI);
  SPI.begin(true);

To use pins for SPI1, replace SPI above with SPI1. As long as this happens prior to the call to the Adafruit libraries, everything works fine.

A Common Option

It would be nice to find a set of physical pin connections that I know would always work regardless of the board in use: RP2040, ESP32-S3 or ESP32-C3.

With careful noting of the RP2040 limitations, I think that is largely possible with the following. Even though the GPIO numbers are different, the physical pins are common on all three boards.

DisplayFunctionWS PinRP2040ESP32-C3ESP32-S3BLKBacklight control
(not required)N/CN/CN/CCS1Chip select
Display 1H2 P6GP5GP9GP10DCData/CommandH2 P5GP4GP10GP11RESResetH2 P9GP8GP6GP7SDAData (MOSI)H2 P8GP7GP7GP8SCLClock (SCLK)H2 P7GP6GP8GP9VCCPowerH1 P33V33V33V3GNDGroundH1 P2GNDGNDGNDCS2CS Display 2H1 P9GP14GP5GP6CS3CS Display 3H1 P8GP15GP4GP5CS4CS Display 4H1 P7GP26GP3GP4

A couple of notes:

I’ve avoided pins 1-4 on header 2, as the ESP32-C3 can’t use them for SPI and they support either the UART or USB.
I’ve had to include a MISO (SPI RX) pin in each configuration too, so I’ve just picked something that can be ignored. For RP2040 that has to be one of GP0, GP4 or GP16 however, which could clash with either the UART, the above configuration for DC pin, or the onboard WS2812 LED, but there isn’t much that can be done.
I’ve allowed three consecutive pins on the first header for optional additional CS pins for displays 2 to 4.

Here is the full set of configurable code for the above:

#include <Adafruit_GFX.h>    // Core graphics library
#include <Adafruit_ST7735.h> // Hardware-specific library for ST7735
#include <SPI.h>

//#define WS_RP2040_ZERO
//#define WS_ESP32C3_ZERO
#define WS_ESP32S3_ZERO

#ifdef WS_RP2040_ZERO
#define SPI_SS      5
#define SPI_MOSI    7
#define SPI_SCLK    6
#define SPI_MISO    4  // Not used
#define SPI_BUS     SPI
#define TFT_CS1    SPI_SS
#define TFT_CS2    14
#define TFT_CS3    15
#define TFT_CS4    26
#define TFT_RST     8
#define TFT_DC      4
#endif

#ifdef WS_ESP32C3_ZERO
#define SPI_SS      9
#define SPI_MOSI    7
#define SPI_SCLK    8
#define SPI_MISO    0  // Not used
SPIClass MySPI(FSPI);
#define TFT_CS1    SPI_SS
#define TFT_CS2     5
#define TFT_CS3     4
#define TFT_CS4     3
#define TFT_RST     6
#define TFT_DC     10
#endif

#ifdef WS_ESP32S3_ZERO
#define SPI_SS     10
#define SPI_MOSI    8
#define SPI_SCLK    9
#define SPI_MISO    1  // Not used
SPIClass MySPI(FSPI);
#define TFT_CS1    SPI_SS
#define TFT_CS2     6
#define TFT_CS3     5
#define TFT_CS4     4
#define TFT_RST     7
#define TFT_DC     11
#endif

#ifdef WS_RP2040_ZERO
Adafruit_ST7735 tft1 = Adafruit_ST7735(TFT_CS1, TFT_DC, TFT_RST);
Adafruit_ST7735 tft2 = Adafruit_ST7735(TFT_CS2, TFT_DC, -1);
#else
Adafruit_ST7735 tft1 = Adafruit_ST7735(&MySPI, TFT_CS1, TFT_DC, TFT_RST);
Adafruit_ST7735 tft2 = Adafruit_ST7735(&MySPI, TFT_CS2, TFT_DC, -1);
#endif

void setup() {
#ifdef WS_RP2040_ZERO
  SPI_BUS.setRX(SPI_MISO);
  SPI_BUS.setCS(SPI_SS);
  SPI_BUS.setSCK(SPI_SCLK);
  SPI_BUS.setTX(SPI_MOSI);
  SPI_BUS.begin(true);
#else
  MySPI.begin(SPI_SCLK, SPI_MISO, SPI_MOSI, SPI_SS);
  pinMode(SPI_SS, OUTPUT);
#endif

  tft1.initR(INITR_MINI160x80_PLUGIN);
  tft2.initR(INITR_MINI160x80_PLUGIN);
  tft1.setRotation(3);
  tft1.fillScreen(ST77XX_BLACK);
  tft2.setRotation(3);
  tft2.fillScreen(ST77XX_BLACK);
}

void loop() {
  unsigned long time = millis();
  tft1.fillRect(10, 20, tft1.width(), 20, ST77XX_BLACK);
  tft1.setTextColor(ST77XX_GREEN);
  tft1.setCursor(10, 20);
  tft1.print(time, DEC);
  delay(100);

  time = millis();
  tft2.fillRect(10, 20, tft2.width(), 20, ST77XX_BLACK);
  tft2.setTextColor(ST77XX_MAGENTA);
  tft2.setCursor(10, 20);
  tft2.print(time, DEC);
  delay(400);
}

Closing Thoughts

It is a little annoying that these great boards don’t share a re-usable, common pinout in terms of naming and positions, but I guess that isn’t the main focus for these systems.

Still, it seems that a common hardware pinout can be made that supports many displays, which is great, as I’d really like to get a number of them onto a PCB!

Kevin

#arduinoUno #esp32c3 #ESP32s3 #rp2040 #st7735 #tftDisplay #WaveshareZero

Arduino with Multiple Displays

A while back I tried to use several SSD1306 displays with an Arduino (see OLED MIDI Display – Part 2) and got into trouble with memory. I have another need for multiple displays coming up, so thought I’d revisit the idea to see what could be done.

This shows use to use several cheap SPI-based displays together with an Arduino.

Warning! I strongly recommend using old or second hand equipment for your experiments. I am not responsible for any damage to expensive instruments!

These are the key Arduino tutorials for the main concepts used in this project:

If you are new to Arduino, see the Getting Started pages.

Parts list

Arduino Uno.
2x 0.96″ ST7735 60×180 SPI TFT displays.
Breadboard and jumper wires.

I’m using displays that look like this – note the order of the pins.

The Circuit

The display pins are connected to the Uno as follows:

BLKN/CBacklight control – not requiredCSD10/D7Chip select – one for each display.DCD8Data/CommandRESD9ResetSDAD11Data (MOSI)SCLD13Clock (SCLK)VCC5VPowerGNDGNDGround

Notes:

I’m using the Arduino Uno’s hardware SPI peripheral so the use of D11/D13 is fixed and can’t be changed.
All signals apart from CS are shared between both boards.
However – need to ensure that the boards are only reset once!

The Code

There are several software libraries that could be used for these kinds of displays. I’m using the Adafruit libraries:

Adafruit_GFX
Adafruit_ST7735_Library

These aren’t always ideal for generic no-name displays as they are geared up to support Adafruit products directly.

A case in point: there is no generic initialisation for a ST7735 display, but rather a number of bespoke initialisations that relate to Adafruit’s range of displays only. I was looking for some means of setting the display size (160×80) but that isn’t possible.

But as it happens, there are two initalisation options that map onto the above boards:

#include <Adafruit_GFX.h>    // Core graphics library
#include <Adafruit_ST7735.h> // Hardware-specific library for ST7735
#include <SPI.h>

#define TFT_CS1       10
#define TFT_CS2        7
#define TFT_RST        9
#define TFT_DC         8

//#define TFT_TYPE INITR_MINI160x80
#define TFT_TYPE INITR_MINI160x80_PLUGIN   // Inverted display

Adafruit_ST7735 tft1 = Adafruit_ST7735(TFT_CS1, TFT_DC, TFT_RST);
Adafruit_ST7735 tft2 = Adafruit_ST7735(TFT_CS2, TFT_DC, -1);

void setup() {
  tft1.initR(TFT_TYPE);
  tft2.initR(TFT_TYPE);
}

Notes for this initialisation code:

The use of pins D11 and D13 for SPI is assumed, and RST and DC are common.
I’m using the “INITR_MINI160x80_PLUGIN” initialisation option which is the same as “INITR_MINI160x80” but with the colours inverted. Without this, the built-in colour options aren’t correct for my boards.
Notice how in the second initialisation I’m using “-1” as the RESET pin so that the first display isn’t reset again after being initialised.
Both instances have their own CS pin defined.
The resolution and display size is fixed at 160×80.

In my case I also used setRotation(3) to rotate the displays by 180 degrees.

Here is my complete test code that prints the current millis() count to each display in a different colour.

#include <Adafruit_GFX.h>    // Core graphics library
#include <Adafruit_ST7735.h> // Hardware-specific library for ST7735
#include <SPI.h>

#define TFT_CS1       10
#define TFT_CS2        7
#define TFT_RST        9
#define TFT_DC         8

//#define TFT_TYPE INITR_MINI160x80
#define TFT_TYPE INITR_MINI160x80_PLUGIN   // Inverted display

Adafruit_ST7735 tft1 = Adafruit_ST7735(TFT_CS1, TFT_DC, TFT_RST);
Adafruit_ST7735 tft2 = Adafruit_ST7735(TFT_CS2, TFT_DC, -1);

void setup() {
  tft1.initR(TFT_TYPE);
  tft2.initR(TFT_TYPE);
  tft1.setRotation(3);
  tft1.fillScreen(ST77XX_BLACK);
  tft2.setRotation(3);
  tft2.fillScreen(ST77XX_BLACK);
}

void loop() {
  unsigned long time = millis();
  tft1.fillRect(10, 20, tft1.width(), 20, ST77XX_BLACK);
  tft1.setTextColor(ST77XX_GREEN);
  tft1.setCursor(10, 20);
  tft1.print(time, DEC);
  delay(100);

  time = millis();
  tft2.fillRect(10, 20, tft2.width(), 20, ST77XX_BLACK);
  tft2.setTextColor(ST77XX_MAGENTA);
  tft2.setCursor(10, 20);
  tft2.print(time, DEC);
  delay(400);
}

Closing Thoughts

This is a really good start. What I’d like to do is see how far I can push it, see how many displays it is possible to hook up, and what the overheads of updating them might be.

Then depending on where that leaves me, I can have a think about if I need an alternative microcontroller, like a RP2040 or ESP32 – something with several cores might be particularly useful for this – and see how things go.

Then I can start to think about the musical uses I have in mind.

Update: It seems to work with four displays too. I’ve attached two 1.8″ ST7735 displays just to try it (these are “INITR_18BLACKTAB” displays). See photo below!

Kevin

#arduinoUno #include #st7735 #tftDisplay

On the third night, a 1.28" round TFT display (https://bsky.app/profile/adafruit.com/post/3leccborle22w), and on the fourth a 1.8" round TFT with captouch overlay (https://bsky.app/profile/adafruit.com/post/3leg4y35r2k2k). we've over the hump and still going strong! Tonight, we did a 0.85" TFT breakout; it's 128x128 pixels and so tiny we had to put the breakout pads on opposite sides.

#festivaloflights #electronicsdesign #tftdisplay

Digital frequency meter with ESP32 and TFT display: an economical and essential solution for the electronics laboratory

https://www.techrm.com/digital-frequency-meter-with-esp32-and-tft-display-an-economical-and-essential-solution-for-the-electronics-laboratory/

#breadboard,#digital,#digitalelectronics,#digitalfrequencymeter,#Dupontcables,#esp32,#FFT,#internetofthings,#iot,#library,#linux,#NodeMCU,#platformio,#tft,#tftdisplay,#tutorial

Control of an SG90 servomotor with ESP32 and touchscreen display

https://www.techrm.com/control-of-an-sg90-servomotor-with-esp32-and-touchscreen-display/

#breadboard,#digital,#digitalelectronics,#Dupontcables,#esp32,#internetofthings,#iot,#library,#NodeMCU,#platformio,#PWM,#servo,#servomotor,#SG90,#tftdisplay,#tutorial

LCD TFT display for monitoring temperature and humidity with DHT22

https://www.techrm.com/lcd-tft-display-for-monitoring-temperature-and-humidity-with-dht22/

#breadboard,#datalogger,#DHT22,#digital,#digitalelectronics,#Dupontcables,#esp32,#internetofthings,#iot,#library,#NodeMCU,#platformio,#sensor,#sensors,#tftdisplay,#tutorial

Displays We Love Hacking: SPI and I2C https://hackaday.com/2023/12/21/displays-we-love-hacking-spi-and-i2c/ #HackadayColumns #oleddisplay #OLEDSSD1306 #oledscreen #SPIdisplay #TFTdisplay #SPIscreen #tftscreen #I2Coled #TFTLCD #Parts #oled #tft

Step-by-Step Guide: Build an ESP8266 FM Radio with Infrared Remote Control and TFT Display

https://www.techrm.com/step-by-step-guide-build-an-esp8266-fm-radio-with-infrared-remote-control-and-tft-display/

#analogueelectronics, #breadboard, #Dupontcables, #esp8266, #frequencymodulation, #header, #howtosolder, #infraredreceiver, #infraredremotecontrol, #library, #LM386, #platformio, #radioreceiver, #Si4703, #soldering, #speaker, #tft, #tftdisplay, #tutorial

Measuring oxygen saturation and heart rate with the ESP8266 and MAX30101 Sensor: complete guide

https://www.techrm.com/measuring-oxygen-saturation-and-heart-rate-with-the-esp8266-and-max30101-sensor-complete-guide/

#arduinocloud,#breadboard,#cloud,#datalogger,#Dupontcables,#esp8266,#header,#howtosolder,#internetofthings,#iot,#lcd,#library,#linux,#MAX30101,#measure,#platformio,#redLED,#sensor,#soldering,#tft,#tftdisplay,#tutorial,#wifi

Weather station with ESP8266 and TFT display: real-time monitoring of weather forecasts

https://www.techrm.com/weather-station-project-with-esp8266-and-tft-display-real-time-monitoring-of-weather-forecasts/

#atmosphericpressure,#breadboard,#datalogger,#Dupontcables,#esp8266,#humidity,#internetofthings,#iot,#lcd,#library,#linux,#measure,#platformio,#RESTAPI,#soldering,#temperature,#tft,#tftdisplay,#tutorial,#weatherforecast,#wifi

Arduino Library Makes Digital Rain Like It’s 1999

There's going to be a new Matrix movie in theaters next month, and you know what that means: we're about to see a whole new generation get obsessed with the franchise's iconic "Digital Rain" effect. Thanks to modern advertisement technology, expect to see lines of glittering text pouring down the displays of everything from billboards to gas pumps pretty soon.

Doesn't get much easier than that.

For those of us who've just been looking for an excuse to break out the old Matrix screensavers, you might as well get a jump on things using this handy Arduino library for the ESP8266 and ESP32. Developed by [Eric Nam], it lets you start up a digital rainstorm on displays supported by the TFT_eSPI library as easily as running digitalRainAnim.loop().

You can even install the library through the Arduino IDE, just open the Library Manager and search for "Digital Rain" to get started. You've still got to hook the display up to your microcontroller, but come on, [Eric] can't do it all for you.

Looking at the examples, it seems like various aspects of the animation like color and speed can be configured by initializing the library with different values. Unfortunately we're not seeing much in the way of documentation for this project, but by comparing the different examples, you should be able to get the high points.

While our first choice would certainly be a wall of green alphanumeric LED displays, we can't help but be impressed with how easy this project makes it to spin up your own little slice of the Matrix on the workbench.

#classichacks #softwarehacks #arduinolibrary #digitalrain #esp32 #esp8266 #matrix #matrixdigitalrain #tftdisplay

#TFTdisplay

Client Info