Teensy 4.0 First Beta Test

Status
Not open for further replies.
@KurtE
Just loaded it and ran graphicstest. Looking good.

Did you happen to notice that when it first starts the "waiting...." text is a mirror of what it is suppose to be.... and the first deadbeef is the same. By the time it gets to the last text rotation its fine?

Think I had that on mine as well
 
@KurtE and others

Running all day without an issue with the T4 and now hanging again. Here is debug info that @defragster put in and my added prints to put it in plain English:
Code:
Fault irq 3
 stacked_r0 ::  00020003
 stacked_r1 ::  00000077
 stacked_r2 ::  00000000
 stacked_r3 ::  00000000
 stacked_r12 ::  01200007
 stacked_lr ::  000099FB
 stacked_pc ::  4018C000
 stacked_psr ::  60000000
[COLOR="#FF0000"] _CFSR ::  00000001
      (IACCVIOL) Instruction Access Violation[/COLOR]
 _HFSR ::  40000000
 _DFSR ::  00000000
 _AFSR ::  00000000
 _BFAR ::  00000000
 _MMAR ::  00000000
need to switch to alternate clock during reconfigure of ARM PLL
USB PLL is running, so we can use 120 MHz
Freq: 12 MHz * 75 / 3 / 1
ARM PLL=80002064
ARM PLL needs reconfigure
ARM PLL=8000204B
New Frequency: ARM=300000000, IPG=150000000
Decreasing voltage to 1150 mV
 
Wow, so much impressive display stuff happening! Oh how I'd love to be doing this stuff....

Just yesterday I finally got the test fixture to be able to initialize fuses on a completely new board. Today I got the test able to manipulate the QSPI flash chip. So all the pieces are falling into place, just not as fast as I wanted. A lot of the other tester stuff is pretty similar to Teensy 3.6, so I'm feeling optimistic now that these iMXRT specific tester things are working.

I'm debating whether to send ~6 of the new 1062 boards without much testing, versus wait a few more days until I get the tester farther along - probably early next week. The first 1052 boards (before the breakout board for audio, serial, and USB host) were sent with little testing other than being able to program the LED blink. But now we're getting pretty close to the final product. Would be really good if everyone uses boards that've been through a testing process very similar to what we'll use for production, rather than the very ad-hoc & kludgey way I did things with the 1052 boards. Then again, I *really* want to get some of these 1062 boards out to everyone who's been highly active in beta testing!

I did a quick round of testing with 1062. Looks like I2S output and SD over SPI are broken on 1062. Haven't looked into why. PWM, I2C, analogRead and lots of other stuff works fine. Way too much hardware & manufacturing stuff has taken all by time lately, so I've had pretty much no time for the software side these last couple weeks.

I see some comments to me recently about display product ideas. Please understand I can't participate in much conversation right now. I'm trying to check the forum a couple times each day and answer user support questions, but lately that's been the extent of my forum time recently. I probably have a couple more weeks like this, not being able to participate much here, before I can return to focusing on the software side.
 
Wow, so much impressive display stuff happening! Oh how I'd love to be doing this stuff....

Just yesterday I finally got the test fixture to be able to initialize fuses on a completely new board. Today I got the test able to manipulate the QSPI flash chip. So all the pieces are falling into place, just not as fast as I wanted. A lot of the other tester stuff is pretty similar to Teensy 3.6, so I'm feeling optimistic now that these iMXRT specific tester things are working.

I'm debating whether to send ~6 of the new 1062 boards without much testing, versus wait a few more days until I get the tester farther along - probably early next week. The first 1052 boards (before the breakout board for audio, serial, and USB host) were sent with little testing other than being able to program the LED blink. But now we're getting pretty close to the final product. Would be really good if everyone uses boards that've been through a testing process very similar to what we'll use for production, rather than the very ad-hoc & kludgey way I did things with the 1052 boards. Then again, I *really* want to get some of these 1062 boards out to everyone who's been highly active in beta testing!

I did a quick round of testing with 1062. Looks like I2S output and SD over SPI are broken on 1062. Haven't looked into why. PWM, I2C, analogRead and lots of other stuff works fine. Way too much hardware & manufacturing stuff has taken all by time lately, so I've had pretty much no time for the software side these last couple weeks.

I see some comments to me recently about display product ideas. Please understand I can't participate in much conversation right now. I'm trying to check the forum a couple times each day and answer user support questions, but lately that's been the extent of my forum time recently. I probably have a couple more weeks like this, not being able to participate much here, before I can return to focusing on the software side.

Good news on progress and lack of any stoppers! And sounds like you've done some testing and have 1062 buildable!

Some US addresses would ship cheap and fast for some - perhaps broader - smoke testing - and return more easily if it came to it needing hardware edits/testing.

Your focus on hardware is understood and pleasing … especially given … "we're getting pretty close to the final product"
 
@Paul - Sounds like you are making good progress! As for when to ship a few boards, Probably when you are ready... If you think a few more days would help to maybe avoid having to replace or update boards later, then probably a good thing to wait. However if you think having a few others help beat up some stuff quickly then...

@mjs513 and others.

I hacked up your version of the library a little more to try out 24 bit writes of the color:
Code:
void ILI9488_t3::write16BitColor(uint16_t color, bool last_pixel){
  // #if (__STM32F1__)
  //     uint8_t buff[4] = {
  //       (((color & 0xF800) >> 11)* 255) / 31,
  //       (((color & 0x07E0) >> 5) * 255) / 63,
  //       ((color & 0x001F)* 255) / 31
  //     };
  //     SPI.dmaSend(buff, 3);
  // #else
  uint8_t r = (color & 0xF800) >> 11;
  uint8_t g = (color & 0x07E0) >> 5;
  uint8_t b = color & 0x001F;

  r = (r * 255) / 31;
  g = (g * 255) / 63;
  b = (b * 255) / 31;
#if defined(__IMXRT1052__) || defined(__IMXRT1062__)  // Teensy 4.x
  uint32_t color24 = ((uint32_t)r << 16) | ((uint32_t)g << 8) | b;
  if (last_pixel)  {
	maybeUpdateTCR(LPSPI_TCR_PCS(1) | LPSPI_TCR_FRAMESZ(23));
	IMXRT_LPSPI4_S.TDR = color24;
	_pending_rx_count++;	//
	waitTransmitComplete();
  } else {
	maybeUpdateTCR(LPSPI_TCR_PCS(1) | LPSPI_TCR_FRAMESZ(23) | LPSPI_TCR_CONT);
	IMXRT_LPSPI4_S.TDR = color24;
	_pending_rx_count++;	//
	waitFifoNotFull();
  }

#else
  writedata8_cont(r);
  writedata8_cont(g);
  if (last_pixel)  {
  	writedata8_last(b);
  } else {
  	writedata8_cont(b);
  }
#endif
  // #endif
}
I think it is working and speed: Still have DC=10...
Code:
ILI9488 Test!
Display Power Mode: 0x9C
MADCTL Mode: 0x88
Pixel Format: 0x6
Image Format: 0x0
Self Diagnostic: 0x0
Benchmark                Time (microseconds)
Screen fill              735102
Text                     13738
Lines                    138069
Horiz/Vert Lines         59464
Rectangles (outline)     22223
Rectangles (filled)      1777590
Circles (filled)         207040
Circles (outline)        137729
Triangles (outline)      31126
Triangles (filled)       534966
Rounded rects (outline)  62118
Rounded rects (filled)   1925069
Done!
 
Using the updated ili9341_t3 [KurtE/ILI9341_t3/tree/T4_Beta ] I have a running (edited) BuhdaBrot and DemoSauce on T_3.6 (FrankB Teensy64) and T4 Beta

To get T4 to run I had to move back to Breadboard wiring :( - something seems wrong with my T4_Beta_Breakout even with direct wiring - maybe it is me … though each time I go back to breadboard it works?

DemoSauce
T4 [BOLD] then T_3.6@256MHz [ul]:
Code:
TwistyText
Frame count (more is better):  [B]1118[/B]  then [U]984[/U]
---
PlasmaCloud  [20 secs]
Frame count (more is better):  [B]681  [/B](34.05 FPS)  then [U]731  (36.55 FPS)[/U]
---
Waveform  [20 secs]
Frame count (more is better):  [B]99698  [/B](4984.90 FPS)  then [U]96883  (4844.15 FPS)[/U] [ T_3.6 WaveForm is a solid yellow screen :( ]
---
MagentaSquares  [20 secs]
Frame count (more is better):  [B]1332  [/B](66.60 FPS)  then [U]1415  (70.75 FPS)[/U]
---
Sphere3D  [20 secs]
Frame count (more is better):  [B]744  [/B](37.20 FPS)  then [U]864  (43.20 FPS)[/U]
---
Checkerboard  [20 secs]
Frame count (more is better):  [B]389  [/B](19.45 FPS)  then [U]325  (16.25 FPS)[/U]
---
Leaves  [20 secs]
Frame count (more is better):  1145  (57.25 FPS)  then [U]1257  (62.85 FPS)[/U] [Leaves all white on T_3.6?]
---
Cube3D  [20 secs]
Frame count (more is better):  871  (43.55 FPS)  then [U]1167  (58.35 FPS)[/U] [T4 jerky and T_3.6 is smooth]
---
PlasmaYellow  [20 secs]
Frame count (more is better):  1357  (67.85 FPS)  then [U]1457  (72.85 FPS)[/U]
---
TriangleWeb  [20 secs]
Frame count (more is better):  1709  (85.45 FPS)  then [U]1767  (88.35 FPS)[/U]

Some test transition wipes on T4 looked odd.
 
Last edited:
I agree with Tim - it's better to ship the new boards to US addresses.

I've decided to make a display board with some chips on it in the hope I can use a fast 8 or 16 bit interface with a few pins - had some ideas.. just need to find out if the needed logic chips exist :)
 
FastLED testing

I don't pretend to understand most of FastLED lib, but I did hack enough to successfully test neopixel and DOTSTAR strips on Teensy 4 beta. See
https://github.com/manitou48/FastLED
The branch is a starting point for further T4 refinement and optimization. I did not incorporate F_CPU_ACTUAL, so you need to update boards.txt to teensy4b.build.fcpu=600000000 so that F_CPU reflects actual T4 CPU clock.

TODO:
  • incorporate F_CPU_ACTUAL
  • SPI clock is 6.25MHz, and the template doesn't seem to allow me to change SPI CLK speed ?
  • need FASTLED_TEENSY4 conditional?
  • M7 DSP support in lib8tion.h
  • other teensy3 optimizations? fastspi, clockless_block
  • more testing, more mods?

Note: Paul has already updated the Teensyduino Adafruit_NeoPixel lib to support T4.

EDIT: 5/9/19 add T4B2 (1062) pin defs in fastpin_arm_t4.h using fast GPIO (GPIO6-9). Tested with scope and with NEOPIXEL and DOTSTAR (SPI running at 22 mhz) strips. F_CPU 600mhz in boards.txt, 1.8.9 with 1.47-beta2

EDIT: 8/13/19 official T4 support for FastLED in 1.47-beta7, see
https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=212184&viewfull=1#post212184
 
Last edited:
@Paul - Sounds like you are making good progress! As for when to ship a few boards, Probably when you are ready... If you think a few more days would help to maybe avoid having to replace or update boards later, then probably a good thing to wait. However if you think having a few others help beat up some stuff quickly then...

@mjs513 and others.

I hacked up your version of the library a little more to try out 24 bit writes of the color:
,,,,,,,
I think it is working and speed: Still have DC=10...
…….

@Paul, I agree with what @KurtE said. The end state is in site so don't get too sidetracked :)

@KurtE. Just tried your changes and seems to work. Think I am going to add in scrolling and text positioning stuff as well. Maybe its time to put this on a GitHub page?

@defragster. That's strange about the Breadboard but at least it works on the breadboard. Glad you got it working though. Demosauce seems to give the display a nice workout :)
 
@KurtE, @defragster and others. Heres a modified version of budhabrot on the ILI9488, interesting I got up to 320x320 image with the _t3 version.
Code:
// Buddhabrot
// j.tarbell   January, 2004
// Albuquerque, New Mexico
// complexification.net
//  http://www.complexification.net/gallery/machines/buddhabrot/appletl/index.html
// based on code by Paul Bourke
// astronomy.swin.edu.au/~pbourke/
// j.tarbell   April, 2005
//
/*
WRITE BMP TO SD CARD
Jeff Thompson
Summer 2012
Writes pixel data to an SD card, saved as a BMP file.  Lots of code
via the following...
BMP header and pixel format:
   http://stackoverflow.com/a/2654860
SD save:
   http://arduino.cc/forum/index.php?topic=112733 (lots of thanks!)
... and the SdFat example files too
www.jeffreythompson.org
*/
// Modified to run on Teensy
// MJS     March, 2019

#include <ILI9488_t3.h> // Hardware-specific library
#include <SD.h>
#include <SPI.h>
#include <font_Arial.h>

#define ILI9488_RST 23 //23 for t4
#define ILI9488_DC 9
#define ILI9488_CS 10
ILI9488_t3 tft = ILI9488_t3(ILI9488_CS, ILI9488_DC, ILI9488_RST);


const int dim = 320;             // screen dimensions (square window)
int bailout = 200;         // number of iterations before bail
int plots = 10000;        // number of plots to execute per frame (x30 = plots per second)

// 2D array to hold exposure values
byte exposure[dim*dim];
int maxexposure;           // maximum exposure value
int time = 0;
int exposures = 0;

boolean drawing;

//bmp save
char name[] = "9px_0000.bmp";       // filename convention (will auto-increment)
const int w = dim;                   // image width in pixels
const int h = dim;                    // " height
const boolean debugPrint = true;    // print details of process over serial?

const int imgSize = w*h;
// set fileSize (used in bmp header)
int rowSize = 4 * ((3*w + 3)/4);      // how many bytes in the row (used to create padding)
int fileSize = 54 + h*rowSize;        // headers (54 bytes) + pixel data

unsigned char *img = NULL;

File file;
const int cardPin = 18;          // pin that the SD is connected to (d8 for SparkFun MicroSD shield)

void setup() {
  Serial.begin(115200);
  tft.begin();
  tft.setRotation(3);
  //tft.setFont(Arial_9);
  tft.fillScreen(ILI9488_BLACK);
  //tft.setTextColor(ILI9488_WHITE, ILI9488_BLACK);
  //tft.setTextDatum(TL_DATUM);

  if ( ARM_DWT_CYCCNT == ARM_DWT_CYCCNT ) {
    ARM_DEMCR |= ARM_DEMCR_TRCENA; // T_3.x only needs this
    ARM_DWT_CTRL |= ARM_DWT_CTRL_CYCCNTENA;
    Serial.println("CycleCnt Started.");
  }
  
  // SD setup
  Serial.begin(9600);
  Serial.print("Initializing SD card...");
  if (!SD.begin(cardPin)) {
    Serial.println("initialization failed!");
    return;
  }
  Serial.println("initialization done.");

}

uint32_t CCdiff;
void loop() {
  plotPlots();
  static int Dexposures = 0;
  time++;
  if (time % 30 == 0) {
    // show progress every 2 seconds or so...
    CCdiff = ARM_DWT_CYCCNT;
    findMaxExposure();
    CCdiff = ARM_DWT_CYCCNT - CCdiff;
    renderBrot();
    //saveBMP();
    // show exposure value
    // show exposure value
    //tft.drawString("bailout:  ", 0, 0);
    //tft.drawNumber(bailout, 0, 25);
    //tft.drawString("exposures: ", 0, 40);
    //tft.drawNumber(exposures, 0, 60);
    //tft.drawNumber(exposures - Dexposures, 0, 80);
    //tft.drawString("Cycles: ", 0, 100);
    //tft.drawNumber(CCdiff, 0, 120);
    Dexposures = exposures;
  }

  if ( exposures > 10000000 ) {
    exposures = 0;
    memset(exposure, 0, sizeof( exposure ));
  }
}

void plotPlots() {
  float x, y;
  // iterate through some plots
  for (int n=0;n<plots;n++) {
    // Choose a random point in same range
    x = randomFloat(-2.0,1.0);
    y = randomFloat(-1.5,1.5);
    if (iterate(x,y,false)) {
      iterate(x,y,true);
      exposures++;
    }
  }
}


//   Iterate the Mandelbrot and return TRUE if the point exits
//   Also handle the drawing of the exit points
boolean iterate(float x0, float y0, boolean drawIt) {
  float x = 0;
  float y = 0;
  float xnew, ynew;
  int ix,iy;

  for (int i=0;i<bailout;i++) {
    xnew = x * x - y * y + x0;
    ynew = 2 * x * y + y0;
    if (drawIt && (i > 3)) {
      ix = int(dim * (xnew + 2.0) / 3.0);
      iy = int(dim * (ynew + 1.5) / 3.0);
      if (ix >= 0 && iy >= 0 && ix < dim && iy < dim) {
        // rotate and expose point
        exposure[ix*dim+iy]++;
      }
    }
    if ((xnew*xnew + ynew*ynew) > 4) {
      // escapes
      return true;
    }
    x = xnew;
    y = ynew;
  }
  // does not escape
  return false;
}

void findMaxExposure() {
  // assume no exposure
  maxexposure=0;
  // find the largest density value
  for (int i=0;i<dim;i++) {
    for (int j=0;j<dim;j++) {
      maxexposure = max(maxexposure,exposure[i*dim+j]);
    }
  }
}


void renderBrot() {
  // draw to screen
  for (int i=0;i<dim;i++) {
    for (int j=0;j<dim;j++) {
      float ramp = exposure[i*dim+j] / (maxexposure / 2.5);
      
      // blow out ultra bright regions
      if (ramp > 3)  {
        ramp = 1;
      }
      uint16_t color = tft.color565(int(ramp*128), int(ramp*128), int(ramp*255));
      tft.drawPixel(j+80, i, color);

      //color c = color(int(ramp*255), int(ramp*255), int(ramp*255));
      //set(j,i,c);
    }
  }
}

double randomFloat(float minf, float maxf)
{
  return minf + random(1UL << 31) * (maxf - minf) / (1UL << 31);  // use 1ULL<<63 for max double values)
}

void saveBMP(){
  // if name exists, create new filename
  for (int i=0; i<10000; i++) {
    name[4] = (i/1000)%10 + '0';    // thousands place
    name[5] = (i/100)%10 + '0';     // hundreds
    name[6] = (i/10)%10 + '0';      // tens
    name[7] = i%10 + '0';           // ones
    file = SD.open(name, O_CREAT | O_EXCL | O_WRITE);
    if (file) {
      break;
    }
  }

  // set fileSize (used in bmp header)
  int rowSize = 4 * ((3*w + 3)/4);      // how many bytes in the row (used to create padding)
  int fileSize = 54 + h*rowSize;        // headers (54 bytes) + pixel data

  img = (unsigned char *)malloc(3*w*h);
  
  for (int i=0;i<dim;i++) {
    for (int j=0;j<dim;j++) {
      float ramp = exposure[i*dim+j] / (maxexposure / 2.5);
      
      // blow out ultra bright regions
      if (ramp > 3)  {
        ramp = 1;
      }
      //uint16_t color = tft.color565(int(ramp*128), int(ramp*128), int(ramp*255));
      //tft.drawPixel(j+80, i, color);
      img[(j*w + i)*3+0] = (unsigned char)(int(ramp*255));    // B
      img[(j*w + i)*3+1] = (unsigned char)(int(ramp*128));    // G
      img[(j*w + i)*3+2] = (unsigned char)(int(ramp*128));    // R
      
      // padding (the 4th byte) will be added later as needed...
      //color c = color(int(ramp*255), int(ramp*255), int(ramp*255));
      //set(j,i,c);
    }
  }

  // create padding (based on the number of pixels in a row
  unsigned char bmpPad[rowSize - 3*w];
  for (int i=0; i<sizeof(bmpPad); i++) {         // fill with 0s
    bmpPad[i] = 0;
  }

  // create file headers (also taken from StackOverflow example)
  unsigned char bmpFileHeader[14] = {            // file header (always starts with BM!)
    'B','M', 0,0,0,0, 0,0, 0,0, 54,0,0,0   };
  unsigned char bmpInfoHeader[40] = {            // info about the file (size, etc)
    40,0,0,0, 0,0,0,0, 0,0,0,0, 1,0, 24,0   };

  bmpFileHeader[ 2] = (unsigned char)(fileSize      );
  bmpFileHeader[ 3] = (unsigned char)(fileSize >>  8);
  bmpFileHeader[ 4] = (unsigned char)(fileSize >> 16);
  bmpFileHeader[ 5] = (unsigned char)(fileSize >> 24);

  bmpInfoHeader[ 4] = (unsigned char)(       dim      );
  bmpInfoHeader[ 5] = (unsigned char)(       dim >>  8);
  bmpInfoHeader[ 6] = (unsigned char)(       dim >> 16);
  bmpInfoHeader[ 7] = (unsigned char)(       w >> 24);
  bmpInfoHeader[ 8] = (unsigned char)(       h      );
  bmpInfoHeader[ 9] = (unsigned char)(       h >>  8);
  bmpInfoHeader[10] = (unsigned char)(       h >> 16);
  bmpInfoHeader[11] = (unsigned char)(       h >> 24);

  // write the file (thanks forum!)
  file.write(bmpFileHeader, sizeof(bmpFileHeader));    // write file header
  file.write(bmpInfoHeader, sizeof(bmpInfoHeader));    // " info header

  for (int i=0; i<h; i++) {                            // iterate image array
    file.write(img+(w*(h-i-1)*3), 3*w);                // write px data
    file.write(bmpPad, (4-(w*3)%4)%4);                 // and padding as needed
  }
  free(img);
  file.close();                                        // close file when done writing
}
 
... found a more Interesting solution for my displayproblem: A SPI-RAM with inbuilt PAL/NTSC encoder :) Ordered chips+ 11 EUR Display and will make that board for all Teensys 3.x first :)
 
@KurtE. Just tried your changes and seems to work. Think I am going to add in scrolling and text positioning stuff as well. Maybe its time to put this on a GitHub page?
Good Morning all :D -

Yes could be good time to add to github... Or the question is, should we adopt it to the _t3n version? (maybe Minus Spin)... But would add some additional features like:
a) Frame buffer on T4 (hopefully)
b) The other graphic primitives that were added (plus clipping and the like), including your latest additions....
c) Opaque font text...
d) And hopefully still support for different SPI objects. (Have not tried current one yet on T3.x...), and when we get a T4(b2 or released), we can try SPI1 and maybe SPI2. This is where SPIN came in, but most of this has migrated into SPI library, except for some of the support functions (mostly that came from ili9341_t3 library). Things like wait until queue not full, ... The place where this came in handy is the SPIN tables included some information for this, like how big the FIFO queues are, which these functions referenced... I believe that these areas of my SPIN tables were also migrated into the SPI objects table, but I don't think we exported any methods to retrieve that value... But could hack it...

...
 
Good Morning all :D -

Yes could be good time to add to github... Or the question is, should we adopt it to the _t3n version? (maybe Minus Spin)... But would add some additional features like:
a) Frame buffer on T4 (hopefully)
b) The other graphic primitives that were added (plus clipping and the like), including your latest additions....
c) Opaque font text...
d) And hopefully still support for different SPI objects. (Have not tried current one yet on T3.x...), and when we get a T4(b2 or released), we can try SPI1 and maybe SPI2. This is where SPIN came in, but most of this has migrated into SPI library, except for some of the support functions (mostly that came from ili9341_t3 library). Things like wait until queue not full, ... The place where this came in handy is the SPIN tables included some information for this, like how big the FIFO queues are, which these functions referenced... I believe that these areas of my SPIN tables were also migrated into the SPI objects table, but I don't think we exported any methods to retrieve that value... But could hack it...

...

@KurtE

It would be nice to get it incorporated into _t3n. Would provide additional capabilities to the user. Maybe create a branch for now. You planning on supporting both displays in one library? No rush was just a thought.

So lets switch over to _t3n?
 
@wmxz, the sd socket on the audioshield for example.
the code uses the spi-lib only - no own spi code

If it is a SW issue, it can be handled, but I got (it seems wrongly) the impression 'broken' means hardware and not 'needs work'. Anyhow, looking forward to 1062
 
@KurtE

It would be nice to get it incorporated into _t3n. Would provide additional capabilities to the user. Maybe create a branch for now. You planning on supporting both displays in one library? No rush was just a thought.

So lets switch over to _t3n?
A couple of options here...

We keep your library independent... And simple merge in all of the other code... Should not be overly hard to do with tools like WinMerge or sublime-merge...
The plus of this approach is that you don't need to pay penalties for checking things like sizes and the like in loops.

Example if you wish to fill the screen you can simply do it now by iterating to a constant ILI9341_TFTWIDTH*ILI9341_TFTHEIGHT ... but with doing both you would need to do _width*_height (But this overhead would be minuscule ) A little more overhead would be to writing out the 16 bit colors. Currently for ili9341_t3(n) these are all done inline going directly to hardware... With a combined version would need to test which display we are using and do different outputs depending...

Or Could do a lot heavier edit and move most of my code into some base class and then have subclasses for each of the displays... i.e. like Adafruit_gfx, which we got away from...

I could go either way. For the fun of it, I might try a quick and dirty merge and see how bad it would be?

As a possibility, you could maybe create the github project... And if you like how the merge turns out, could do a PR to take it in?
 
@KurtE

Maybe keep the library independent for now and do the merging incrementally. For instance - add the stuff I added to _t3n first (that's simple) and then maybe do the merge for framebuffer (if that is what you are talking about?). I always ran into problems when doing a mass merge - yes I know incremental merges are a pain as well.

..For the fun of it, I might try a quick and dirty merge and see how bad it would be?
You are as bad as me, hehehe :)
 
@mjs513 (and others)

Here is a Zip file before merge. Same as previous one, except has the updated output color functions and I also updated keywords.txt to change ILI9341 to ILI9488...
 

Attachments

  • ILI9488_t3.zip
    902.2 KB · Views: 92
@KurtE
Thanks for the common baseline. If there is anything you want me to do - have a feeling anything I do will be duplicating your merge?
 
@mjs513 - right now I am sort of distracted from this distraction ;) So I would say if there are pieces you want in quickly... Go for it!

Right now playing around with OpenCM trying to figure out how to properly use half duplex in their Serial objects...

Their hardware supports it, but their documentation is a bit lacking... But that is really off topic...
 
@KurtE : ili9341_t3 All Good:: - about 12 hours runtime with p#2181 ver of ili9341_t3 DemoSauce on both T_3.6 and T4 ! Still cycling on both devices - same behavior as noted - no new anomalies.

Just pulled the p#2195's ili9488 zip - will see about moving them both over to that and running some examples.

@mjs513 - I've not seen any faults on T4 - so I have not done anything with Fault Reg dumping. You are able to use Breakout w/USB&TFT - is that in use with fault? - I've given up on breakout. Still thinking I roasted something under Breakout when I got the T4 hot and bothered some posts back.
 
@KurtE : ili9341_t3 All Good:: - about 12 hours runtime with p#2181 ver of ili9341_t3 DemoSauce on both T_3.6 and T4 ! Still cycling on both devices - same behavior as noted - no new anomalies.

Just pulled the p#2195's ili9488 zip - will see about moving them both over to that and running some examples.

@mjs513 - I've not seen any faults on T4 - so I have not done anything with Fault Reg dumping. You are able to use Breakout w/USB&TFT - is that in use with fault? - I've given up on breakout. Still thinking I roasted something under Breakout when I got the T4 hot and bothered some posts back.

@defragster - just a warning - I haven't been able to get ILI9488_t3 running on the FB_Teensy64. Same behavior with the original version of the ili9488 lib that we started with.

The faults have been happening with something plugged into the USBhost or the tft connected. The last fault was with just the ILI9488. Once I did a hard reset it cleared itself and was able run sketches again.
 
@mjs513 - right now I am sort of distracted from this distraction ;) So I would say if there are pieces you want in quickly... Go for it!

Right now playing around with OpenCM trying to figure out how to properly use half duplex in their Serial objects...

Their hardware supports it, but their documentation is a bit lacking... But that is really off topic...

Not a problem @KurtE, I just picked up some lewan serial servos - on my todo list - but if I start on that I'll never get back to this - besides - no room on my desk for both projects :)
 
Status
Not open for further replies.
Back
Top