Highly optimized ILI9341 (320x240 TFT color display) library

Thanx for the quick answer.

Unfortunately I don't have an oscilloscope. And I did not build the device, so cant say anything about if the right pins are used (the code assumes the default pin for MISO.) Just doing some coding help for a friend who built it...

Do you know of a code snippet with which I could check some predictable return value from the display? Say - pixel resolution or rotation state? The get-functions in the ILI-libraries unfortunately just return preset values they keep in store for that, without actually reading out those values...
 
As mentioned, would help to see the actual wiring. That is the display will probably work fine output only without the MISO pin connected, but the Read won't work it it is not setup with it.

Some of the test programs I believe will print out some register values at the startup of the program.

Example graphictest for ili9341_t3 library starts off with:
Code: 
 Serial.println("ILI9341 Test!"); 

  // read diagnostics (optional but can help debug problems)
  uint8_t x = tft.readcommand8(ILI9341_RDMODE);
  Serial.print("Display Power Mode: 0x"); Serial.println(x, HEX);
  x = tft.readcommand8(ILI9341_RDMADCTL);
  Serial.print("MADCTL Mode: 0x"); Serial.println(x, HEX);
  x = tft.readcommand8(ILI9341_RDPIXFMT);
  Serial.print("Pixel Format: 0x"); Serial.println(x, HEX);
  x = tft.readcommand8(ILI9341_RDIMGFMT);
  Serial.print("Image Format: 0x"); Serial.println(x, HEX);
  x = tft.readcommand8(ILI9341_RDSELFDIAG);
  Serial.print("Self Diagnostic: 0x"); Serial.println(x, HEX);
So what do these registers print out as?
 
all requests return the same:

ILI9341 Test!
Display Power Mode: 0x3
MADCTL Mode: 0x3
Pixel Format: 0x3
Image Format: 0x3
Self Diagnostic: 0x3
 
Sounds like it is not working properly...

Again without seeing the actual wiring, it is hard to say what is wrong.

Also any additional devices connected up to the SPI pins?
 
ok, I finally got a qualified reply from my friend who built it.
You both were totally right: the MISO-pin was not connected properly, but he forgot this fact himself. (Before I gave it a try he also spent some time trying...)

*sigh*

So - everything was a false alarm. It could never have worked like it is. :-/

Nonetheless - Thanks for your help!!
 
Amazing work on the optimised library!

@Frank B -
Thanks for your work on Google font files! Would it be possible for me to request OpenSans please?
Secondly, is your ILI9341_t3DMI library still valid, or are the DMI improvements now part of the main t3 library?
 
ohhorob said:
Then I tried another display (higher density) and have not been able to make it work at all yet. I used an oscilloscope to look at the MISO waveform, and it's too low and noisy for Teensy to register the values at any speed. I'm going to try a custom PCB to see if that cleans up the signal enough to be serviceable. Otherwise I'll need to abandon the display and find another.
Click to expand...

This is the display -- https://www.crystalfontz.com/product/cfaf240320w020t-TFT-240x320-IPS

I purchased it on the carrier board, and built this simple board for it to connect with Teensy 3.6.

eb17139aaf5abea1067b2a22daa81cd5.png

Turns out the MISO pin is floating :(

However the controller is pushing the output signal on the MOSI line, so I've slowed down the clock and used a 1K resistor from MOSI to MISO, and MISO directly to the display data line.

This works now for read/write, but it's slower than I'd like.. should I be able to omit the resistor and tie MISO and MOSI??
 
the resistor will prevent high speed transfers

did you set your pin to output and drive it deasserted before running the library itself?
 
tonton81 said:
the resistor will prevent high speed transfers

did you set your pin to output and drive it deasserted before running the library itself?
Click to expand...

Is "deasserted" simply writing low to the pin?

I haven't tried that yet. Would that make it safe to omit the resistor and bring up the clock speed?
 
Hello everyone. I am new to the forum, and wanted to congratulate you on this great work.
I am newbie also on this matter, and I have been using the ILI9341_t3 raftly for a month already, and very happy with it.
Yesteday I found an error that drove me crazy with the fillRectHGradient funtion. The error comes when calculating the delta color it is using the height instead of the width. The formula should be: dr=(r2-r1)/w; dg=(g2-g1)/w; db=(b2-b1)/w; instead of dr=(r2-r1)/h; dg=(g2-g1)/h; db=(b2-b1)/h;, as it is calculating a horizontal gradient.

Hope it helps.
 
rickusb said:
Hello everyone. I am new to the forum, and wanted to congratulate you on this great work.
I am newbie also on this matter, and I have been using the ILI9341_t3 raftly for a month already, and very happy with it.
Yesteday I found an error that drove me crazy with the fillRectHGradient funtion. The error comes when calculating the delta color it is using the height instead of the width. The formula should be: dr=(r2-r1)/w; dg=(g2-g1)/w; db=(b2-b1)/w; instead of dr=(r2-r1)/h; dg=(g2-g1)/h; db=(b2-b1)/h;, as it is calculating a horizontal gradient.

Hope it helps.
Click to expand...
I believe this has been fixed for a long time in my ili9341_t3n version of the library (github kuirte)

I believe this is also part of the big Pull request I had a year ago: https://github.com/PaulStoffregen/ILI9341_t3/pull/41

But as I mentioned that was a big Pull request... Things like: Still works when only DC is connected to a hardware CS pin... Ability to set drawing offsets, the ability to set clipping rectangle...
 
Greetings all!
I'd like to use the TFT color display on SPI1 on a Teensy 3.6 project.

Am I right in thinking that I should be using the KurtE library? Can anyone point me towards any examples of this usage? I've read (most!) of this thread, plus the KurtE library thread, and I will admit to being a little confused about a couple of things. I'm sure an SPI1 example would help a lot.

Cheers, Doug
 
spi0 would be faster as it has a 4 item FIFO queue, SPI1 only has 1. kurts library would be the fastest provided you use the spi0 of course
 
Does anyone know how to convert a font file (otf or ttf) for use with the libraries, as Frank B was doing? He doesn't seem to be around at the moment :)
 
As mentioned SPI0 is faster than SPI1 and SPI2, but SPI1 and 2 are still very usable, as they still pretty well double buffer, so probably most of the time we can still keep things going pretty much at full speed.

As for example of how to use it with SPI1... The example program graphictest has a bunch of #define/#ifdef for different configurations including some for SPI1. Actually I believe there are two examples. One that uses normal pins and the other was setup to be able to use a MicroSD adapter that gave you access to the underlying pins, which you could then use for SPI1...

So for example if your defined the TFT object like:

Code: 
#ifdef SPI1_DISP
#define TFT_DC 6 // 0xe4
#define TFT_CS 7 // 0xe5
#define TFT_SCK 32 //0xe2
#define TFT_MISO 1 // 0xe3
#define TFT_MOSI 0 // 0xe1
#define TFT_RESET 8
ILI9341_t3n tft = ILI9341_t3n(TFT_CS, TFT_DC, TFT_RESET, TFT_MOSI, TFT_SCK, TFT_MISO, &SPIN1);
#endif
It would use the SPI1 pins (SPIN1)... Note: the code was also setup that you could ignore specifying which SPIN object to use (SPIN1 -> SPI1), as the code will see that the pins specified were not valid for SPI and so it will check to see if they are valid for SPI1 and if not SPI2...

Other than than that init, same usage pattern.
 
tonton81 said:
spi0 would be faster as it has a 4 item FIFO queue, SPI1 only has 1. kurts library would be the fastest provided you use the spi0 of course
Click to expand...

I'm trying to add the display to an existing board that has SPI1 available. SPI0 would require a layout change (which could be done, if really required).
If SPI1 is just a bad option, then I'll not waste any more time on it...
 
@Projectitis:

I've just converted the files... see attachment.
Perhaps time to update my whole google-fonts archive... Unfortunately I deleted the Virtual Machine where I had my code for batch-processing all files. Have to re-write it..
 

Attachments

  • opensans.zip
    1.1 MB · Views: 268
  • LICENSE.txt
    11.3 KB · Views: 378
Last edited:
KurtE said:
So for example if your defined the TFT object like:

Code: 
#ifdef SPI1_DISP
#define TFT_DC 6 // 0xe4
#define TFT_CS 7 // 0xe5
#define TFT_SCK 32 //0xe2
#define TFT_MISO 1 // 0xe3
#define TFT_MOSI 0 // 0xe1
#define TFT_RESET 8
ILI9341_t3n tft = ILI9341_t3n(TFT_CS, TFT_DC, TFT_RESET, TFT_MOSI, TFT_SCK, TFT_MISO, &SPIN1);
#endif
Click to expand...

Hmmm, I'm only getting a blank, white, screen when I use the above definitions (and hookup appropriately!). The only difference I have is TFT_RESET 255, because I have that pin tied to 3.3V. (I did make sure that SPI1_DISP is #defined).

The graphicstest program from the ILI9341_t3n library seems relatively happy, returning the following over serial:
ILI9341 Test!
After TFT Begin
0
Display Power Mode: 0xCE
MADCTL Mode: 0x24
Pixel Format: 0x2
Image Format: 0x0
Self Diagnostic: 0x0
Benchmark Time (microseconds)
Screen fill 225067
Text 11551
Lines 60026
Horiz/Vert Lines 18414
Rectangles (outline) 11704
Rectangles (filled) 462564
Circles (filled) 70791
Circles (outline) 56546
Triangles (outline) 14487
Triangles (filled) 154526
Rounded rects (outline) 25380
Rounded rects (filled) 505430
Hit key to continue
Done!

Any thoughts on what I might be missing? I've carefully checked the hookup n+1 times...

Doug
 
Doug, I wonder if not resetting the display could be a problem? I'm not sure what the symptoms are though.
The code ILI9341_xxx::begin specifically resets the display before sending the init commands:
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);
	}
Or are you resetting manually/some other way?
 
That was it! (I should have tried that earlier).
I had been simply tying Reset high because of the connection table on the PJRC product page and assuming it was required only for special circumstances. Silly me...
 
I have found in many cases you don't need the reset line, but then I get a display that appears to need it... Not sure why...
 
You must log in or register to reply here.
Back
Top