Teensy 4.0 First Beta Test

Status
Not open for further replies.
Did a quick shifting of the back side to suggest. Red Boxes were just to make them stand out for grouping as an addition - black would be right perhaps - with a single arrow to the general area {only 2 of 3 shown}.

t4_BackRev.png

Also shifted the USB Host and SDIO for locality of reference - need to make sure the USB Host D- / D+ are understood as not device USB pins like prior Teensy models.

As noted before the Front of the T4 card might benefit from having 'Teensy 4.0 pins are 3.3V only' - where the note about interrupt capability is shown
 
Last edited:
USBHost - USB Device

Q. can the USB Host pads (D+ D-) that are at location of Old USB Device pad also be used vor USB device mode?
Can a T4 have two USB device ports (one for programming and standard USB activity and one dedicated for own application)?
 


Which signals are on the round testpads between 24-33?

Here's info on all the other test points....

...
Maybe that's more than anyone might ever want to know about the test procedure, but hopefully it shines some light on why there are so many test points. This iMXRT chip has several power supply voltages. All need to be checked, and the tester needs to be able to fully discharge every capacitor so each individual power up test begins with the T4 fully off.

...

Very cool insight - nice share … how long does a test cycle take?

That is followed by the usual PJRC 'plug in USB cable' Blink test? When is the Blink sketch loaded? Is a button press done at that point to visually see the 'Bootloader Red' LED function before unplugging?
 
Adafruit_gfx, adafruit_ili9341, adafruit_st7735 and st7735_t3

None of these compile on T4...

I did some changes to Adafruit_gfx - https://github.com/KurtE/Adafruit-GFX-Library/tree/T4_Beta

That I was able to build and run graphicstest example app on T4 using PJRC ILI9341 display using pins (CS=10, DC=9, reset=23)

I also was able to get graphicstest example to work on ST7735 SPI display with adafruit_st7735... library.

Still working on ST7735_t3 as more 32 bit registers... And likewise SPI data different...

Anyway if anyone wises to try it out before I try issuing a PR to Adafruit that would be great.

Hi Kurt
Just gave your changes a try with the T4. Ran graphicstest as you did and worked no problem. Ran a version, for just drawpixels using my budhabrot example and it ran as well no problems.
 
Adafruit_gfx, adafruit_ili9341, adafruit_st7735 and st7735_t3

None of these compile on T4...

I did some changes to Adafruit_gfx - https://github.com/KurtE/Adafruit-GFX-Library/tree/T4_Beta

That I was able to build and run graphicstest example app on T4 using PJRC ILI9341 display using pins (CS=10, DC=9, reset=23)

I also was able to get graphicstest example to work on ST7735 SPI display with adafruit_st7735... library.

Still working on ST7735_t3 as more 32 bit registers... And likewise SPI data different...

Anyway if anyone wises to try it out before I try issuing a PR to Adafruit that would be great.

@KurtE - It works on ili9341.

I had to grab :: github.com/adafruit/Adafruit_ILI9341

Using the mock_ili9341 example in the GFX lib it is running with T4 on the PJRC Purple OSH test board.

Only verbose console warning is:
In file included from T:\tCode\libraries\Adafruit_GFX\Adafruit_GFX.cpp:35:0:

T:\tCode\libraries\Adafruit_GFX\glcdfont.c:13:0: warning: "PROGMEM" redefined
#define PROGMEM
^

In file included from T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4/WProgram.h:41:0,
from T:\TEMP\arduino_build_882294/pch/Arduino.h:6,
from T:\tCode\libraries\Adafruit_GFX\Adafruit_GFX.h:5,
from T:\tCode\libraries\Adafruit_GFX\Adafruit_GFX.cpp:34:

T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4/avr/pgmspace.h:28:0: note: this is the location of the previous definition
#define PROGMEM __attribute__((section(".progmem")))
^

And libs used:
Multiple libraries were found for "Adafruit_GFX.h"
Used: T:\tCode\libraries\Adafruit_GFX
Not used: T:\Ard186t4b2\hardware\teensy\avr\libraries\Adafruit_GFX
Using library SPI at version 1.0 in folder: T:\Ard186t4b2\hardware\teensy\avr\libraries\SPI
Using library Adafruit_GFX at version 1.5.5 in folder: T:\tCode\libraries\Adafruit_GFX
Using library Adafruit_ILI9341 at version 1.5.0 in folder: T:\tCode\libraries\Adafruit_ILI9341
"T:\\Ard186t4b2\\hardware\\teensy/../tools/arm/bin/arm-none-eabi-size" -A "T:\\TEMP\\arduino_build_296803/mock_ili9341.ino.elf"
Sketch uses 32448 bytes (1%) of program storage space. Maximum is 2031616 bytes.
Global variables use 37632 bytes (3%) of dynamic memory, leaving 1010944 bytes for local variables. Maximum is 1048576 bytes.

Also the Adafruit Touchpaint : T:\tCode\libraries\Adafruit_ILI9341\examples\touchpaint
Works with a quick hack of to replace this - though touch map is rotated 90 degrees when tested - the display works:
//#include <Adafruit_STMPE610.h>
#include <XPT2046_Touchscreen.h>
 
Did a quick shifting of the back side to suggest.

The red boxes are a really interesting idea. But the card really needs to go into printing, at least for the first batch... so I'm really not looking to make much change to the formatting right now. At this point I'm mainly looking to verify the info.

Another rev of the card definitely will be made shortly after the T4 release, since the first batch will be using photos of a beta board.


Q. can the USB Host pads (D+ D-) that are at location of Old USB Device pad also be used vor USB device mode?
Can a T4 have two USB device ports (one for programming and standard USB activity and one dedicated for own application)?

Good question. I have not tried this, so I really can't say for sure. One of the chip errata is about power management when both ports are in device mode. That may or may not be an issue, because we're not breaking out the 2 power pins separately.

Other that the errata, everything in the reference manual seems to say this should be possible. If you or anyone else really wanted to try, my understanding is it should mostly be a matter of making a copy of usb.c & usb_serial.c and just change all the register names for the other USB controller and USB PHY.



Very cool insight - nice share … how long does a test cycle take?

About 650 ms, plus a 75 ms "debounce" time from the moment the board is electrically seen on the shorter pogo pins.


That is followed by the usual PJRC 'plug in USB cable' Blink test? When is the Blink sketch loaded? Is a button press done at that point to visually see the 'Bootloader Red' LED function before unplugging?

Yup, every board will still get the 2nd test, which checks the pushbutton and USB connector and LEDs, and gives one final visual inspection.
 
@Paul - Things for the good explanation of all of those other test points... Plus how the boards are tested.

The Card - Looks good enough to me. I like @defragsters comments but, I would not hold up shipping to spend more time yet.

@defragster and @Paul plus @all - With Adafruit and GFX and the warning about PROGMEM.

Not sure of the right fix for the message:
'
In file included from T:\tCode\libraries\Adafruit_GFX\Adafruit_GFX.cpp:3 5:0:

T:\tCode\libraries\Adafruit_GFX\glcdfont.c:13:0: warning: "PROGMEM" redefined
#define PROGMEM
^

In file included from T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4/WProgram.h:41:0,
from T:\TEMP\arduino_build_882294/pch/Arduino.h:6,
from T:\tCode\libraries\Adafruit_GFX\Adafruit_GFX.h:5,
from T:\tCode\libraries\Adafruit_GFX\Adafruit_GFX.cpp:3 4:

T:\Ard186t4b2\hardware\teensy\avr\cores\teensy4/avr/pgmspace.h:28:0: note: this is the location of the previous definition
#define PROGMEM __attribute__((section(".progmem")))
^

First pass was to edit glcdfont.c to not define it in the case of T4:
Like:
Code:
#ifndef FONT5X7_H
#define FONT5X7_H

#ifdef __AVR__
 #include <avr/io.h>
 #include <avr/pgmspace.h>
#elif defined(ESP8266)
 #include <pgmspace.h>
[COLOR="#FF0000"]#elif defined(__IMXRT1052__) || defined(__IMXRT1062__)
// PROGMEM is defefind for T4 to place data in specific memory section[/COLOR]
#else
 #define PROGMEM
#endif

// Standard ASCII 5x7 font

static const unsigned char font[] PROGMEM = {
But that gives a compiler error:
Code:
C:\Users\kurte\Documents\Arduino\libraries\Adafruit_GFX_Library\glcdfont.c:20:35: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PROGMEM'

 static const unsigned char font[] PROGMEM = {

                                   ^
Obviously I can rid myself of both warning and error like:
Code:
#ifdef __AVR__
 #include <avr/io.h>
 #include <avr/pgmspace.h>
#elif defined(ESP8266)
 #include <pgmspace.h>
#elif defined(__IMXRT1052__) || defined(__IMXRT1062__)
// PROGMEM is defefind for T4 to place data in specific memory section
 #undef PROGMEM
 #define PROGMEM
#else
 #define PROGMEM
#endif

But is that what we expect?

@all Hacked up version (first pass) of ST7735_t3 library that compiles and works with my Adafruit_GFX changes mentioned earlier.

So far only pass 1, where I use SPI.transfer() to do the transfers... Also I don't yet have code in to handle putting the display on NON SPI (MOSI, SCLK) pins.
I did however make it work on SPI2 (and probably SPI1, not setup to test yet)...

Will probably do another pass to make use of the T4's SPI FIFO queues. Maybe does not help as much as T3.x where we can encode DC, CS data, but still may help some...
Current version up at: https://github.com/KurtE/ST7735_t3/tree/T4_beta
 
The red boxes are a really interesting idea. But the card really needs to go into printing, at least for the first batch... so I'm really not looking to make much change to the formatting right now. At this point I'm mainly looking to verify the info.

Another rev of the card definitely will be made shortly after the T4 release, since the first batch will be using photos of a beta board.
Indeed the boxes seemed like a good way to contain and group them to make sense of the otherwise disassociated field of 'color blob splatter' and then a single arrow to the proper pin array is meaningful and not messy.

...
About 650 ms, plus a 75 ms "debounce" time from the moment the board is electrically seen on the shorter pogo pins.
It must take longer than that to pick up the board and get it placed and secured :)

Yup, every board will still get the 2nd test, which checks the pushbutton and USB connector and LEDs, and gives one final visual inspection.
Cool.
Does that 2nd test load Blink - or is that pushed in on the 1st test?

@KurtE: I had a 'touchpaint_xpt2046.ino' open and changed:
//#include <ILI9341_t3.h>
#include <Adafruit_ILI9341.h>

And the <Adafruit_ILI9341.h> works - unlike the <ILI9341_t3.h>
Using library XPT2046_Touchscreen at version 1.3 in folder: T:\Ard186t4b2\hardware\teensy\avr\libraries\XPT2046_Touchscreen
Using library SPI at version 1.0 in folder: T:\Ard186t4b2\hardware\teensy\avr\libraries\SPI
Using library Adafruit_ILI9341 at version 1.5.0 in folder: T:\tCode\libraries\Adafruit_ILI9341
Using library Adafruit_GFX at version 1.5.5 in folder: T:\tCode\libraries\Adafruit_GFX
 
I've added the card image to msg #3.


It must take longer than that to pick up the board and get it placed and secured :)

Yup. Also takes time to get it into the anti-static bag, and the get groups of 25 of those into the larger bags, and go through a process we use to double check the counting of boards at the beginning and end of each work session. It's been a while since we've looked at the total time, but previous it was running about 45 seconds per Teensy. About 2 of those 45 seconds are the actual electrical tests.


Does that 2nd test load Blink - or is that pushed in on the 1st test?

LED blink is always loaded in the 2nd test, with an actual USB cable.
 
Just returned from a trip to found the T4 Beta-3 (?) board waiting for me!
It's a work of art! :D
Have to catch up with delayed work, but can't wait to play with the little beast!!!
Thanks Paul!
 
Msg #3 Card image looks good - the tan for USB Host is nice.

Using as Ref 'posted text' for 1062 in MSG#3 :: I did a quick scan - Serial pin #'s line up, and the 3 i2c's, and SPI & CAN pins. I suppose the two AUDIO pins on back were not called out due to space limits?

Did a B&W Laser print of card - all is readable - assume those with limited color vision will get a usable color here or there as needed.

In MSG#3 the posted text for rear pins has #24 and #26 swapped in the pin order - assuming the card with proper numeric order matches the code linkage.


The 'Printed' anti-static bag Teensy 4.0 IMXRT1062 Chip from Beta 2 Mod delivery looks very nice! Those A-S bags are no fun to open :mad:

Very cool that the 1st TEST can program the raw bootloader chips. Wanted to assume the USB cable 2nd Test did Blink as final test, but wasn't sure.
 
I suppose the two AUDIO pins on back were not called out due to space limits?

Which 2 pins?

Pins 32 and 33 are shown with "OUT1B and MCLK2" with yellow background.


In MSG#3 the posted text for rear pins has #24 and #26 swapped in the pin order

I believe that was the (weird) order of the early 1052 boards. Looks like msg #3 hasn't been updated since. Truth is I just randomly connected the 10 remaining pins to those pads at the last minute, even before the decision was made which would be pin 24, 25, etc. Just getting the board routed in only 4 layers and extra size was the main focus, so we could begin the beta test with something.

The order printed on the final PCB and the card definitely is correct.
 
Which 2 pins?

Pins 32 and 33 are shown with "OUT1B and MCLK2" with yellow background.

I believe that was the (weird) order of the early 1052 boards. Looks like msg #3 hasn't been updated since. Truth is I just randomly connected the 10 remaining pins to those pads at the last minute, even before the decision was made which would be pin 24, 25, etc. Just getting the board routed in only 4 layers and extra size was the main focus, so we could begin the beta test with something.

The order printed on the final PCB and the card definitely is correct.

What I saw was here - Audio on #26 and #27 - whatever they mean or do those TX's aren't on card:
Code:
Bottom:
---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
Pin    Name       GPIO  Serial    I2C  SPI     PWM      CAN   Audio      XBAR    FlexIO  Analog
---    ----       ----  ------    ---  ---     ---      ---   ----       ----    ------  ------
24/A10 AD_B0_12   1.12  UART1_TX  4_SCL        PWM1_X2                                   A1:1  
25/A11 AD_B0_13   1.13  UART1_RX  4_SDA        PWM1_X3,GPT1_CLK                          A1:2
26/A12 AD_B1_14   1.30                 3:MOSI                 [B][U]1:TX_BCLK[/U][/B]          3:14    A2:3  
27/A13 AD_B1_15   1.31                 3:SCK                  [B][U]1:TX_SYNC[/U][/B]          3:15    A2:4  
28     EMC_32     3.18  UART7_RX               PWM3_B1
29     EMC_31     4.31  UART7_TX       1:cs1   PWM3_A1
[COLOR=#ff8c00]30     EMC_37     3.23                         GPT1_3   3_RX  3:MCLK     I-23
31     EMC_36     3.22                         GPT1_2   3_TX  3:TX_DATA  I-22[/COLOR]
32     B0_12      2.12                                        1:TX1_RX3  IO-10   2:12
33     EMC_07     4.7                          PWM2_B0        2:MCLK     IO-09   1:7
 
On dual USB device:
Good question. I have not tried this, so I really can't say for sure. One of the chip errata is about power management when both ports are in device mode. That may or may not be an issue, because we're not breaking out the 2 power pins separately.

As I only use the data lines from USB- device, I will try that.
 
Also on my long list of stuff to eventually do is a library to implement USB device on Teensy 3.6's 2nd USB port. If running both ports on T4 in device mode works, would make sense for that library to do both.
 
st7735_t3 library update

As I mentioned yesterday, I needed to first update Arduino GFX code, to compile on Teensy. Still not sure yet what is best/intended way to use PROGMEM on T4 with existing code... More in #3358.

Yesterday first pass got the T4 to work with the library, however it was using SPI.transfer calls...

I updated the graphic test program to get a better idea of the timings...

So, setup looks like:
Code:
ST7735_t3 tft = ST7735_t3(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);

// Option 2: must use the hardware SPI pins
// (for UNO thats sclk = 13 and sid = 11) and pin 10 must be
// an output. This is much faster - also required if you want
// to use the microSD card (see the image drawing example)
//ST7735_t3 tft = ST7735_t3(cs, dc, rst);
float p = 3.1415926;


void setup(void) {
  elapsedMillis timer;
  pinMode(SD_CS, INPUT_PULLUP);  // don't touch the SD card
  Serial.begin(9600);
  Serial.print("hello!");

  // Use this initializer if you're using a 1.8" TFT
  tft.initR(INITR_BLACKTAB);
  // Use this initializer (uncomment) if you're using a 1.44" TFT
  //tft.initR(INITR_144GREENTAB);

  Serial.println("init");

  uint16_t time = millis();
  tft.fillScreen(ST7735_BLACK);
  time = millis() - time;

  Serial.println(time, DEC);
  delay(500);

  // large block of text
  tft.fillScreen(ST7735_BLACK);
  Serial.println("After fill screen");
  testdrawtext("Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur adipiscing ante sed nibh tincidunt feugiat. Maecenas enim massa, fringilla sed malesuada et, malesuada sit amet turpis. Sed porttitor neque ut ante pretium vitae malesuada nunc bibendum. Nullam aliquet ultrices massa eu hendrerit. Ut sed nisi lorem. In vestibulum purus a tortor imperdiet posuere. ", ST7735_WHITE);
  Serial.println("After test draw text");
  delay(1000);

  // tft print function!
  timer = 0;
  tftPrintTest();
  Serial.printf("tftPrintTest: %d\n", (int)timer);
  delay(4000);

  // a single pixel
  tft.drawPixel(tft.width() / 2, tft.height() / 2, ST7735_GREEN);
  delay(500);

  // line draw test
  timer = 0;
  testlines(ST7735_YELLOW);
  Serial.printf("testlines: %d\n", (int)timer);
  delay(500);

  // optimized lines
  timer = 0;
  testfastlines(ST7735_RED, ST7735_BLUE);
  Serial.printf("tftPrintTest: %d\n", (int)timer);
  delay(500);

  timer = 0;
  testdrawrects(ST7735_GREEN);
  Serial.printf("tftPrintTest: %d\n", (int)timer);
  delay(500);

  timer = 0;
  testfillrects(ST7735_YELLOW, ST7735_MAGENTA);
  Serial.printf("tftPrintTest: %d\n", (int)timer);
  delay(500);

  timer = 0;
  tft.fillScreen(ST7735_BLACK);
  testfillcircles(10, ST7735_BLUE);
  testdrawcircles(10, ST7735_WHITE);
  Serial.printf("tftPrintTest: %d\n", (int)timer);
  delay(500);

  timer = 0;
  testroundrects();
  Serial.printf("testroundrects: %d\n", (int)timer);
  delay(500);

  timer = 0;
  testtriangles();
  Serial.printf("testtriangles: %d\n", (int)timer);
  delay(500);

  timer = 0;
  mediabuttons();
  Serial.printf("mediabuttons: %d\n", (int)timer);
  delay(500);

  Serial.println("done");
  delay(1000);
}

Note: I have the code to handle SPI, SPI1 (not tested yet), SP2, on T4. The initial timings were pretty slow: (this is on SPI2)
Code:
hello!init
89
After fill screen
After test draw text
tftPrintTest: 1725
testlines: 1150
tftPrintTest: 127
tftPrintTest: 115
tftPrintTest: 650
tftPrintTest: 273
testroundrects: 312
testtriangles: 185
mediabuttons: 1213
done
As compared to T3.6
Code:
hello!init
23
After fill screen
After test draw text
tftPrintTest: 1559
testlines: 300
tftPrintTest: 33
tftPrintTest: 30
tftPrintTest: 169
tftPrintTest: 71
testroundrects: 81
testtriangles: 49
mediabuttons: 1092
done

So today I hacked on it some more. I took some of the stuff from the PR request for ILI9341_t3, and now use the SPI FIFO, I switch to output 16 bit values. To do this I introduced code for beginTransaction/endTransaction. There are still some optimizations I can do, where you put DC on an SPI cs pin... Most of the code for that is in place. But not some initial stuff...

Current timings are:
Code:
ello!Before Commandlist
After Commandlist
init
30
After fill screen
After test draw text
tftPrintTest: 1580
testlines: 449
tftPrintTest: 44
tftPrintTest: 40
tftPrintTest: 222
tftPrintTest: 102
testroundrects: 114
testtriangles: 70
mediabuttons: 1106
done
Still not as fast as T3.6 ,but pretty good speed ups.

While I was at it, I added SPI Transaction support for T3.x boards as well. Also add support for SPI1/SPI2 (not tested yet) for T3.5/6. Also should be able to work when CS is NOT a CS pin.
The timings for this is showing slightly slower... Why? because the older code would return even though the SPI fifo queue might be full, and as such the timings might happen before we finish outputting 4 16 bit values...

Warning: - I removed the __AVR__ support, plus the Arduino DUE support.

There is still some code in their that on T3.x if you specify non SPI pins, it will try to do it bit banging... Not sure if we need/want to keep this? I have not yet done the bit banging code for T4.

I have not updated the TLC code yet. I suspect I need to do some additional support to make it compile. But again wonder why this is in a _t3 library?

Thoughts?
Want to try it out? https://github.com/KurtE/ST7735_t3/tree/T4_beta (needs my update Adafruit_gfx as well)

Minor Update: I tried T3.6 with SPI1 (MOSI(0), SCK(32), DC(31), CS any digital pin) and it works...
 
Last edited:
Quick update:

With T3.6 - As I mentioned in minor update to previous posting I tried:SPI1 (MOSI(0), SCK(32), DC(31), CS any digital pin) and it works...

Since then I tried on SPI2 with: MOSI(44), SCK(46), CS(54), DC(55) and it works

I also made changes to make it build on TLC.

Also put in code to T4, to allow bit bang when not on SPI pins... And it might be faster.

Again if anyone is interested... it is up on my fork/branch mentioned in previous post.

Will play a little more and maybe issue PR...
 
Good work KurtE - I confirmed the AdaF_GFX with 9341 - but don't have any 7735's to try.

I don't have a good answer for re-define of Progmem … bummer T4 needs it back in use …

<EDIT> … for some reason of course I have one … 128x128 … looks like the pin order matches the ili9341? Just cut the antistatic wrapper off of it
 
@KurtE - I got the github >> ST7735_t3-T4_beta.zip

Compiled and ran the example 'graphistest' in the lib examples - on T4 plugged into PJRC Purple Test PCB

Post#3368 sketch code #1 is incomplete and I don't have : various 'test' things like > testdrawtext

<edit> ran :: "T:\tCode\libraries\ST7735_t3\examples\SpeedTest\SpeedTest.ino" no problem
 
@KurtE in speedtest.ino noted above I did this quick - to repeat the intro tests then it dies - gotta run - not sure what is doing this?::

Note death of locking - requires Button to reprogram:
T:\Ard186t4b2\hardware\teensy/../tools/teensy_post_compile -file=SpeedTest.ino -path=T:\TEMP\arduino_build_497409 -tools=T:\Ard186t4b2\hardware\teensy/../tools -board=TEENSY40 -reboot -port=usb:0/140000/0/8/7 -portlabel=COM25 Serial -portprotocol=Teensy
Unable to open COM25 for reboot request
Windows Error Info: Access is denied.
more ideas... https://forum.pjrc.com/threads/40632?p=126667&viewfull=1#post126667
Previously selected Teensy port is offline.
5 other Teensy boards found. Please select
a Teensy from the Tools > Ports menu.
Unable to open COM25

Make the end of loop() look like this:
Code:
	fps = 1000000.0f/float(end-start);
[B][U]  delay(500);
  firstset();
  delay(500);
[/U][/B]}

Split setup() like this::
Code:
void setup()
{
	pinMode(SD_CS, INPUT_PULLUP);  // keep SD CS high when not using SD card

	// Use this initializer if you're using a 1.8" TFT
	disp.initR(INITR_BLACKTAB);
	// Use this initializer (uncomment) if you're using a 1.44" TFT
	//disp.initR(INITR_144GREENTAB);
[B][U]  firstset();
}
void firstset()
{
[B][COLOR="#FF0000"]        n = 0;[/COLOR][/B]  // Here is the fix - re-running the code ran off array end
[/U][/B]	disp.setRotation(0);
	disp.setTextWrap(true);
	disp.setTextColor(RGB(31,31,31), RGB(0,0,0));
	disp.setCursor(0, 0);

	disp.fillScreen(RGB(0,0,0));

	t[n++] = millis();
	disp.fillScreen(ST7735_BLACK);
	t[n++] = millis();
	testdrawtext("Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur adipiscing ante sed nibh tincidunt feugiat. Maecenas enim massa, fringilla sed malesuada et, malesuada sit amet turpis. Sed porttitor neque ut ante pretium vitae malesuada nunc bibendum. Nullam aliquet ultrices massa eu hendrerit. Ut sed nisi lorem. In vestibulum purus a tortor imperdiet posuere. ", ST7735_WHITE, ST7735_WHITE);
	t[n++] = millis();
	tftPrintTest(false);
	t[n++] = millis();
	testdrawtext("Lorem ipsum dolor sit amet, consectetur adipiscing elit. Curabitur adipiscing ante sed nibh tincidunt feugiat. Maecenas enim massa, fringilla sed malesuada et, malesuada sit amet turpis. Sed porttitor neque ut ante pretium vitae malesuada nunc bibendum. Nullam aliquet ultrices massa eu hendrerit. Ut sed nisi lorem. In vestibulum purus a tortor imperdiet posuere. ", ST7735_WHITE, ST7735_BLACK);
	t[n++] = millis();
	tftPrintTest(true);
	t[n++] = millis();
	testlines(ST7735_YELLOW);
	t[n++] = millis();
	testfastlines(ST7735_RED, ST7735_BLUE);
	t[n++] = millis();
	testdrawrects(ST7735_GREEN);
	t[n++] = millis();
	testfillrects(ST7735_YELLOW, ST7735_MAGENTA);
	t[n++] = millis();
	disp.fillScreen(ST7735_BLACK);
	t[n++] = millis();
	testfillcircles(10, ST7735_BLUE);
	t[n++] = millis();
	testdrawcircles(10, ST7735_WHITE);
	t[n++] = millis();
	testroundrects();
	t[n++] = millis();
	testtriangles();
	t[n++] = millis();
	mediabuttons();
	t[n++] = millis();
	disp.fillScreen(RGB(0,0,0));
}
 
Last edited:
Thanks @defragster.

I might need to see your whole program to see what is happening. Things like where is the array t defined? And where is n defined... Could it be just walking off the end of an array?

Likewise where start and end are defined? (i.e. could it be a divide by 0?)

I updated the graphic test program to do all of the tests in a run_tests function, which is also called in loop and so far it has been running for awhile on T4.
 
@Paul - Things for the good explanation of all of those other test points... Plus how the boards are tested.

The Card - Looks good enough to me. I like @defragsters comments but, I would not hold up shipping to spend more time yet.

@defragster and @Paul plus @all - With Adafruit and GFX and the warning about PROGMEM.

Not sure of the right fix for the message:
'

First pass was to edit glcdfont.c to not define it in the case of T4:
Like:
Code:
#ifndef FONT5X7_H
#define FONT5X7_H

#ifdef __AVR__
 #include <avr/io.h>
 #include <avr/pgmspace.h>
#elif defined(ESP8266)
 #include <pgmspace.h>
[COLOR="#FF0000"]#elif defined(__IMXRT1052__) || defined(__IMXRT1062__)
// PROGMEM is defefind for T4 to place data in specific memory section[/COLOR]
#else
 #define PROGMEM
#endif

// Standard ASCII 5x7 font

static const unsigned char font[] PROGMEM = {
But that gives a compiler error:
Code:
C:\Users\kurte\Documents\Arduino\libraries\Adafruit_GFX_Library\glcdfont.c:20:35: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PROGMEM'

 static const unsigned char font[] PROGMEM = {

                                   ^
Obviously I can rid myself of both warning and error like:
Code:
#ifdef __AVR__
 #include <avr/io.h>
 #include <avr/pgmspace.h>
#elif defined(ESP8266)
 #include <pgmspace.h>
#elif defined(__IMXRT1052__) || defined(__IMXRT1062__)
// PROGMEM is defefind for T4 to place data in specific memory section
 #undef PROGMEM
 #define PROGMEM
#else
 #define PROGMEM
#endif

But is that what we expect?

@all Hacked up version (first pass) of ST7735_t3 library that compiles and works with my Adafruit_GFX changes mentioned earlier.

So far only pass 1, where I use SPI.transfer() to do the transfers... Also I don't yet have code in to handle putting the display on NON SPI (MOSI, SCLK) pins.
I did however make it work on SPI2 (and probably SPI1, not setup to test yet)...

Will probably do another pass to make use of the T4's SPI FIFO queues. Maybe does not help as much as T3.x where we can encode DC, CS data, but still may help some...
Current version up at: https://github.com/KurtE/ST7735_t3/tree/T4_beta

Hi @KurtE - @defragster
Sorry I been missing in action but too much going on right now. Anyway trying to catch up which is always tough. GFX library and PROGMEM has been talked about a few times on the thread - here's one: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=195059&viewfull=1#post195059.

I don't have a ST7735 display so can't really be of much use on that one. But did I read right that touch seemed to work with the 9341 display with the Adafruit lib but had a problem with ILI9341_t3n?
 
opps ... I got a call to a neighbor's house as I saw this - made post and jetted over ... now back ...

It is this included example:: T:\tCode\libraries\ST7735_t3\examples\SpeedTest\SpeedTest.ino

Yes - it is n++ going off the end - this fixes it … edit to above
Code:
void firstset()
{
  n = 0;
 
Status
Not open for further replies.
Back
Top