Teensy 4.0 with Audio Board and ILI9341 screen wiring

Kurt,
I did give your suggestions a try. I dropped the SPI clock freq to 20^6Hz and still no dice. I also downloaded the beta TDI but from what I Can tell, no changes were made to the ili9341_t3 library between the latest release and the beta.

There are other examples of running this exact display I have on the T4 and from what I can see, I've got everything in place. I found a guy that had schematics and code just shortly ago and I'm pretty convinced that I popped something in the display.

I would like to contribute back to this community in any way I can so this may be an opportunity to do that with a comprehensive thread on using these displays with the 4.0, options with the libraries out there, some benchmark tests, and some tweaking of the libraries to see if more performance can be had.
 
Might help to see a picture of your setup as well as maybe a quick summary of what pins are hooked up to the display...

I have not done much with Audio board on T4 in awhile, in fact have not use the new T4 version of it yet... I did purchase two, so maybe tomorrow I will solder one up, and setup with display to make sure there are not other issues.
 
I have a videos of my rig running on the T3.5 using the ili9341_t3n library. I was using limiting resistors between the TFT and T3.5 for obvious reason. The new setup simply has the T4.0 in the position where you see the 3.5 and it was working pretty well - I like to think I'm not a total idiot, LOL.
https://www.youtube.com/watch?v=wk2FauuPKqk

These boards are pin compatible for the connections used here so this code is where I Started with. Troubleshooting the T4 not working, I moved some of those around, 255'd the RST and took the TFT RST to the 3.3V bus, moved DC around to no avail.. And there is only one CS line on this board so that had to stay at pin10. I tried moving the clock around to no avail... Same with the DC line..... and RST I've tried direct to the 3.3v+ bus, pulled up by 10K to the 3.3v+ bus, and on a few different digital pins. I also tried 10K pullup resistors on the CS and DC lines as I came across that suggestion somewhere here or on the ardy site... over the 14+ hours I've been learning volumes about this topic. :)

I had this display running on an Arduino Micro originally just playing around with it, using the Adafruit library, but that micro is painfully underpowered for what I wanted to do with it.
https://www.youtube.com/watch?v=CKPnREocxWs

The 3.5 and 4.0 have these pins in the same location which was convenient but this is what WORKS on the 3.5. I REALLY want the t3n library as it has the framebuffer which sped things up immensely and the T4 should only further improve on it's performance. All of the little icons in the program were manually drawn out, painstakingly I may add, lines, circles, text, etc.. I would really prefer to be able to use small bitmap files with more realistic images in them and a background texture underneath everything else... That may be wishful thinking though - I dont think these libraries have developed far enough to handle layers, sprites, and 3d mapping seems around the moon and back from what I have come across..

So, nothing really special in the code below... Pretty cut and dry. Obviously given the T4 is a 3.3V system, I have removed the limiting series resistors and the display is wired direct to the T4.

Code:
#include "ILI9341_t3n.h"
#include <SD.h>
#define TFT_CS   10  // CS & DC can use pins 2, 6, 9, 10, 15, 20, 21, 22, 23
#define TFT_RST   8  // RST can use any pin
#define TFT_DC    9  //  but certain pairs must NOT be used: 2+10, 6+9, 20+23, 21+22
#define TFT_MOSI 11  // MOSI can also use pin 7
#define TFT_SCLK 13  // SCLK can also use pin 14
#define TFT_MISO 12
ILI9341_t3n tft = ILI9341_t3n(TFT_CS, TFT_DC, TFT_RST, TFT_MOSI, TFT_SCLK, TFT_MISO);
 
Additionally, Some odd behavior in the graphicstest examples..

Running the Adafruit ili9341 library, serial monitor reveals this:

Code:
Display Power Mode: 0x4

MADCTL Mode: 0x48

Pixel Format: 0x5

Image Format: 0x80

Self Diagnostic: 0x0

Benchmark                Time (microseconds)

Screen fill              855113

Text                     40875

Lines                    386405

Horiz/Vert Lines         69823

Rectangles (outline)     44407

Rectangles (filled)      1774730

Circles (filled)         199066

Circles (outline)        169034

Triangles (outline)      88231

Triangles (filled)       575280

Rounded rects (outline)  81884

Rounded rects (filled)   1764108

Done!

The Modes and formats actually have non zero values in them. While the T4 is running this example, there is no image on the screen, but it isn't full bright either. It dims and flickers in stride with the test steps in the monitor.. so it seems like "something" is happening but nothing pretty, LOL.

When I run the T3 or T3N libraries' test examples, all of the header mode/format values come back zero, the display is hard white, no flickering though..
 
@AshPowers - Before I dig in my box to grab the new T4 Audio adapter. I can already see you have conflict here.

You show:
Code:
#include "ILI9341_t3n.h"
#include <SD.h>
[COLOR="#FF0000"]#define TFT_CS   10 [/COLOR] // CS & DC can use pins 2, 6, 9, 10, 15, 20, 21, 22, 23
#define TFT_RST   8  // RST can use any pin
#define TFT_DC    9  //  but certain pairs must NOT be used: 2+10, 6+9, 20+23, 21+22
#define TFT_MOSI 11  // MOSI can also use pin 7
#define TFT_SCLK 13  // SCLK can also use pin 14
#define TFT_MISO 12
ILI9341_t3n tft = ILI9341_t3n(TFT_CS, TFT_DC, TFT_RST, TFT_MOSI, TFT_SCLK, TFT_MISO);

Now if you look at the product page for the Audio Adapter: https://www.pjrc.com/store/teensy3_audio.html
You will see that it uses pins:
Code:
Function	Teensy 4.0 Pins(Rev D)	 Teensy 3.x Pins(Rev C)	Shareable
Audio Data	7, 8, 20, 21, 23		9, 11, 13, 22, 23	
Audio Control	18, 19		18, 19	SDA, SCL (other I2C chips)
Volume Pot	15 (A1)		15 (A1)	-
[COLOR="#FF0000"]SD Card		10[/COLOR], 11, 12, 13	7, 10, 12, 14	MOSI, MISO, SCK (other SPI chips)
Memory Chip	6, 11, 12, 13	6, 7, 12, 14	MOSI, MISO, SCK (other SPI chips)

So pin 10 is used as the Chip select for the SD Card that is on the adapter. So you need to change your TFT_CS to some other unused pin

Again you should refer to the pin usage table on the product page. Sorry if the copy I put here, all of the lines don't align properly.

Kurt
 
You can do that with the T4.0? I thought you HAD to use the only CS pin on the T4, pin 10.

I gave it a shot using pin 6... No dice...
 
Well, while waiting for the replacement screen to show up I figured I'd connect the T3.5 back in and give it a final test... And behold! The TFT is just fine...

What a total pain in my arse.

Can someone please put together a proper wiring diagram and some libraries that actually work? 2.5 days spent trying to get a damn SPI TFT running. *Sigh* And still not working.
 
I am not having any problems?

Again Look at the table I pointed to in previous post. Look at the next line down from SD Card, and you will see pin 6 is used for Memory Chip...

So I wired up my display using
DC = 9
CS = 5
Reset = 4

I tried it with both ILI9341_t3 and ILI9341_T3n

If you try with _t3, you need to edit the defines at the top of the program. Mine now looks like:
Code:
// For the Adafruit shield, these are the default.
#define TFT_DC  9
#define TFT_CS 5
#define TFT_RST 4

// Use hardware SPI (on Uno, #13, #12, #11) and the above for CS/DC
ILI9341_t3 tft = ILI9341_t3(TFT_CS, TFT_DC, TFT_RST);

Again some of the web pages need to be updated for the T4. In particular the stuff talking about CS pins.
Actually SPI pins in general.

That is on the main SPI object there is only one valid pin for each of the functions: (MOSI=11, MISO=12, SCLK=13). And there is one CS pin. The SPI hardware on the T4 is completely different than the T3.x chips.
In particular on how the T3.x has a FIFO queue where each element is 32 bits, and top 16 bits allow you to encode data like which hardware CS pins to change state of, and some other information that says how big the data word is, which in our case is either 8 or 16... I won't go into all of the details, but you can get a good speed up when DC is on hardware CS pin as you can encode this data on the FIFO and not have to wait for data to be fully output when changing the state of DC as such you get very little time wasted on the SPI buss. You also can get a slight speed up with the CS being on hardware CS.

The T4 SPI also has a FIFO, where each element is 32 bits, but the entries are either Data or a command. Plus side is you can have 32 bit SPI data outputs. The other side is that changing states of how many data bits and CS state is done as separate command word on FIFO and we only exposed one CS pin on the T4... Again you can get some speed up with that pin being used for DC. But as pin 10 is often used by default by other hardware, in this case Audio board, the code was updated to allow non Hardware CS pins to be used...
 
You are right, I didnt' see that pin 10 was being used.

So I changed the pin settings to your recommendation with the T3.5 connected and it works like a champ. I also found that you can hook the T3.5 to this display without series resistors. Seems to be working A-OK.

Then I put the T4 in place and no love. I'm wondering if there is something wrong with the T4? Any way to diagnose this? I have a scope, logic analyzer - what should I be seeing on these lines?
 
Hard to say... Helps to see your actual hook ups. Good connections? Pins soldered...
Hard to know what is wrong with the description: no love

When I have no joy from things like this not working, I would hook up one of my Logic Analyzers, to all of the pins, like:
MOSI, SCLK, CS, DC, probably MISO as well and if you have your display hooked up to a reset pin, then that one as well.

Then I would restart the program, and make sure that the Reset pin, looks like it is high goes low and comes back up high.

I would make sure that it looks like valid SPI information going out. That is the CS pin is HIGH, goes low, you see the SPI Clock pin give you the pulses for the clock and the MOSI pin changes. and likewise some of the DC pins high during transfers (Data) and sometimes low with data being transferred (Command)...

I will often times add some debug printing to the library, example in the begin or init method, might add debug prints showing the actual Pins that were passed in...

I would also verify that the copy of the library I am running is the latest version up on github (www.github.com/paullstoffogren/ili9341_t3)...

I don't remember if there have been any other changes taken in since the last Beta of Teensyduino. I suspect that soon we will have a new released version of Teensyduino.
 
OK, I have put together a video showing my setup. I downloaded the library from Paul's GITHUB page here:
https://github.com/PaulStoffregen/ILI9341_t3

I removed all other instances of the t3 version that I had previously. I used the example that comes as part of his library and changed a few of the pin assignments around as follows:

Code:
#define TFT_DC 9
#define TFT_CS 7
#define TFT_MOSI 11
#define TFT_MISO 12
#define TFT_RST 255
#define TFT_SCLK 13

// Use hardware SPI (on Uno, #13, #12, #11) and the above for CS/DC
ILI9341_t3 tft = ILI9341_t3(TFT_CS, TFT_DC);

I recompiled and uploaded to both the 3.5 and the 4.0. The video shows you what I am seeing as a result. All of my connections are solid, it works just fine with the 3.5. The 4.0 flickers the screen but none of the test visuals appear.

https://www.youtube.com/watch?v=sFW-QoxVz4w

In addition, I just added LEDs into the setup, connected to the following:

CS: YELLOW
DC: RED
MOSI: BLUE
SCK: GREEN

They seem to be all be functioning in the same manner but a obviously something is different. At least we know the most important pins ARE actually sending signals though. So, it has to be something that is different in the 4.0, yea?

HEre's the video:
https://www.youtube.com/watch?v=mctoKCArOqI
 
Last edited:
I have connected my digital analyzer to the 4 main lines to see the difference in signals.

T3.5
SCLK: 143KHz stable in the first ~40ms and then it bounces around from 20KHz to 400KHz.

T4: ~4KHz to 6KHz, unstable, in the first 40ms or so. Then the CLK ramps up and bounces around from 20KHz to 400KHz.

It looks like both 3.5 and 4.0, the DC line is normally high, at the beginning of a cycle, the DC pulses low and the CLK pulses while CS pulses high at ~equal intervals, MOSI is buzzing along in chunks at the CLK timing period..

The biggest difference I See here in in the CLK...

This is the 3.5:
t35-displayout1.jpg

This is the 4.0:
t40-displayout1.jpg
 
With only 1 MHz samplerate you will not see anything useful.
All you can say s, that you can see some toggles, Your "measured" clkrates are totoally wrong.. they're in the MHz range :)

So I'd say you may want to buy a better LA. :)
 
I now saw your video. I'd say the connections are too long and unreliable. Try shorter wires - are there LEDs in the connections?
Remove them, and directly connect Teensy+Display.
 
Frank, too long? Why does it work just fine with the T3.5 then?

As for removing the LEDs, I only put them in there for testing purposes. I have tried it both with and without the LEDs in the circuit. It works perfectly with the T3.5 but not with the T4.... with or without LEDs.
 
In an interesting twist, the replacement TFT I just received actually works with the T4. I changed nothing in the wiring at all - simply removed the original TFT from the breadboard, plugged in the new one, and voila - it works just fine... It also works with the T3.5 as well.

So I'm not exactly sure what the difference is between these two TFT modules. On the backside of them, the original is labeled as V1.2 and the one I just received is a v1.1. The TFT module itself looks identical but there are variations in the circuit board... and the variations really only appear to be in the placement of components...

So, playing around with the SPICLOCK and the library used, performance appears to be the same for ili9341-t3 and t3n.

at 72MHz SPICLOCK (display goes unstable periodically around 80MHz)
Code:
_t3n::begin mosi:11 miso:12 SCLK:13 CS:10 DC:9
   T4 setup CS/DC

_t3n::begin - completed

After TFT Begin

15

Display Power Mode: 0x0

MADCTL Mode: 0x0

Pixel Format: 0x0

Image Format: 0x0

Self Diagnostic: 0x0

Benchmark                Time (microseconds)

Screen fill              102781

Text                     5924

Lines                    38846

Horiz/Vert Lines         8878

Rectangles (outline)     5723

Rectangles (filled)      211145

Circles (filled)         36989

Circles (outline)        33303

Triangles (outline)      9116

Triangles (filled)       75440

Rounded rects (outline)  13917

Rounded rects (filled)   234990

My question now is, can this performance be improved upon? I'm running the T4 at 816MHz and using the Faster option for the compiler.

Is there a relationship between the processor's clock frequency and the SPICLOCK frequency that will affect overall performance or is the best performance simply a matter of running the processor and SPICLOCK as fast as possible before the display loses stability?
 
Getting v1.2 display working with Teensy 4.0

I struggled as you, to get this display to work with T4.0 (never tried on other board either).

Same problem as you, white screen or some flickering characters but obviously something wrong. (Graphicsdemo from Library)

What worked was lowering the speed. Tried first at 150Mhz which worked directly. Voila!
Tried every speed up to 528MHz and that worked good. Even tried at 600MHz again but that worked somwhat but with some flickering. But when I went higher it went back to the white screen with kind of noise.

After this I needed to power Off/on the device to get it to work at 528MHz again.

..I guess this can hava something to do with cable lengths/interference between cables/poor connections at high speeds?

However, try at lower speeds with your original v1.2 display. It would be interresting to get this confirmed.


Frank, too long? Why does it work just fine with the T3.5 then? 20200211_205911.jpg

As for removing the LEDs, I only put them in there for testing purposes. I have tried it both with and without the LEDs in the circuit. It works perfectly with the T3.5 but not with the T4.... with or without LEDs.
 
Hello,

I just received the ILI9341 and would like to connect it to the Teensy 4.0 with the Rev D audio adapter.
I tried without the audio card, respecting the wiring indicated on PJRC, it works well.

I read the whole thread, but I won't be able to summarize what is the wiring to do to make this work for:
- the TFT display
- the touch screen
- the audio card + its SD reader

please can you help the newbie that I am... thanks !
 
I faced the same. I think it's going to be very difficult to find enough IO for everything (even though MOSI/MISO/SCK for SPI can be shared and each SPI device just needs its own chip select). I could setup Teensy+ILI or Teensy+Audio and get each to work but not all 3. I therefore put the ILI off to one side while I got on with developing the synthesizer core with just Teensy 4 + Audio.

Because I knew more flash (for wavetable samples) would be good and because I knew that to eventually combine all three to include the ILI I would need more pins I actually picked up a Teensy 4.1 to replace Teensy 4.0 back during the last Black Friday sales. But since then I haven't tried putting ILI back into the design - but I think you'd stand a whole lot more chance with a Teensy 4.1

These videos show my early experiments with ILI connected to Teensy 4.0:

https://youtu.be/JX2qGT2LkCs
https://youtu.be/fmQxh2z7Bv4

As you can see, and I'm sure you are already aware, to simply get the display and the touch interface working already takes a LOT of wires/pins!

I know it's $30 or something but you will probably lose a lot less hair by just considering Teensy 4.1 as a replacement (then use the Teensy 4 for a more "cut down" synth design later - which is what I'm doing).

EDIT: BTW the code used in one of those was here: https://github.com/wrightflyer/mouse_graphics/tree/master/teensy_touch
 
I will try several wiring to operate the SD card, the touch screen, the audio card and the screen.

To see more clearly with the use of pins, I made a diagram for myself, I will complete it with the ILI after my tests.
Here is this diagram if it can be useful to someone...

Teensy_4_audio_adaptator_wiring.jpg
 
Yeah I have a very sketchy diagram here:

https://github.com/wrightflyer/Synth
View attachment 23266
As you can see that is just the T4 pinout, the audio board pinout then a few annotations to show what's left.

As far as I can see, once T4 is connected to audio then you are left with pins:

0, 1, 2, 3, 4, 5, 9, 14, 16, 17 and 22

Of course MOSI(11)/MISO(12)/SCK(13) for the SPI can be shared as long as each SPI device has it's own CS signal (like SDCS on 10).

The ILI needs connections to:

CS, RESET, DC/RS, MOSI, SCK, MISO, T_CLK, T_CS, T_DIN, T_DO, (T_IRQ)

I guess it should be do-able on what's available but if the synth wants to have some user control (maybe just UART_RX for MIDI IN?) then you are going to be VERY tight on pins.

For mine I wanted 8 encoders and a two axis joystick (mod/pitch bend) so even using multiplexers it is tight.
 
good idea the multiplexer.
What is the tft reset pin used for? because I see that it can be connected directly to 3.3v which saves a pin.

a solution to gain pins would be to deport the commands to another microprocessor (arduino, teensy ..) and connect it to T4 by serial bus or i2c or radio
 
I have a feeling I first read about reset in this thread. I have a feeling the driver maybe uses it to be sure the display is in a "known state" in the communications but I seem to remember that it may actually be optional.

The c'tor for the driver has:
Code:
class ILI9341_t3 : public Print
{
  public:
	ILI9341_t3(uint8_t _CS, uint8_t _DC, uint8_t _RST = 255, uint8_t _MOSI=11, uint8_t _SCLK=13, uint8_t _MISO=12);
so "_RST" is being set to 255 if not specified. When I invoked it I simply used:
Code:
#define TFT_DC  9
#define TFT_CS 10
#define TOUCH_CS 8

...

ILI9341_t3 tft = ILI9341_t3(TFT_CS, TFT_DC);
XPT2046_Touchscreen ts(TOUCH_CS);
so I'm reminded that I did not set it. It seems that the only use of it is in the begin() method when it does:
Code:
	// toggle RST low to reset
	if (_rst < 255) {
		pinMode(_rst, OUTPUT);
		digitalWrite(_rst, HIGH);
		delay(5);
		digitalWrite(_rst, LOW);
		delay(20);
		digitalWrite(_rst, HIGH);
		delay(150);
	}
So basically it's only going to attempt that reset sequence once in the begin() if you happen to have given a 3rd parameter in the c'tor. So it can be left N/C and ignored I guess.
 
Correct, in most cases the reset on the display is not needed.
You also don't need some pins of the audio shield.
I.e. if you don't use the potentiometer, you don't need pin 15.
If you don't need the SD card on the Audio Shield (and don't use the Flash), you can also omit these pins.
For this purpose it is best to have a look at the circuit diagram of the Audio Shield.
https://www.pjrc.com/store/teensy3_audio.html
 
Back
Top