ILI9488_t3 - Support for the ILI9488 on T3.x and beyond...

I have version up at (kurte) in the branch build_fix which fixes the build...

Recently we only had one configuration we were testing. I will run it on a couple of configurations and do a PR back...
But in the mean time, you can take a look at my branch....
:eek:
 
Thank you, I wasn’t very clear in that last post. The library
Can be installed in the - hardware>teensy folder, where the teensy specific libraries get put when installing teensy loader, or I can install it in the “standard” libraries folder. I realize I have it in both places now, but I did not initially. First I installed it in the standard Arduino libraries folder, I then put a copy in the teensy specific hardware folder just to see if it made a difference.

The problem I am having is that it will not compile, I have tried several of the example codes while selecting either t3.6 or T4.0 and it always fails with the same error listed above. I will download the latest version and update TL and hopefully that will fix it. Thanks
 
Understood. After your report I went through and hopefully fixed the issues. Which @mjs513 merged in. So you will need to download the updated code.
 
@KurtE
I just pushed a PR to resolve the " Fix compile issues with file name and conflict with STL containers" that was seen on the ILI9341_t3n by @Blackaddr.
 
@KurtE
Just incorporated it into the HX... library.

Also just pushed a PR to @Paul to update the ST7735 library as well. RA8875 does not suffer from the same affliction at least for "swap" it uses its own "swapvals".
 
@mjs513... My ST7735 branch also has fix for swap and one font file case name fix as well..
 
@KurtE
Shoot - forgot about checking the example - will update it now.

EDIT: Just updated PR with the example sketch fixed
 
@mjs513 - Good morning again...

I thought for quick test to see if SPI2 is defined properly for T4.1 beta at least looks like it outputs something to the memory pins, I started to hack up the continuous update test...
And ran into issues with the ILI9488_t3 constructor (or my laziness). Which I can get around. But wondering what you think if I make the constructors work work more consistent with some of our other libraries.

That is my test, is to first make sure works with SDIO pin.
Code:
#define TFT_DC 44
#define TFT_RST 46
#define TFT_CS 47 // any pin will work not hardware
ILI9488_t3 tft = ILI9488_t3(&SPI2, TFT_CS, TFT_DC, TFT_RST);
So I tried the shorthand version, and it failed as it still defaults to MOSI=11, SCK=13... Which are not valid for SPI2...

So possible fix #1 is when using shorthand constructor, then use default SPI pins for that port...

Also Wondering about adding new constructor like: ILI9488_t3 tft = ILI9488_t3(TFT_CS, TFT_DC, TFT_RST, TFT_MOSI, TFT_SCK, TFT_MISO)

And have it deduce which SPI port if the MOSI/SCK/MISO are all valid for a port than use that port...

Make sense?

For this test will probably just do full constructor with all of the pins... But what fun is that :D
 
@mjs513 - Good morning again...

I thought for quick test to see if SPI2 is defined properly for T4.1 beta at least looks like it outputs something to the memory pins, I started to hack up the continuous update test...
And ran into issues with the ILI9488_t3 constructor (or my laziness). Which I can get around. But wondering what you think if I make the constructors work work more consistent with some of our other libraries.

That is my test, is to first make sure works with SDIO pin.
Code:
#define TFT_DC 44
#define TFT_RST 46
#define TFT_CS 47 // any pin will work not hardware
ILI9488_t3 tft = ILI9488_t3(&SPI2, TFT_CS, TFT_DC, TFT_RST);
So I tried the shorthand version, and it failed as it still defaults to MOSI=11, SCK=13... Which are not valid for SPI2...

So possible fix #1 is when using shorthand constructor, then use default SPI pins for that port...

Also Wondering about adding new constructor like: ILI9488_t3 tft = ILI9488_t3(TFT_CS, TFT_DC, TFT_RST, TFT_MOSI, TFT_SCK, TFT_MISO)

And have it deduce which SPI port if the MOSI/SCK/MISO are all valid for a port than use that port...

Make sense?

For this test will probably just do full constructor with all of the pins... But what fun is that :D

That was one of the things that has been on my to do list but just keep procrastinating to make the changes since we kept doing other updates at the time.

So basically - I agree, it really does make sense what you are saying. Guess I will expect a PR soon :) Think you can actually issue and accept as well :)
 
Yep - But turns out bad test case for this T4.1 as I was using the one using EXTRAM... And this one does not have this.

I also think we need/should figure out best ways to handle cases like this on libraries. That is right now #define option to use external memory or not. But again I can imagine wanting some programs/T4.1s use external ram and others not... Wondering if it needs/should be some compile option or maybe sub-class?
 
Yep - But turns out bad test case for this T4.1 as I was using the one using EXTRAM... And this one does not have this.

I also think we need/should figure out best ways to handle cases like this on libraries. That is right now #define option to use external memory or not. But again I can imagine wanting some programs/T4.1s use external ram and others not... Wondering if it needs/should be some compile option or maybe sub-class?

we could use that trick with #includes that we used for ILI9341_fonts or I use to determine what display I have hooked up:
Code:
…
#elif __has_include(<RA8876_t3.h>)
	#include "Ra8876_Lite.h"
	#include "RA8876_t3.h"
	#define RA8876 1
#else
so if we include the extRam library or whatever we wind up using for a library it would set up to use extmem.
 
Saw a note that ExtRam to be recognized/included in Cores - should be able to disable that on the fly when that is added?

Just looking at CORES - it isn't there yet - but FUNNY - 9 months ago the T_4.0 beta had the Serial4 debug print disabled.
 
Quick update: I have hacked up the Constructors/begin to work a little better/Easier, with two different constructors.
One has the SPI (SPI1, SPI2) as the first argument and the other does not.

I have it tested on on T4.1 and T3.5 for SPI and SPi1. Did not Try SPI2 yet.

Compiles and runs with T3.2 and LC
 
Just took a look and tried it on SPI (since that is what I have that crazy shield of mine configured for. Both constructors work without a problem on a T4.1. Nice you kept the old constructor for compatibility :)
 
Thanks,

I am wondering about how to best support 3 different memory sizes of pixels in frame buffers, 4 if you count none. But T3.5-T3.6 can only support 8 bits per pixel, through a Pallet. T4 can support that as well as 16 bits per pixel, which at display update time (either synchronous or asynchronous) we convert the 16 bits into 18 bits to update the display (output 24 bits per pixel). We now also have an ability for those T4.1s with extended memory chips to be able to use 32 bits per pixel and can do SPI updates without having to convert the data...

Currently you can setup which was by setting #define in header file that set the data type for RAFB. So if you setup one T4.1 with the memory and want to use it, other T4.1s won't work if they don't have the memory...

So am thinking about a few different ways to potentially resolve this.

1) Allow some way to override the define by a sketch specific header file. In theory something like:
Code:
#if __has_include(<optional>)
#  include <optional>
#  define have_optional 1
#elif __has_include(<experimental/optional>)
So far when I have tried it, did not appear to work for me... But may try again.

2) Change all of the code to allow you to set the color size at run time. Sort of like how like how the RA8875 code works. That colors can be either 8 or 16 bits, you can set as part of the begin/setup. It is very doable, but would grow all of the code some and maybe slightly slow it down. But maybe the most functional. That is your T4.1 code could try to get external memory and if that fails, setup to use 16 bit more...

3) Sub-classes - Could make all of the methods that touch the frame buffer to be virtual. Maybe some of the code gets refactored to call off to smaller subset of methods. And then have sub-classes for the different ones that do the work.

4) Template class? - Might make sense, but sort of out of my comfort level. Also if I understand correctly if RAFB is the type that is defined, everything that deals with this must be in same file, i.e header file.


Also with templates, If I am reading correctly you can potentially have some different code setup to be used for different classes passed in?
That is for example the DMA setup code would be very different for the 8/16 bit versus 32 bits.

Again the template code does sounds like it could work pretty well, but not sure I like folding everything into the header file.


So probably pass one. see if the has_include works for this as it is the least painful way.

Thoughts?
 
Hello everybody,

do you see a chance to get the RPI display running with the Teensy 4.0?

https://www.waveshare.com/wiki/4inch_RPi_LCD_(C)

Unfortunately I don't find a suitable 4 inch display.

Thank you!

The simple answer is, I don't know. That is there are several different RPI display boards out there that use different display chips or some really strange ones.
For example I think I have one of the WaveShare 3.2"(SpotPear) which I don't think I ever tried hard enough to get working. The first thing you may need to
do is to try to get a sense of what their display is setup using.

For example could be ILI9488 or ILI9486 (you are here so you probably already tried this driver to see if it does anything) or HX8357 you might try our library for this to see if you get anything
https://github.com/mjs513/HX8357_t3n

Or maybe it is related to the really screwy KeDei RPI display that I wasted way too much time on: https://github.com/KurtE/KeDeiRPI35_t3

But again it could be something completely different.
 
Hi,
I got the delivery today. After a lot of trying it works now.
I use the init commands from https://github.com/996refuse/waveshare4c/blob/master/const.py and had to set the SPI frequency to 19Mhz. With 20Mhz there are errors and it crashes. With 18Mhz it stays white.
Does anyone have any idea why it is so sensitive? I run the ILI9341 with t3n lib with 115Mhz without problems.
I also transferred the init commands to the ILI9341_t3n lib. So far without function. But I will keep trying.
 
Hi,
I got the delivery today. After a lot of trying it works now.
I use the init commands from https://github.com/996refuse/waveshare4c/blob/master/const.py and had to set the SPI frequency to 19Mhz. With 20Mhz there are errors and it crashes. With 18Mhz it stays white.
Does anyone have any idea why it is so sensitive? I run the ILI9341 with t3n lib with 115Mhz without problems.
I also transferred the init commands to the ILI9341_t3n lib. So far without function. But I will keep trying.

If you look at the other file in the link you posted (go up one level - think it was call waveshare4.show???) anyway, the max_spi looks like its only 12.5 MHz? So not sure why the speed limit on the that display as @KurtE said cant really find what display chip its using?
 
@KurtE - Got 2 primary things fixed in the lib but just noticed that the Center-center code hasn't been added. Probably should check Pauls master branch

EDIT: I was wrong we added it but forgot to define CENTER in the sketch and also found drawRect didn't have the centering test in it.
 
Last edited:
@mjs513 - Sounds like you are having some fun... Hopefully will get back to this display soon!

@sepp89117 - As we mentioned no idea, What version of Teensyduino? The latest released code has some SPI update to allow longer time from CS assert to start of signal. Maybe needed?

Maybe issues with some of their init commands in python maybe run slower, where on T4 maybe runs faster... Note: with most of our displays there are delays built in after some of the init strings, as a way to allow display to process previous command... You might want to compare your init to existing and see if you need to build in similar delays. Or sometimes it just is bad contacts with jumper wires that can give you a lot of grief.
 
Back
Top