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

@mjs513 - ST7735 - Maybe upload a copy of your exact one that is still causing USB issues.. I might even put in my actual Adafruit display to try it.

If I find anything obvious will post back to T4 thread. One thing I wondered was if they did anything during constructor, but nothing major, just setting a few variables. Everything is done more in their calls to initr()... Was looking to see if there were any other objects... Did not see anything obvious.

Will play more later
 
@degragster - @KurtE

Yep - got the old screen finally working. New I think I put 5v to one of the other pins by accident and may have fried the chip.

Runs nice but backlight I very bright and washes out the colors with KurtE's new library.
 
@mjs513, @defragster -

Thanks Mike, will try yours out and see if it behaves the same for me. If so again probably should post what is needed for @Paul to take a look at.

I am not sure why I am playing with this KeDei code, other than it is almost close enough to work with.

As I thought the rotations are wrong:

If you look at this image:
IMG_0796-(002).jpg

And you look at the code. The small black square starts at 0,0 and the White square ends at width, height.
Added code to print out the text at X=0, y=height/2 (minus...) and you can see if I rotate the display such as the text is correct orientation, the black is at the top... Should be at bottom, so need to change settings for controlling some of this...

Should probably try it with some of the other display drivers...
Code: 
#include <KeDeiRPI35_t3.h>
#define TFT_CS 10
#define TOUCH_CS 9
KEDEIRPI35_t3 tft = KEDEIRPI35_t3(&SPI, TFT_CS, TOUCH_CS);

float p = 3.1415926;


void setup(void) {
#ifdef TFT_BLK
  pinMode(TFT_BLK, OUTPUT);
  digitalWrite(TFT_BLK, HIGH);
#endif

  Serial.begin(9600);
  Serial.print("hello!");
  tft.begin();
}

uint8_t rotation = 0;
void loop() {
  tft.setRotation(rotation);
  Serial.printf("Set Rotation: %d width: %d height: %d\n", rotation, tft.width(), tft.height());
  elapsedMillis timer;
  uint16_t time = millis();
  tft.fillScreen(KEDEIRPI35_RED);
  tft.fillRect(tft.width() / 2 - 32, 20, 64, tft.height() - 40, KEDEIRPI35_GREEN);
  tft.fillRect(0, 0, 8, 8, KEDEIRPI35_BLACK);
  tft.fillRect(tft.width() - 8, tft.height() - 8, 8, 8, KEDEIRPI35_WHITE);
  tft.drawPixel(0, 0, KEDEIRPI35_YELLOW);
  tft.drawPixel(1, 1, KEDEIRPI35_RED);
  tft.drawPixel(2, 2, KEDEIRPI35_BLUE);
  tft.setCursor(0, tft.height()/2-4);
  tft.printf("R:%d W:%d H:%d", rotation, tft.width(), tft.height());
  tft.drawPixel(tft.width() - 1, tft.height() - 1, KEDEIRPI35_YELLOW);
  tft.drawPixel(tft.width() - 2, tft.height() - 2, KEDEIRPI35_RED);
  tft.drawPixel(tft.width() - 3, tft.height() - 3, KEDEIRPI35_BLUE);
  // large block of text
  //delay(2500);
  Serial.println("Hit any key to continue");
  uint8_t loffset = 0;
  for (;;) {
    while (!Serial.available()) ;
    char ch = Serial.read();
    while (Serial.read() != -1) ;
    if (ch == '.') {
      tft.drawRect(loffset, loffset, tft.width() - 2 * loffset, tft.height() - 2 * loffset, KEDEIRPI35_GREEN);
      loffset++;
    } else break;
  }
  rotation = (rotation + 1) & 0x3;
}
 
@KurtE

Kedei: Think with the Kedei it started off with the challenge of just getting it working now we just cant help ourselves. :)

I downloaded your last GitHub - I hope - but my colors are way off:

20190714_201155 (1).jpg
 
KurtE said:
The good (or bad) news is it crashes my T4 as well... Will debug again tomorrow... But might again probably should put up on T4 thread for Paul to take a look at.
Click to expand...

That seems a good plan with a good repro setup - I was going to wait for clean new CORES - but since it dies for you as well.

I'd like to see it here - Other than current ST7735 and that sketch what is key? Current cores and SPI from PJRC github or other/
 
@defragster

You will need the latest core, Kurt's modified Adafruit_GFX library and latest SPI with the writeRect PR (still open). The uncannyeye sketch is in post #353.

To duplicate load up the sketch on a clean install and then just comment/uncomment the line
Code: 
  //#define LIGHT_PIN_FLIP    // If defined, reverse reading from dial/photocell
In this case uncomment it. You don't even need to have displays attached. To duplicate it though you can't use your debug_tt. If you include it, it some how fixes the problem.
 
Lots of pieces from https://forum.pjrc.com/threads/55735-ILI9488_t3-Support-for-the-ILI9488-on-T3-x-and-beyond?p=210182&viewfull=1#post210182 ::
https://github.com/PaulStoffregen/cores
https://github.com/KurtE/Adafruit-GFX-Library
https://github.com/PaulStoffregen/SPI

Here is the UnCannyEyes as used here - with local copy of HardFault_HandlerC(): View attachment uncannyEyes0a.zip

from post >>uncannyEyes0.Zip

… link to st7735 … https://github.com/KurtE/ST7735_t3/tree/writeRect_reset_delay

Time to gather …
NOT NEEDED :: from post >>debug_tt.zip

NOTE: Once it compiles to upload a failed repro build - to get back to working SerMon USB seems to take a SECOND Button push to get working SerMon back from USB. The SPI LED will blink - but USB stays corrupted until a second Button Push upload.

<edit> debug_tt - not required if this is placed in the sketch - just toggle: #if 0 and 1.
NOTE: It is not because the HardFault_HandlerC() is truncated - the copy in debug_tt is a full copy - and instead of the minimal copy below I did another FULL copy of the current version from CORES and the repro is the same. The problem seems to be in the linking or code placement in memory - even though in these cases the T4 is never faulting - so the code is never called or executed.
Code: 
#if 1  // TOGGLE 0 to exclude and cause BAD USB - set back to 1 and recompile to correct.
#ifdef __cplusplus
extern "C" {
#endif

#if defined(__IMXRT1052__) || defined(__IMXRT1062__)
void HardFault_HandlerC(unsigned int *hardfault_args) {
  digitalWriteFast( 13, HIGH );
  while (1);
}
#endif
#ifdef __cplusplus
} // extern "C"
#endif
#endif

>> Running with BARE T4 on USB cable - white wire T4B2.
OKAY - I get REPRO when this is changed per note above when this line uncommented:
Code: 
T:\tCode\t4\uncannyEyes0\config.h:
  136    #define BLINK_PIN         1 // Pin for manual blink button (BOTH eyes)
  137    #define LIGHT_PIN      A2 // Photocell or potentiometer (else auto iris)
[COLOR="#FF0000"]  138:   //#define LIGHT_PIN_FLIP    // If defined, reverse reading from dial/photocell[/COLOR]

NOTE: it fails, then Button upload when debug_tt active in sketch by uncommenting or recommenting - when the local copy of "HardFault_HandlerC" comes or goes - just the change in config.h causes the code to recompile and that brings the failure back.
Note from @mjs513 above:
To duplicate load up the sketch on a clean install and then just comment/uncomment the line
Code: 
  //#define LIGHT_PIN_FLIP    // If defined, reverse reading from dial/photocell
In this case uncomment it. You don't even need to have displays attached. To duplicate it though you can't use your debug_tt. If you include it, it some how fixes the problem.
Click to expand...

BUT:: IDE SerMon shows Garbage after first upload - it comes online properly with a second Button Upload. It looks like this:
UnCannyE0.png
Then it clears up showing the 64's and is running???

<EDIT UPDATE> I am not getting "REPRO / NO REPRO /REPRO / … " by reverting the code?
@mjs513 - is your note saying any change to 'LIGHT_PIN' ? I did get a hang now with it commented - before it was when uncommented?
It does seem to take 'Clean Build' - once it works it seems to persist? Maybe it is a change from change to '\uncannyEyes0\config.h' ?


Edit: I am seeing two kinds of fail - the obvious one I removed debut_tt and made the config.h change - T4 not running - no SPI LED and this on SerMon:
Code: 
T:\tCode\T4\uncannyEyes0\uncannyEyes0.ino Jul 14 2019 20:57:03
********
 T4 connected Serial_tt ******* debug_tt port

T:\tCode\T4\uncannyEyes0\uncannyEyes0.ino Jul 14 2019 20:57:03InitCreate display #Create display #Reset displaysCall init/begin func for each display

The less obvious case it seemed to start and print normally - and had to observe the LED stayed OFF - with no SPI activity.
 
Last edited:
defragster said:
Lots of pieces from https://forum.pjrc.com/threads/55735-ILI9488_t3-Support-for-the-ILI9488-on-T3-x-and-beyond?p=210182&viewfull=1#post210182 ::
https://github.com/PaulStoffregen/cores
https://github.com/KurtE/Adafruit-GFX-Library
https://github.com/KurtE/SPI
>>uncannyEyes0.Zip

… link to st7735 … https://github.com/KurtE/ST7735_t3/tree/writeRect_reset_delay

Time to gather ...
Click to expand...
Some of these requirements might not be necessary with my versions;
a) SPI - Paul has pulled in my changes
b) GFX - I believe Adafruit has pulled these in. Maybe already released new version with them?
 
Latest repro steps on T4 thread post #3701

@mjs513 - KurtE - if my notes are less than clear please update or expand so Paul can get to see it.

<edit>:
Back when debug_tt was first noted as having an impact it seemed the only thing it added was alternate code resource for the CORES 'weak' FaultHandler - my testing seems to indicate that as adding that locally to the unCannyEyes sketch was the same as including the debug_tt. Both a nearly empty version - or a FULL copy of the PJRC version.

There is something very odd here - but not just for mjs513 this time. Typing this I just thought I should pack up my BUILD dir for working and failing - the issue might be something that shows in the leftover build files. Wil go Add those to that post.

@mjs513 - before this you were seeing other fails and restarts on upload - were they at all similar to this?
 
Last edited:
@mjs513 and @defragster - I think I can officially probably put this KeDei to rest for awhile (maybe forever)
Fixed Touch paint to work with the correct rotation stuff...

touchpaint.jpg

Fixed the touchscreen mapping to screen coordinates, or at least close enough.
Changed to now output 12 colors (480/40), so whole top of screen.
Changed it to be array of colors driven instead of code for each color....
Also an array of color names, which I output when to serial monitor when you click to change colors
And any Serial input in monitor, toggles printing out touch data...
 
defragster said:
Latest repro steps on T4 thread post #3701

@mjs513 - KurtE - if my notes are less than clear please update or expand so Paul can get to see it.

<edit>:
Back when debug_tt was first noted as having an impact it seemed the only thing it added was alternate code resource for the CORES 'weak' FaultHandler - my testing seems to indicate that as adding that locally to the unCannyEyes sketch was the same as including the debug_tt. Both a nearly empty version - or a FULL copy of the PJRC version.

There is something very odd here - but not just for mjs513 this time. Typing this I just thought I should pack up my BUILD dir for working and failing - the issue might be something that shows in the leftover build files. Wil go Add those to that post.

@mjs513 - before this you were seeing other fails and restarts on upload - were they at all similar to this?
Click to expand...

To be honest - I believe so. I should go back to my eigen sketch and rerun it with debug_tt included.

<edit> but I haven't lost usb except for this sketch in a very long time. Eigen threw it into the bootloader and even with debug_tt included still does it.
 
KurtE said:
@mjs513 and @defragster - I think I can officially probably put this KeDei to rest for awhile (maybe forever)
Fixed Touch paint to work with the correct rotation stuff...

….

Fixed the touchscreen mapping to screen coordinates, or at least close enough.
Changed to now output 12 colors (480/40), so whole top of screen.
Changed it to be array of colors driven instead of code for each color....
Also an array of color names, which I output when to serial monitor when you click to change colors
And any Serial input in monitor, toggles printing out touch data...
Click to expand...

Just tried it and it does work - my colors are just off compared to what you have = but that may be my display.
 
@mjs513 ...

I lied a little.

I now have it so it builds and crawls on Teensy LC... it uses SPI.transfer and SPI.transfer16 to do the work. Might be able to more on it, but it aint worth it!

I just unplugged T4 from my partially assembled board and plugged in TLC
 
mjs513 said:
avoiding flickering and tearing
Click to expand...
Blog:
This can be achieved by rendering subsequent frames on top of previous frames without erasing, and then erasing only those pixels that have changed.
Click to expand...
That's exactly what I say (since many years.. :) ) - it looks a bit more "dynamic" if do it the other way: first delete the pixels that changed to "black", then overwrite all others. But best is, to do double-buffering, if possible.
(..and NEVER..NEVER, write pixels twice.. i.e. delete without thinking and redraw - this WILL flicker if there is a refresh in between - but OK, everybody knows that)
 
Last edited:
@Frank B - haven't done 3d graphics since my college days and that was on Apollo computers, IBM360 and PDP11's and of course TRS80 - yes I am old :) So with the T4 going to have some fun. Found a very simple Ray Tracing example with the usual test case of sphere's that runs pretty much out of the box and takes about a sec to run using a ILI9341 using @KurtE ILI9341_t3n library:
20190715_165624.jpg

<EDIT> The same sketch on a T3.6 takes 34s to complete just to give you an idea. For anyone that is interested here is the sketch:
View attachment TFT22_raytrace.zip
 
Last edited:
Got github KeDei - touchpaint example just has debug feedback - scaling seems about right

But don't see the color box paint area like p#367 to test compare the color block?

Screen is just WHITE ?
 
@defragster - Might help to see your setup (post, or email). Are you using breakout board? If so how to get +5v to it... I was using my own breakout.
Also does yours say anything like Version 6.3...
 
You must log in or register to reply here.
Back
Top