8 x 1.44/1.8'' inch 128x128 128x160 TFT Full Color SPI LCD Display Modules over SPI

Status
Not open for further replies.

bossredman

Well-known member
Maybe? Again I have not tried them...

Hardware wise in theory can. That is you could potentially put all of them on the main SPI buss.
Where you connect some of the same SPI pins to all of the displays: Like MOSI, SCK, and maybe same IO pin for DC.
Each display would need their own Chip select pin(CS) pin... Also in theory you could move some of the displays to SPI1 and SPI2 on the T3.6

But then there is the issue of what code do you use to control the displays.

You might run into issues, like can you have multiple instances of the display object where all of the state information is contained within the object or does the library store a lot of this as global variables...

Also most libraries do not directly support using SPI1 and SPI2.

Also if you use the st7735_t3 library that I believe Teensyduino installs, it sort of requires CS and DC to be on hardware CS pins, it may fall back to bit banging if this is not the case.
Also when I say hardware CS pins, they have to both map to different SPI CS masks (some CS pins are actually sort of duplicates of each other)...
The library code looks like it only supports, the combinations of:
Code:
	 && !(_cs ==  2 && _rs == 10) && !(_rs ==  2 && _cs == 10)
	 && !(_cs ==  6 && _rs ==  9) && !(_rs ==  6 && _cs ==  9)
	 && !(_cs == 20 && _rs == 23) && !(_rs == 20 && _cs == 23)
	 && !(_cs == 21 && _rs == 22) && !(_rs == 21 && _cs == 22) ) {

I have a version of the library, I hacked up in 2016 which supported the different SPI busses as well as maybe not CS pin on hardware CS pin...
(https://github.com/KurtE/ST7735_t3/tree/SPIN-Version) It uses my SPIN library to do some of the work... Have not tried it in a very long time.

I thought I had a test app with 4 of these like displays with two on SPI and one each on SPI1 and SPI2... But I may have deleted it.
 
OK thanks Kurt.

Sounds like it may not be a good option.

Does anyone have any suggestions on teh best way to achieve what I'm after then pls?

ie 8 small displays - for displaying text/symbols - multi-coloured AND relatively cheap.
 
Not sure anything is 'designed' to work in that situation - or that it has been done. There was a post some time back about 3 or more larger ili9341's used at once with unique CS pins.

How many updates how quickly need to be made across the displays? Simple text update on each screen one at a time - or dynamic response across multiple displays?

Given the lower pixel count - if the update rate isn't excessive it seems there should be a way to use the SPI bus and a way to switch the CS pin across the like displays.
 
by small I mean 1.4 or 1.8 inch max.
refresh won't be any thing fast.
all will just display simple text (2 rows each of 8 chars max) & a simple symbol. updated once after a press of a switch.
will remain stitic until the next press.
switch is foot operated
 
Again not saying you should or should not try it.

As I mentioned in theory it should work. Might need to tweak a library or two to make work...

If that runs into problems, you can probably hook up some of them to use the same IO pins through some form of multiplexer(s).

Again sometimes it boils down to how fast you need it to run and complexity.
 
The 7-pin display modules do not need "just" SPI, but also CS (Chip Select), D/C (Data or Command), Reset, and optionally a PWM pin for controlling the backlight. As KurtE mentioned, this should work in theory, but the problem is existing library support. The CS pins need to be separate, but all can share the D/C and Reset pins (although you cannot then reset just one display; you can only reset them all if you need to). There is always the risk that the display modules don't like sharing their lines among so many modules -- for example, if there are too many pull-up/down resistors in the lines, or even if the modules don't like their D/C pins toggled when their CS is not selected.

The existing ST7735 libraries I looked at do not use a canvas, but send the pixel data resulting from drawing commands via SPI. Assuming 16-bit RGB color, each 128×128 frame needs 32768 bytes; 128×160 needs 40960 bytes. With a full canvas, it would be much easier to support the eight SPI displays, because then the SPI transfers could use DMA. If the library is the only one using that SPI bus, you could avoid the CS pin restrictions by reserving the hardware CS pin (i.e., keep it unused), and let the SPI library think it is using hardware CS pins, too.

The leftover issues is that I don't know of any graphics libraries for the 16-bit color canvas; you'd need to write your own. The easiest would be to just read them from raw binary files from a microSD card using Paul's SD library. (It is trivial to convert to/from that raw hardware format and e.g. NetPBM binary .ppm format; and NetPBM tools contain converters to/from JPEG, GIF, and PNG.) Still, you'd need some kind of font-drawing (overlaying on top of image read from microSD) at least. So, quite a bit of coding work.

Another option is to use "intelligent" display modules.

There is at least one seller on eBay with RGB TFT display modules (of various sizes) that support I2c. These have some sort of microcontroller on board, and you can set different I2C addresses for each module, so you should be able to control several of these on the same I2C bus (without the I2C multiplexer). Instead of pixel data, you send the drawing or writing commands as text to the desired module, so no library per se is needed. They also cost about three or four times as much as the above 7-pin display modules.

Personally, I might use slightly smaller, single-color (white) OLED modules.

There are up to 1.3" single-color OLED displays using the SSD1306 controller. I have the white ones, and I like them quite a bit. Make sure you look at the four-pin ones. In the yellow/blue models, the pixels near the top are yellow, and the rest are blue, on a black background. So, each pixel is always the same color if lit: monochrome. The larger ones (0.96" and 1.3") are 128×64, the smaller (0.91") are 128×32.

Use eight identical I2C displays, and an I2C multiplexer like Adafruit sells (or a cheap eBay clone). You only need minimal changes to the Adafruit SSD1306 library, to fully support the I2C multiplexer. This is because the library only communicates with the display at init and display times. At init time, all displays need to be initialized (a new constructor function, that takes the heights of the up to eight displays into account, and drops the splash). A new variant of the .display() method takes an additional parameter, to choose the display to be updated with the current canvas; you can even update the same canvas to multiple displays. You can also add helpers so that the canvas is easy to load from a 1024- or 512-byte (128×64 or 128×32 bit) raw binary file on a microSD card (say, using Paul's SD library), in case you want to display nice pre-drawn icons, and optionally add text/lines/bars on top. Drawing/writing text to the canvas is done using Adafruit GFX library. There is only one canvas, but you can send it to any display or displays. (You can obviously also keep the icons in Flash, but there isn't that much room there.)

I could probably provide the changes, porting it to the i2c_t3 library (using DMA for the i2c transfers), but I don't yet have a multiplexer to test the code, and my newest Teensy is a 3.2. The changes are really simple.

Note that SSD1351-based 1.5" RGB OLED displays do not support I2C; they have a 3-wire SPI mode, not I2C. Beware of erroneous listings!
 
thanks for the detailed response.
appreciate the time it must have took.

I've seen the single or 2 colour 12c ones.
but nfortunately it's the multi colour feature thst I need.
as I'm wanting to upgrade from my current 8 times 8x2 LCD displays .
 
You could use the dig-ole displays:

These displays can be used with either serial UARTs, i2c, or SPI. And you can probably run some on serial UART (the Teensy 3.6 has 6 separate UARTs), SPI, or i2c. I only used it with serial UARTs when I used it a few years ago. IIRC, the library they had needed a simple edit to treat the Teensy like a standard Arduino.

To change from UART to i2c or SPI, you need to set a solder jumper.

If you go with i2c, there is a command to change the i2c address in the library. So you would need to hook up a new display, and change it to a unique address, and then from then on, use the new address. That is probably the simplest approach. I don't know if a single i2c bus can hold 8 displays (it probably can, as long as the wires are short).

For i2c on the Teensy, you will need at least one device on the i2c to have pull-up resistors. From the documentation, it doesn't look like the monitors have pull-up resistors. So you will need 2 2.2K resistors. One to connect between 3.3v and SCL, and the other to connect between 3.3v and SDA.

It looks like the OLED monitors use about 110mA (at 5v) and the first LCD monitor I checked used 0.5mA to 135mA (at 5v). For 8 displays, you would need on the order of 1 amp of power. You will need an independent 3.3v (or 5v) power source as this goes above what a Teensy can supply either through its VIN or 3.3v terminals. (remember to cross connect the grounds) to drive 8 displays.

Unlike the the displays you mentioned, the dig-ole displays have their own memory. This means you don't have to keep a copy of the display in the Teensy 3.6 and send it to the display. Instead the library sends commands to the display (draw line, write text, etc.). The Teensy only has 256k. I don't think if it has enough memory to support 8 full displays in color if you had to have the screen image in the Teensy.

When I ordered my displays, I ordered them from the Canadian office and not the Chinese office. I think it was a little more than a week, but it has been some time since I ordered them.

A completely different approach would be to use one large monitor, and put a physical mask over the display to make it look like 8 separate displays. I just got mail that the 7" Gamedunio 3X is now shipping:
 
Last edited:
So you would need to hook up a new display, and change it to a unique address,

Thanks Michael definitely food for thought.
Ref having to change the address - can you elaborate on how I would do this pls?
DO I need any additional HW/SW?

EDIT: oops never mind sorry - just saw you added a link for the maual
 
Also - can you expand on this too pls?

Note, I am a software guy, not a hardware guy. So if any h/w types pipe up, believe them and not me.

In general, there are several ways to power your project, which needs roughly 1 amp of power.

1) Just use a standard USB cable to power everything. Unfortunately, depending on where you get your power, you might not get a full amp of power. For USB 2.0, you generally can rely on 0.5 amp (500mA), but there are times when you might not get that amount. USB 2.0 chargers can sometimes get 2.1 amps, but typically they can only get that much power if they signal that they want more power. There are various ways to do this, but the Teensy does not do any of that, so you need to look for something that provides the power all of the time. Such things exist, but you can't depend on a random USB connection to provide the power, you have to look for a USB battery or socket that specifically does not say it is a smart charger (and even if it doesn't say that, you still need to test it).

1a) So assuming you found a USB power source that can deliver 1 amp, you can't just connect your screens to the Teensy's 3.3v or VIN pins, as the Teensy has limiters to prevent providing that much power. Instead, you have to connect the displays to the USB power before it gets to the Teensy, so that they can be powered directly.

1b) You can power the Teensy from the VIN pin, but you have a potential problem if you are powering the Teensy from both the VIN pin and USB. There is a solder pad underneath the Teensy that connects the USB power to Teensy's VIN, and if you cut that, there is no conflict. However, when you program the Teensy, you will need to apply external power, as it won't get it from the USB connection.

1c) You could build a USB to USB cable that allows you to get the power before it enters the Teensy for the displays. This way you don't have to cut the solder jumper.

2) If your USB power solution doesn't have enough power, you may need to use two or more power inputs. You often see this with the long ws2812b (neopixel) or apa102 (dotstar) light strings, where a single power source is not enough to power all of the LEDs. Instead you use multiple power sources, say connecting one USB battery to power 4 displays, another USB battery to power the other 4 displays, and the 3rd battery to power the Teensy. Between each of the batteries, you make sure the ground wire (typically black) is connected to each of the power supplies., but the power wire (5v) is not connected between the supplies.
 
I would say start out small. Get two displays. You should be able to power them with the Teensy and start working on getting them to work. Then after they are working, you can tackle the issues with power.
 
I would say start out small. Get two displays. You should be able to power them with the Teensy and start working on getting them to work. Then after they are working, you can tackle the issues with power.

ha im glad yiu said that...as that exactky whst i did.
cheers
 
I'm planning on driving six 1.44" ST7735 displays using a Teensy 3.2 and the ST7735_t3 library. MOSI, SCK, DC, and RST will be common across all six displays. I'm using pin 15 for DC, so CS can be any of 10, 2, 9, 6, 20, 23, 21, or 22 and still be using hardware SPI. I'm not specifying RST in the ST7735 constructor, so it won't be triggered by the ST7735 initialization routine in the library. I'm pulsing the RST line in my code before calling the ST7735 library's initialization routine.

The displays haven't shown up yet. I'll experiment with them once they arrive to make sure this plan works.
 
Warning as for using that many hardware CS pins, there are probably not that many unique CS pins. That is several of them are logically duplicates of others. I am not at a computer so will respond more tomorrow
 
Warning as for using that many hardware CS pins, there are probably not that many unique CS pins. That is several of them are logically duplicates of others. I am not at a computer so will respond more tomorrow

For 3.2/3.5/3.6, you can only have 4 displays for the fast DMA control (you can have 5 fast ports, but you need both a DC and CS pin for the displays, you can share the DC pin but not the CS pin). In addition, while there are 9 pins, several of the pins overlap, and you can use either one or the other pin, but not both in the same time. The pins are:

  • Pin 2 or pin 10;
  • Pin 6 or pin 9;
  • Pin 15/A1;
  • Pin 20/A6 or 23/A9;
  • Pin 21/A7 or 22/A8.

For more information, see:
 
HI - my Digole displays have arrived.

I've loaded the Digole library - but I see from one of the sample sketches that the SDA & SCL pins are set to/defined as 4 & 5 respectively.

Code:
#if defined(_Digole_Serial_I2C_)
#include <Wire.h>
DigoleSerialDisp mydisp(&Wire, '\x27'); //I2C:Arduino UNO: SDA (data line) is on analog input pin 4, and SCL (clock line) is on analog input pin 5 on UNO and Duemilanove
#endif

Any idea how & where I change these to use SCL0 (pin 19) & SCL0 (pin18) on my T3.6 pls.?
 
For 3.2/3.5/3.6, you can only have 4 displays for the fast DMA control (you can have 5 fast ports, but you need both a DC and CS pin for the displays, you can share the DC pin but not the CS pin). In addition, while there are 9 pins, several of the pins overlap, and you can use either one or the other pin, but not both in the same time. The pins are:

  • Pin 2 or pin 10;
  • Pin 6 or pin 9;
  • Pin 15/A1;
  • Pin 20/A6 or 23/A9;
  • Pin 21/A7 or 22/A8.

For more information, see:

What if I add a SN74LCV244N between the four available chip-selects, tying the chip-selects to both halves of the input to the octal buffer? I then use two non-CS pins to control the tri-state outputs to up to eight displays. I'll have to add 10k or so pull-ups on the tri-state outputs. It might be necessary to add a second SN74LC244N between MOSI, SCK, DC, and RESET, just to act as a driver. I don't know if the Teensy has enough drive for six (or more) displays on the common pins.
 
What if I add a SN74LCV244N between the four available chip-selects, tying the chip-selects to both halves of the input to the octal buffer? I then use two non-CS pins to control the tri-state outputs to up to eight displays. I'll have to add 10k or so pull-ups on the tri-state outputs. It might be necessary to add a second SN74LC244N between MOSI, SCK, DC, and RESET, just to act as a driver. I don't know if the Teensy has enough drive for six (or more) displays on the common pins.
Note, there are SPI devices that need tri-state buffering when you have multiple devices on the same SPI bus.

But the reasons for using the special 9 pins are a different issue. Normally you can use any digital pins for the display's CS and DC pins.

The pins I was mentioning are used in a much higher speed transfer method that uses background DMA to speed up transfers to the display. If you use this faster method, both the CS and DC pins have to come out of the set of pins mentioned. This technique was first done by Paul for speeding up the ILI9341 320x240 display (which PJRC.COM sells). Several of the other display drivers have adapted this technique. In theory, it should fall back to the normal slower SPI data transfer mechanisms if you don't use the right pins.

In addition, as I mentioned earlier, once you get more than two of these OLED displays, you will need to work on powering the displays. The OLED 128x128 displays draw something like 110 - 125mA. Drawing power from the Teensy's VIN pin will only give you about 250mA before the fuse within the Teensy between the USB port and VIN sets in. If you wire it so the displays get their power from the USB line before plugging it into the Teensy, you can get more power. But the USB 2.0 spec limits you to typically 500mA (4 displays). Above 4 displays, you will need to think about how to get about an amp of power (at 5v) to power the displays.

There are various batteries that can provide this amount of power, as well as A/C converters. However, you have to be careful, as as lot of these power sources are 'smart devices', in that they will only deliver the higher amps if the device they are connecting to properly identifies itself as capable of handling higher voltages, and the Teensy doesn't do this identification.

OLED displays tend to need a lot of power, depending on whether the screen is mostly dark (low power) or mostly bright (high power). The TFT displays tend to need a lot less power, and the power usage is more consistent as the main power draw is the backlight. OLED displays are much brighter, and you see the display from a wider angle than a TFT display. But as I've discovered the TFT displays can be run at a faster speed, while I found with the 128x128 OLED displays, I had to slow down communication with the display when running a Teensy 3.5/3.6 at full speed.

So far, I have not had to limit the TFT speed, as my two displays kept up, even when I was using a Teensy 3.6 over-clocked to the fastest speed. While for the OLED display, I had to limit the SPI bus to 11Mhz so that the display was not corrupted. I've tried different manufacturers (Adafruit, Wavelan, New Haven) of the OLED display, and some (Wavelan, New Haven) could be cranked a bit higher than the Adafruit display.

In another post (the Teensy 4.0 beta thread), I posted about the Adafruit program uncanny eyes, which has two 128x128 displays that draw eyeballs and have the eyes move around. I have two main test beds, a Teensy 3.2 driving 2 TFT 128x128 displays, and a Teensy 3.5 driving 2 OLED displays. Both of these test beds use the 9 special pins and do use the DMA methods to speed up the display. The numbers I got were:

  • Teensy 3.2, 120Mhz, 2 TFT displays, 5.2v, 0.09a, 78 fps (this uses the ST7735 driver)
  • Teensy 3.5, 168Mhz, 2 OLED displays, 5.2v, 0.25a, 35 fps (this uses the SSD1351 driver)
 
Last edited:
Thanks Michael, I was going to show the table of pins once I got back to my computer...

One thing to note: is the system will not tell your it is an error if for example you setup one display to use pin 10 and another pin 2... There is nothing currently on system that keeps track of which hardware CS signals have been grabbed... It will complain if you try to use 10 and 2 on the same display.

Note: However with the changes that I made, that Paul has brought in to support T4, the system is setup to allow you to use non hardware CS pins. I put in code also on T3.x that if MOSI, SCK and DC are on the hardware SPI pins, it is happy. You get a slight speed up with CS on hardware CS, but only very slight, so I check that and allow both cases.

But again that code does not detect and fallback that if for example one display uses pin 10 and then second one tries to use pin 2, they will both try to use the hardware way...
 
Thanks Michael, I was going to show the table of pins once I got back to my computer...

One thing to note: is the system will not tell your it is an error if for example you setup one display to use pin 10 and another pin 2... There is nothing currently on system that keeps track of which hardware CS signals have been grabbed... It will complain if you try to use 10 and 2 on the same display.

Note: However with the changes that I made, that Paul has brought in to support T4, the system is setup to allow you to use non hardware CS pins. I put in code also on T3.x that if MOSI, SCK and DC are on the hardware SPI pins, it is happy. You get a slight speed up with CS on hardware CS, but only very slight, so I check that and allow both cases.

Good. Are there special CS/DC pins in the Teensy 4.0? I asked in the beta thread, but that is rather high volume.
 
Status
Not open for further replies.
Back
Top