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

Status
Not open for further replies.
With T4 - only Pin 10 is CS pin on that SPI buss - And it works very differently than T3.x

That is with T4 you con't have the PUSHR register where you can select which if any (may be more than one) are to be asserted during that SPI transfer, and the CONT bit will say if those assertions should continue after that transfer completes.

Instead with the T4 you do have a FIFO queue, and you have two different registers that can be put onto the queues:
The standard: TDR which you can transfer up to 32 bits of data
And the TCR (Transfer control register) which you can adjust things like word size... With this you can choose which CS channel to assert (only one), and the T4 only has one that was routed out to external IO pin... So very different. With T4 in for example my ili9341_t3n library I got a very slight speedup by using DC on pin 10... But just slight.
 
I was able to get six displays running off of a Teensy 3.2. I had to use the updated library from https://github.com/PaulStoffregen/ST7735_t3 dated July 7, 2019.
I used SCK on 14, MOSI on 11, DC on 21. I used CS on 10, 9, 15, 20 (normal CS pins) plus pins 3 and 4.
I had to change the SPI clock down to 4 MHz to get it to work, but that's probably because of my long test jumpers.

140618.jpg

I'm building a "nearly NIMO" clock from https://www.hackster.io/paul-bricmont/nearly-nimo-clock-9309ec but I'm using a teensy 3.2 instead of a metro M4 + pro mini.
I'm using the teensy's RTC instead of a separate module. I use a 1 F capacitor connected to the teensy's VBat pin, charged through a schottky diode tied to the teensy's 3.3v out.
I set the time via a GPS module connected to Serial1. I also use a Bluetooth module tied to Serial3 to set the timezone and other options.
 
Update on my project ref OP.

So I ordered 8 of the Digole 160x128 OLED displays as mentioned by Michael in Post #10 (Thanks Michael - btw).
Got 7 of them hooked up and running on I2C OK-ish offline (ie just on a spare T3.6 with nothing else connected).
The 8th I managed to damage whilst soldering the Comms jumper pads.

I'm now starting to dabble with displaying what I need & am becoming quickly frustrated in trying to consistently produce inverse text.
ie different colour background for the text vs the main display background colour.

It would appear that the library does not directly support this feature & so a work around is to use XOR operations on the Font & a drawn rectangle underneath the text.

It appears to be very hit and miss & was wondering if someone could point me in the direction of some good documentation on this matter pls.

I'm not 100% sure what the correct terminology is for this stuff - so my searches are coming up relatively empty.

My Goal is to be able to Toggle a text string's background colour - to indicate if that item is enabled or not.

So main display background is BLUE.
Individual items are WHITE text
But if an individual item is enabled in my project - I'd like to change the item's string's Background colour to GREEN & the text to BLACK.
Then if toggled to disable - I'd like to change the item's string's Background colour to BLUE (same as main display ) & the text to WHITE.

Any pointers would be much appreciated pls.
 
You guys are mean. I did link to digole displays in post #8... snif. :confused:

Kidding aside, doesn't setting the background color ("BGC" + color) and foreground color ("SC" + color) using "C" mode suffice?
I.e., sending "BGC" + color + "SC" + color + "ETP" + xcoord + ycoord + "DMC" + "TT" + text + 0?

You see, pages 19-20 of the manual explicitly says that "DM" + "C", for "TT" command, it also clear the char box as background color, all other modes will not clear the char box.
 
TBH - I don't find the manual particularly easy to follow (probably just me).
Just looking for something a little more detailed & easier to follow
Hence my request.
 
One other thing - is there any way to use excel &VBA to calculate the resulting color from a BITWISING operation?

I see the digole displays use 8 bit (256) colour - where the inputted integer (0 to 255) represents RRRGGGBB.
So does that mean RRR & GGG can only represent values of 0 to 7 (111) & BB - 0 to 3 (11) ?
Or am I not understanding that correctly?

I was hoping to write some VBA script for Excel to take 2 RRRGGGBB values & set the cell Fill to the result of the BIT WISE operation.
Thanks
 
(I definitely agree, the manual is pretty bad.)

Yes, Red R and Green G are between 0 and 7, and Blue B is between 0 and 3, inclusive. The color value is B+4*G+32*R.

If r, g, and b are all between 0 and 1, inclusive, then R=max(0,min(round(7*r),7)), G=max(0,min(round(7*g),7)), and B=max(0,min(round(3*b),3)), and the color value is max(0,min(round(3*b),3))+4*max(0,min(round(7*g),7))+32*max(0,min(round(7*r),7)).

Or, you can rename the attached file as rgb332.html and open it in your browser to pick a color. (I am too lazy to add the Javascript for an interactive color picker, it being Friday here and all. :cool:)
 

Attachments

  • rgb332.txt
    17.2 KB · Views: 159
TRhanks - I'll take a look.

BTW - I'm using a Teensy MPC with arduino.
So I've been using teh arduino commands listed in manual.

Am I still able to send te other commands listed in the manual - ie "BGC" + color + "SC" + color + "ETP" + xcoord + ycoord + "DMC" + "TT" + text +0.

If so - How ?

I tried using "write" but get error - 'write' was not declared in this scope"
 
I've been using teh arduino commands listed in manual.
In that case, use
Code:
setBgColor(back);
setColor(fore);
setMode('C');
drawStr(x,y,text);
where back and fore are the R3G3B2 colors (0 to 255, inclusive), x and y are the coordinates, and text is the text to display. The setMode('C') is the crucial bit.
 
Cheers mate!

Worked a treat - thanks!!!

Been battling for days with this.

Any chance you could re-write the whoile manual so its easier to understand :)
 
Dont believe it.

Managed to burn out the i2c jumper pad again whilst soldering - aarrrg!!!!

Any idea if there is anywhere else on the board I can jump out to configure this for i2c comms pls?
 
That's why I got a cheap but temperature-controlled cheap soldering station, and use flux, leaded solder (60/40 or 63/37), acetone or IPA, and a tooth brush. To borrow a saying from welders about angle grinders: flux and acetone or isopropyl alchohol and leaded solder make me the solderer I ain't.

Teensy LC has two hardware I2C buses. By default, first one on pins 19 and 18, and the second one on pins 22 and 23. The first one has alternate pins, too:
card6a_rev2.png


Let's say your setup code is DigoleSerialDisp(Wire, 0x27); .
This means you're using the Teensyduino Wire library, and the default (first) I2C on pins 19 and 18.
If you change your setup code to
Code:
    Wire.setSDA(17); // Use SDA0 alternate pin, 17
    Wire.setSCL(16); // Use SCL0 alternate pin, 16
    DigoleSerialDisp(Wire, 0x27);
to use the alternate pins. Note that 19 moves to 16, and 18 to 17, so you'll "swap" your wires, not just move them two places.

Alternatively, use DigoleSerialDisp(Wire1, 0x27); to use the second I2C bus on the Teensy LC, on pins 22 and 23.
 
OOOP!!! Feel bad now - after Ive seen your reply.

Sorry - I should have been clearer - it was the jumper pads on teh Digole display that I fried.

I did the same on teh 8th of the forst batch of 8 I bought from China.
Just waited 3 weeks for the 2 re-rdered spares to arrive & Ive done the same on the first of those.
Fuming!
 
I once lifted a resistive touchscreen pad on a single-board computer, before they became common.. Multi-layer board, couldn't fix it. Expensive error. After that, I became much more careful. It is amazing how much using flux and good leaded solder helps, especially with lower temperatures so you don't burn out stuff. Then, afterwards, regardless if you were using no-clean flux, wiping and brushing with IPA or acetone, really makes a difference. Just sayin'... :D

When connecting paired pads (like jumpers), I now use a very short piece of tinned wire. Even if the gap is like 0.1mm or so, it helps a lot.
 
When you get it working like you want, consider posting a thread about the issues/gotchas and in general, the experience, you had. You know, to pass it forwards, and help anyone else possibly dealing with a similar situation in the future. 👍
 
hmmm
is the position of the i2c pull up resistors critical.
gone from being within 20mm from teensy to about 300mm and now getting corrupted displays.

could possibly the soldering as my iron packed in whilst doing them.
but wondering if distance could be issue too
 
You probably need to get stricter about what resistors are used, how far the total wire length is for the bus, the capacitance of all of the devices on the bus. I.e. things EE's presumably learn, but software jocks (like me) just resort to hand waving. Here is some reading of links I've clipped in the past or found via a quick google search:


Naively, I might expect an i2c bus multiplexer to help, as at any one time, you only have 3 devices on the i2c bus (Teensy, bus multipler, and the display it connects to) rather than having 8 displays + Teensy (but note, this is only a guess). I can imagine the total length of the wires for 8 displays might be beyond i2c limits:

 
Thanks mate.

I quick look at those links tells me all that stuff is way way way over my little head I'm afraid.

Guess I'll have to stick withtrial & error.
Started of with 4k7 ohm
 
just wondering if I've made an error in teh way I've wired these displays up too.

In essence, each of teh 8 displays has its 2 x i2c wires (each ~300mm in length) connected to a rail/bus on a board (so 8 to 1 for SDA & again 8 to 1 for SCL).
The board then takes a single wire for each (2 in total) which are connected to the Teensy pins (each ~100mm).

Would it be better to instead connect each display's SDA pins in series (~100mm apart) & teh same with SCL pins (~100mm apart)?
ie Teensy SDA pin to SDA pin of Display 1, then SDA pin of Display 1 to SDA pin of Display 2, then SDA pin of Display 3 to SDA pin of Display 3, etc.
and similar for SCL

Or is it "electrically" teh same?
 
Last edited:
Nice project.

My first 'hand-waving' would be to try a stronger pull-up, I think 2k4 is recommended for 3.3v Teensy, 4k7 is for 5v.

I have had 5 I2C devices wired in serial with 400mm to the pins, tho this was using a nano @ 5v prior to discovering the Teensies so really not of relevence here.
 
Thanks
I was powering the displays off teh 5v Vin pin.
But using the 3.3v pin fr the pullups.
Is that the prefered way.

\Guess |I should not use teh 5v supply of the pullups - right?
 
No, you should use the 3.3V pin for the pullups. Smaller resistance yields stronger pullups, because the current is higher then.

What kind of cable/wire are you using for the I2C? Personally, I'd use shielded cable (two signal wires, with a foil shield; shield connected at one end to GND). Something like Tasker C2015, except perhaps thicker conductors (just in case, I'm paranoid).

I don't know which topology would work best for you, but comparing just raw length, 8×300mm = 2.4m, whereas 300mm + 8×100mm = 1.1m. To me, this indicates that the one chain approach might be better. However, only testing would tell.
 
Status
Not open for further replies.
Back
Top