NEW: GC9A01A Display driver for Teensy 3.x and Teensy 4.x

Quick question - should I expect this to be working OK with non-default /CS?

Having some problems with a display from AliExpress which looks like this one. The Google Translate of the Chinese silkscreen is ambiguous: "this module can not connect CS, RST" - it may be saying /CS and /RST are optional, or that they shouldn't be connected ... I have connected them.
1751576730609.png


My question arises from being slightly concerned at finding this comment in the source
C++: 
// BUGBUG:: currently assumming we only have CS_0 as valid CS
I have /CS on 22, and DC on 9; /RST is on 6, but guessing that's academic.

Misbehaviour is with the graphicstest.ino sketch - when it gets to drawing lines and rectangles, the display goes garbled and then fades out entirely, though interestingly once it's reset, and before it's cleared to black, it looks as if the right data might actually have made it to the graphics RAM.
 
Which teensy? T4.x not as important to have Cs and dc on hardware Cs pins. On these boards you can not use multiple cs pins at
the same time… 3.x different story
 
Sorry - Teensy 4.1.
KurtE said:
On these boards you can not use multiple cs pins at the same time
Click to expand...
Can you clarify that? At the moment I only have the one display, but the reason I’ve used 22 as /CS is that 6 and 10 are potentially used by the audio adaptor. One possible future test would have two displays.
 
h4yn0nnym0u5e said:
Sorry - Teensy 4.1.

Can you clarify that? At the moment I only have the one display, but the reason I’ve used 22 as /CS is that 6 and 10 are potentially used by the audio adaptor. One possible future test would have two displays.
Click to expand...
In the Teensy 3.x boards, there were a bunch of 'special' pins. Paul documented this many years ago in (look at comment #5):

As I understand it, the display drivers for Teensy 4.x don't have this special optimization.

I believe that in the Teensy 4.0, pin 10 is a special pin for the first SPI bus, and pin 0 is a special pin for the second SPI bus, so it isn't possible for DC and CS to both be on special pins. Teensy 4.1 adds two more special pins (36 and 37) for the first SPI bus and one more special pin (38) for the second SPI. Thus 2 SPI devices can't on the same SPI bus because you don't have enough special pins to have both DC and both CS pins as special pins.

For uncanny eyes, I tend to put one eye on the first SPI bus and the second eye on the second SPI bus.
 
Thanks @MichaelMeissner. So maybe what @KurtE is saying is that multiple “special” /CS pins aren’t a feature of Teensy 4.x, but that it’s not too important anyway because it’ll only make a few nanoseconds’ difference if a non-special (like 22) is used.

As you say, the rational approach is to use the second SPI bus for multiple displays, which is why I felt I had to ask if alternative /CS pins were known working - I couldn’t find any definitive statement where someone had actually done it.

I suspect this isn’t a library issue at all (these things usually aren’t…), but the comment did raise a flag for me. Then again, there’s still a lot of legacy cruft in there - even the graphicstest sketch still claims to be testing the ILI9341!
 
Right ... so this morning, everything's working fine ... no (deliberate) changes to anything! Weird, because even if it's dodgy wiring I would expect nothing to work, not just some of the tests.

Anyway, confirmed that the library can indeed work with the non-default /CS.
 
h4yn0nnym0u5e said:
Anyway, confirmed that the library can indeed work with the non-default /CS.
Click to expand...
Was just catching up on the threads and glad you got it working - was going to say that as far as I remember it should work with a non-standard CS pin as long as it is a digital pin which Teeny 4.1 pins are that you would use.
 
h4yn0nnym0u5e said:
Right ... so this morning, everything's working fine ... no (deliberate) changes to anything! Weird, because even if it's dodgy wiring I would expect nothing to work, not just some of the tests.
Click to expand...
Glad it is working, Been a while since I pulled mine out of the cabinet. One of the early posting from 3 years ago, shows it running
a version of the Uncanny eyes sketch, with two of the displays.

Edit: Oops, I forgot to hit the post reply this morning...
 
Awesome.

I just ordered some of these screens. I've been making paired down drivers that do partial screen updates using DMA suitable for graphics libs like LVGL that produce bitmaps but don't have their own hardware interface with the library. That's all my drivers do is send bitmaps to the display, but it's perfect for LVGL and also for UIX. The advantage is it saves on flash space and compile times when you all you want is to use LVGL for example, and it can do partial screen updates using DMA which is often more performant than having to update the entire display with every transfer.

I hope you don't mind, but I intend to take a look at your code so I don't have to learn the hard lessons you did making it. I'll credit your work in my source.

Thanks for making this!
 
You must log in or register to reply here.
Back
Top