Teensyduino 1.49 Beta #3

[Paul]

Here is a third beta test for Teensyduino 1.49.


EDIT: links removed, please use 1.49-beta5


Changes since Teensyduino 1.49-beta2

Fix delay() and micros() on Teensy 4.0 at 24 MHz
Fix USB touchscreen
Fix serial receive at very high baud rates on Teensy 4.0
Fix MIDI+Serial on Teensy 4.0
Fix USB Keyboard sending "garbage" in long strings on Teensy 4.0
Fix analogWrite for values >= 2^res on certain Teensy 4.0 pins
Wire only clear FIFO with bus is idle on Teensy 4.0 (KurtE)
Wire use open drain pin config on Teensy 4.0
Update ST7735_t3 library
SPI optimize usingInterrupt() on Teensy 4.0 (FrankB)
SPI allow faster clock speeds on Teensy 4.0 (KurtE)
Fix daylight saving time issue with automatic RTC set on Teensy 4.0
Add Makefile for Teensy 4.0
Add main.cpp for Teensy 4.0 (KurtE)
Fix compiler warnings on Teensy 2.0

[mjs513]

Downloaded and installed TD1.49 Beta 3 on Windows 10x64 Home (all updates installed to date) with out any issue.

As an initial test ran @defragster version of the ClocksT4.ino sketch to test the clock changes. Tests ran at 240, 110, 600, 130, 110, 24, and back to 600Mhz. Only frequency that failed was for the 130 Mhz clock speed:

 F_CPU=129600000	50ms delay:: 1009 us and 1 ms
System Clock: 129600000
IPG Clock: 129600000
Semc Clock: 43200000
RTC Clock: 32768
USB1pll Clock: 480000000
Peripheral Clock: 24000000
Osc Clock: 24000000
Arm Clock: 648000000
….

 >>>>>>>>>>>>>>>>>>>>   BUGBUG   @129 MHz  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
 F_CPU=129600000

running your test sketch sure enough showed the clock running backwards

…..
4408004 -> 4408000
4409004 -> 4409000
4410004 -> 4410000
4411004 -> 4411000
-----

Then tested the usb keyboard example sketch "simple.ino" with Notepad++ and it print to the "Hello World" plus the count to Notepad++. Printing to sermon only showed the count being printed not hellow world?

Will test BNO080 and a couple of others but have to get them set up.

[mjs513]

Tested changes to the Wire library with three devices:

1. LidarLite V4LED: worked no issues
2. BNO055: worked out of the box no issues
3. BNO080: kind of worked. Tested with three example sketches. Sometimes on initial load would I had to change wire.clockSpeed from 400 to 100 and 400 and it would start working. Possible it needs additional pull-ups to work properly. But it would work...

EDIT: BNO080 pin configs = see post https://forum.pjrc.com/threads/58654...l=1#post223872 in the beta #2 thread

[wwatson]

Now showing correct RTC time after an upload. Not an hour off.
Skipped TD 1.49 Beta 2 so not sure which TD it changed in.

[ETMoody3]

No issues as with 1.49 b2

[PaulStoffregen]

running your test sketch sure enough showed the clock running backwards

Ok, I've put this on my list of bugs to fix.

But since the errors are so small and only happen at certain slower CPU speeds, I'm going to work on this later.

[defragster]

TD 1.49 b3 installed on Win 10 - works.

per @mjs513 post #2 above : ClocksT4.ino sketch much improved - 130 MHz is intermittent? Need to try the Grieman SDFat_Beta - posted on that thread it was not working at 150?

[neurofun]

T4 @ 600MHz
using this RA8875 lib: https://github.com/mjs513/RA8875 to draw 2 different types of screens.

With TD1.49b2
screen1 takes about 23ms to draw
screen2 takes about 65ms to draw

With TD1.49b3
screen1 takes about 180ms to draw
screen2 takes about 450ms to draw

The screens take about 7-8 times longer to draw with beta3 than with beta2, which is obviously not good.

T4 @ 528MHz

With TD1.49b3
screen1 takes about 125ms to draw
screen2 takes about 320ms to draw

The screens draw faster @528MHz than @600MHz.

[neurofun]

T4 @ 600MHz
With this example beta 3 is about 10x slower than beta2. 2940ms vs 283ms.

#include <SPI.h>
#include <RA8875.h>

//teensy4 SPI0 RA8875
#define TFT_CS      10
#define TFT_RST      9  // 255 = unused, connect to 3.3V
#define TFT_MOSI    11
#define TFT_SCLK    13
#define TFT_MISO    12

RA8875 tft = RA8875(TFT_CS, TFT_RST, TFT_MOSI, TFT_SCLK, TFT_MISO);

void setup(){
  while (!Serial && millis() < 2500);
  
  tft.begin(RA8875_800x480);
  tft.fillWindow(RA8875_BLACK);
  
  uint32_t msec = millis();

  for(int x = 0; x < 800; x += 10){
    for(int y = 0; y < 480; y += 10){
      tft.drawRect(x , y, 8, 8, RA8875_YELLOW);
      tft.fillRect(x+2 , y+2, 4, 4, RA8875_YELLOW);
    }
  }
  
  msec = millis() - msec;
  Serial.print(msec);
  Serial.println(" ms/page");
}
void loop(){}

[WMXZ]

T4 @ 600MHz
With this example beta 3 is about 10x slower than beta2. 2940ms vs 283ms.

or millis() was wrong in beta2?

[defragster]

@Paul and #mjs513:

Paul - thanks for leaving the old "...\teensy\avr\cores\teensy4\clockspeed.c" code in place under COMMENT!

I reverted to that code {based on github link} and my "(embarrassingly opps updated) sketch" shows repeated failures { for 24 and 110 MHz }, that change did change something for the better!

The sketch as it was truly was detecting the errors - but there was a lurking edge condition yielding the false positive BUGBUG indications after the change. The one line addition to that code is in red updated in this post : Teensy-4-0-Clock-speed-influences-delay-and-SPI {@mjs513 - perhaps you can test w/td1.49b3 and not see any sings of failure}

With the observed correction to the provided test sketch - and the TD 1.49b3 code as shipped - those detected time anomalies are gone!

Before seeing the correction issue in the sketch the 1.49b3 code was giving FALSE intermittent BUGBUG notes. It may be the first call to millis() after

To get to finding this I dug into the micros() code and pulled out the values used to determine that { and recorded them before and after set_arm_clock() - and they all appear SANE somehow across frequency change. They can't be perfect as the reference points like "F_CPU_ACTUAL/1000000" change significantly. But with the clockspeed.c change of setting 'CCM_CBCDR' for beta 3 passes that test code okay, and reverting it to beta 2 state gives the failures - and even in that case the micros() values pulled make sense.

If all else tests well maybe that is the end of this.


The DISPLAY slowdown seen by @neurofun is odd - from what I see of the change that provided the correction it was not a direct change to millis() or micros(). Maybe the change made should only be used for change to lower speed clocks?

@neurofun: is the 10X slowdown obviously visible in drawing - or just as reported by the timing code? As noted above the prior code remains under comments and a quick edit/save/rebuild can restore the Beta 2 code - as long as you start and stay at 600 MHz it isn't expected to change anything:
in :: \hardware\teensy\avr\cores\teensy4\clockspeed.c find these lines

	//cbcdr &= ~CCM_CBCDR_PERIPH_CLK_SEL;
	//CCM_CBCDR = cbcdr;  // why does this not work at 24 MHz?
	CCM_CBCDR &= ~CCM_CBCDR_PERIPH_CLK_SEL;
	while (CCM_CDHIPR & CCM_CDHIPR_PERIPH_CLK_SEL_BUSY) ; // wait

And swap the comments on the lines to appear like this:

	cbcdr &= ~CCM_CBCDR_PERIPH_CLK_SEL;
	CCM_CBCDR = cbcdr;  // why does this not work at 24 MHz?
	// CCM_CBCDR &= ~CCM_CBCDR_PERIPH_CLK_SEL;
	while (CCM_CDHIPR & CCM_CDHIPR_PERIPH_CLK_SEL_BUSY) ; // wait

[defragster]

or millis() was wrong in beta2?

@WMXZ - thread you started : forum.pjrc.com/threads/58053-T4-set_arm_clock-and-micros()

Exhibited the issue with:

#if defined(__IMXRT1062__)
extern "C" uint32_t set_arm_clock(uint32_t frequency);
#endif

void setup() {
  // put your setup code here, to run once:
#if defined(__IMXRT1062__)
  set_arm_clock(24000000); // comment here to get full speed
#endif
}

void loop() {
  // put your main code here, to run repeatedly:
 static uint32_t t0;
 if(millis()>(t0+1000))
 {
   t0=millis();
   uint32_t t1=micros();
   delay(50);
   Serial.println(micros()-t1);
 }
}

With TD 1.49Beta3 can you reproduce that issue - or what led you to see it?

I just tested against beta 3 and no problem, and p#11 reversion to Beta 2 indeed produces the issue.

My abuse of that code {noted in post #11} to a function was showing false positives when I didn't set "t0" on entry. But code as presented in your thread seems fixed just by changing the code as shown in p#11.

[WMXZ]

@WMXZ - thread you started : forum.pjrc.com/threads/58053-T4-set_arm_clock-and-micros()

I know, that was the reason for suggestion, stated only as question.

[mjs513]

The sketch as it was truly was detecting the errors - but there was a lurking edge condition yielding the false positive BUGBUG indications after the change. The one line addition to that code is in red updated in this post : Teensy-4-0-Clock-speed-influences-delay-and-SPI {@mjs513 - perhaps you can test w/td1.49b3 and not see any sings of failure}

Unfortunately, at 130mhz the error is still there even with your code change to clocksT4:

 F_CPU=129600000	50ms delay:: 1009 us and 1 ms
System Clock: 129600000

IPG Clock: 129600000

Semc Clock: 43200000

RTC Clock: 32768

USB1pll Clock: 480000000

Peripheral Clock: 24000000

Osc Clock: 24000000

Arm Clock: 648000000

Usb1PllPfd0 Clock: 720000000

Usb1PllPfd1 Clock: 664615368

Usb1PllPfd2 Clock: 508235292

Usb1PllPfd3 Clock: 454736826

Usb2Pll Clock: 24000000

SysPll Clock: 528000000

SysPllPfd0 Clock: 351999990

SysPllPfd1 Clock: 594000000

SysPllPfd2 Clock: 396000000

SysPllPfd3 Clock: 297000000

EnetPll0 Clock: 0

EnetPll1 Clock: 0

AudioPll Clock: 786480000

VideoPll Clock: 0


 >>>>>>>>>>>>>>>>>>>>   BUGBUG   @129 MHz  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
 F_CPU=129600000

[mjs513]

T4 @ 600MHz
With this example beta 3 is about 10x slower than beta2. 2940ms vs 283ms.

@nerofun

Just ran your example using a Adafruit 800x480 display with their RA8875 controller. Also ran it at a couple SPI speeds:

12Mhz SPI
600:    293 ms/page
528:    297 ms/page
396:    307 ms/page

16Mhz SPI
600:    252 ms/page
528:    252 ms/page
396:    266 ms/page

18Mhz SPI
600:    258 ms/page
528:    257 ms/page
396:    446 ms/page

Are you sure about that 2940ms?

[PaulStoffregen]

or millis() was wrong in beta2?

As far as I know, no bugs have been found with millis().

However, micros() had at least 2 bugs. Neither is new. These have been with us since Teensy 4.0 release.

Functions like delay() which use micros() internally are also affected by these micros() bugs.

Bug #1: (fixed) When configured for 24 MHz speed, we were actually running at 30 MHz, but F_CPU_ACTUAL was set to 24000000. When F_CPU_ACTUAL is wrong, micros() computes incorrect output.

Bug #2: (not fixed) At certain slower CPU speeds, micros() gives wrong results just before millis() increments. For example, if millis() is currently 499 and about to turn to 500, the bug in micros() might result in output like 500001, even though micros() should never report more than 499999 while millis() is still 499.

So far, neither of these bugs has been found while running at 600 or 528 MHz.

[neurofun]

@neurofun: is the 10X slowdown obviously visible in drawing - or just as reported by the timing code? As noted above the prior code remains under comments and a quick edit/save/rebuild can restore the Beta 2 code - as long as you start and stay at 600 MHz it isn't expected to change anything:
in :: \hardware\teensy\avr\cores\teensy4\clockspeed.c find these lines

	//cbcdr &= ~CCM_CBCDR_PERIPH_CLK_SEL;
	//CCM_CBCDR = cbcdr;  // why does this not work at 24 MHz?
	CCM_CBCDR &= ~CCM_CBCDR_PERIPH_CLK_SEL;
	while (CCM_CDHIPR & CCM_CDHIPR_PERIPH_CLK_SEL_BUSY) ; // wait

And swap the comments on the lines to appear like this:

	cbcdr &= ~CCM_CBCDR_PERIPH_CLK_SEL;
	CCM_CBCDR = cbcdr;  // why does this not work at 24 MHz?
	// CCM_CBCDR &= ~CCM_CBCDR_PERIPH_CLK_SEL;
	while (CCM_CDHIPR & CCM_CDHIPR_PERIPH_CLK_SEL_BUSY) ; // wait

The slowdown is clearly visible on the display.
Changing clockspeed.c does not resolve the slowdown.

@nerofun

Just ran your example using a Adafruit 800x480 display with their RA8875 controller. Also ran it at a couple SPI speeds:

12Mhz SPI
600:    293 ms/page
528:    297 ms/page
396:    307 ms/page

16Mhz SPI
600:    252 ms/page
528:    252 ms/page
396:    266 ms/page

18Mhz SPI
600:    258 ms/page
528:    257 ms/page
396:    446 ms/page

Are you sure about that 2940ms?

Yes, I'm sure about 2940ms. But that was yesterday.
Today the times vary around 2300ms, which I really don't understand.

After investigating a little further I noticed changing USB Type has an influence on the speed.
Serial = +-2000ms
Serial + MIDI = +-2000ms
MIDI = +-2300ms
Raw HID = +-2300ms

[mjs513]

@neurofun

That's really strange results you are getting with your RA8875. Watching the display there is no noticeable delay at all. I can't seem to duplicate your problems with my Adafruit display. Its like your SPI settings are way off. To get anywhere to what you are seeing I have to run at 180khz clock vs 18mhz, then I will see about 2700ms to update the screen.

[neurofun]

Did some more tests and USB Type does have some influence.
With this new test I get opposite results

#include <SPI.h>
#include <RA8875.h>

//teensy4 SPI0 RA8875
#define TFT_CS      10
#define TFT_RST      9  // 255 = unused, connect to 3.3V
#define TFT_MOSI    11
#define TFT_SCLK    13
#define TFT_MISO    12

RA8875 tft = RA8875(TFT_CS, TFT_RST, TFT_MOSI, TFT_SCLK, TFT_MISO);

void setup(){
  while (!Serial && millis() < 2500);
  
  tft.begin(RA8875_800x480);
}
void loop(){
  tft.fillWindow(RA8875_BLACK);
  
  uint32_t msec = millis();

  for(int x = 0; x < 800; x += 10){
    for(int y = 0; y < 480; y += 10){
      // tft.drawRect(x , y, 8, 8, RA8875_YELLOW);
      // tft.fillRect(x+2 , y+2, 4, 4, RA8875_YELLOW);
      tft.setCursor(x, y);
      tft.print("Z");

    }
  }
  
  msec = millis() - msec;
  Serial.print(msec);
  Serial.println(" ms/page");
}

USB Type : Raw HID
USB Type : MIDI

572 ms/page
591 ms/page
588 ms/page
621 ms/page
604 ms/page
607 ms/page
617 ms/page
604 ms/page
594 ms/page
630 ms/page
612 ms/page
596 ms/page
601 ms/page
598 ms/page
618 ms/page
619 ms/page
617 ms/page
623 ms/page
640 ms/page
649 ms/page
656 ms/page
665 ms/page
657 ms/page
656 ms/page
660 ms/page
639 ms/page
643 ms/page
653 ms/page

USB Type : Serial
USB Type : Serial + MIDI

964 ms/page
959 ms/page
979 ms/page
959 ms/page
997 ms/page
1027 ms/page
1028 ms/page
1045 ms/page
1042 ms/page
1059 ms/page
1067 ms/page
1072 ms/page
1062 ms/page
1135 ms/page
1137 ms/page
1122 ms/page
1129 ms/page
1088 ms/page
1141 ms/page
1211 ms/page
1184 ms/page
1217 ms/page
1185 ms/page
1218 ms/page
1209 ms/page
1247 ms/page
1294 ms/page
1278 ms/page
1248 ms/page
1263 ms/page
1304 ms/page
1307 ms/page
1320 ms/page
1331 ms/page
1333 ms/page
1348 ms/page
1357 ms/page
1345 ms/page
1345 ms/page
1370 ms/page
1420 ms/page
1398 ms/page
1448 ms/page
1412 ms/page
1409 ms/page
1438 ms/page
1409 ms/page
1441 ms/page

Time slowly creeps up.
Re-uploading the code and the previous creep is still there.
Power cycling the T4 for 10sec and the creep starts from zero again.


Reverting back to beta2
USB Type : Serial
gives a solid

80 ms/page

USB Type : Raw HID
USB Type : MIDI
give a solid

86 ms/page

[KurtE]

@neurofun @mjs513 - If I get a chance I will try to get one of my buydisplay units hooked back up...
Again I am assuming T4. I will probably try to hook up the 800x...

@Paul and @mjs513 - Sorry for cross post... I have already posted this on the ADC thread... But Paul was wondering if it makes sense to update IMXRT.h for the ADC_ETC #defines to add more defines for options and potentially for a structure...

That is the current #defines:

#define IMXRT_ADC_ETC		(*(IMXRT_REGISTER32_t *)0x403B0000)
#define ADC_ETC_CTRL			(IMXRT_ADC_ETC.offset000)
#define ADC_ETC_DONE0_1_IRQ		(IMXRT_ADC_ETC.offset004)
#define ADC_ETC_DONE2_ERR_IRQ		(IMXRT_ADC_ETC.offset008)
#define ADC_ETC_DMA_CTRL		(IMXRT_ADC_ETC.offset00C)
#define ADC_ETC_TRIG0_CTRL		(IMXRT_ADC_ETC.offset010)
#define ADC_ETC_TRIG0_COUNTER		(IMXRT_ADC_ETC.offset014)
#define ADC_ETC_TRIG0_CHAIN_1_0		(IMXRT_ADC_ETC.offset018)
#define ADC_ETC_TRIG0_CHAIN_3_2		(IMXRT_ADC_ETC.offset01C)
#define ADC_ETC_TRIG0_CHAIN_5_4		(IMXRT_ADC_ETC.offset020)
#define ADC_ETC_TRIG0_CHAIN_7_6		(IMXRT_ADC_ETC.offset024)
#define ADC_ETC_TRIG0_RESULT_1_0	(IMXRT_ADC_ETC.offset028)
#define ADC_ETC_TRIG0_RESULT_3_2	(IMXRT_ADC_ETC.offset02C)
#define ADC_ETC_TRIG0_RESULT_5_4	(IMXRT_ADC_ETC.offset030)
#define ADC_ETC_TRIG0_RESULT_7_6	(IMXRT_ADC_ETC.offset034)
#define ADC_ETC_TRIG1_CTRL		(IMXRT_ADC_ETC.offset038)
#define ADC_ETC_TRIG1_COUNTER		(IMXRT_ADC_ETC.offset03C)
#define ADC_ETC_TRIG1_CHAIN_1_0		(IMXRT_ADC_ETC.offset040)
#define ADC_ETC_TRIG1_CHAIN_3_2		(IMXRT_ADC_ETC.offset044)
#define ADC_ETC_TRIG1_CHAIN_5_4		(IMXRT_ADC_ETC.offset048)
#define ADC_ETC_TRIG1_CHAIN_7_6		(IMXRT_ADC_ETC.offset04C)
#define ADC_ETC_TRIG1_RESULT_1_0	(IMXRT_ADC_ETC.offset050)
#define ADC_ETC_TRIG1_RESULT_3_2	(IMXRT_ADC_ETC.offset054)
#define ADC_ETC_TRIG1_RESULT_5_4	(IMXRT_ADC_ETC.offset058)
#define ADC_ETC_TRIG1_RESULT_7_6	(IMXRT_ADC_ETC.offset05C)

Repeats for 7 triggers... I am just showing first 2...
But I think could be: Note Just typed in, so need to check if compiler likes...

typedef struct {
	uint32_t DONE0_1_IRQ;				// offset004
	uint32_t DONE2_ERR_IRQ;				// offset008
	uint32_t DMA_CTRL;					// offset00C
	struct {
		uint32_t CTRL;					//offset010
		uint32_t COUNTER;				//offset014
		uint32_t CHAIN_1_0;				//offset018
		uint32_t CHAIN_3_2;				//offset01C
		uint32_t CHAIN_5_4;				//offset020
		uint32_t CHAIN_7_6;				//offset024
		uint32_t RESULT_1_0;			//offset028
		uint32_t RESULT_3_2;			//offset02C
		uint32_t RESULT_5_4;			//offset030
		uint32_t RESULT_7_6;			//offset034
	} TRIG[7];
} IMXRT_ADC_ETC_t;

Or could maybe be:

typedef struct {
	uint32_t DONE0_1_IRQ;				// offset004
	uint32_t DONE2_ERR_IRQ;				// offset008
	uint32_t DMA_CTRL;					// offset00C
	struct {
		uint32_t CTRL;					//offset010
		uint32_t COUNTER;				//offset014
		uint32_t CHAIN_NP1_N[4];
		uint32_t RESULT_NP1_N[4]l
	} TRIG[7];
} IMXRT_ADC_ETC_t;

Also depending on if which structure, I assume you would want all the #define
#define IMXRT_ADC_ETC (*(IMXRT_ADC_ETC_t *)0x403B0000)

#define ADC_ETC_CTRL (IMXRT_ADC_ETC.CTRL)


Also Have defines for most of the sub-options like:

#define ADC_ETC_CTRL_SOFTRST				((uint32_t)(1<<31))
#define ADC_ETC_CTRL_TSC_BYPASS				((uint32_t)(1<<30))
#define ADC_ETC_CTRL_DMA_MODE_SEL			((uint32_t)(1<<29))
#define ADC_ETC_CTRL_PRE_DIVIDER(n)			((uint32_t)(((n) & 0xff) << 16))
#define ADC_ETC_CTRL_EXT1_TRIG_PRIORITY(n)	((uint32_t)(((n) & 0x07) << 13))
#define ADC_ETC_CTRL_EXT1_TRIG_ENABLE		((uint32_t)(1<<12))
#define ADC_ETC_CTRL_EXT0_TRIG_PRIORITY(n)	((uint32_t)(((n) & 0x07) << 9))
#define ADC_ETC_CTRL_EXT0_TRIG_ENABLE		((uint32_t)(1<<8))
#define ADC_ETC_CTRL_TRIG_ENABLE(n)			((uint32_t)(((n) & 0xff) << 0))

#define ADC_ETC_DONE0_1_IRQ_TRIG7_DONE1		((uint32_t)(1<<23))
#define ADC_ETC_DONE0_1_IRQ_TRIG6_DONE1		((uint32_t)(1<<22))
#define ADC_ETC_DONE0_1_IRQ_TRIG5_DONE1		((uint32_t)(1<<21))
#define ADC_ETC_DONE0_1_IRQ_TRIG4_DONE1		((uint32_t)(1<<20))
#define ADC_ETC_DONE0_1_IRQ_TRIG3_DONE1		((uint32_t)(1<<19))
#define ADC_ETC_DONE0_1_IRQ_TRIG2_DONE1		((uint32_t)(1<<18))
#define ADC_ETC_DONE0_1_IRQ_TRIG1_DONE1		((uint32_t)(1<<17))
#define ADC_ETC_DONE0_1_IRQ_TRIG0_DONE1		((uint32_t)(1<<16))
#define ADC_ETC_DONE0_1_IRQ_TRIG7_DONE0		((uint32_t)(1<<7))
#define ADC_ETC_DONE0_1_IRQ_TRIG6_DONE0		((uint32_t)(1<<6))
#define ADC_ETC_DONE0_1_IRQ_TRIG5_DONE0		((uint32_t)(1<<5))
#define ADC_ETC_DONE0_1_IRQ_TRIG4_DONE0		((uint32_t)(1<<4))
#define ADC_ETC_DONE0_1_IRQ_TRIG3_DONE0		((uint32_t)(1<<3))
#define ADC_ETC_DONE0_1_IRQ_TRIG2_DONE0		((uint32_t)(1<<2))
#define ADC_ETC_DONE0_1_IRQ_TRIG1_DONE0		((uint32_t)(1<<1))
#define ADC_ETC_DONE0_1_IRQ_TRIG0_DONE0		((uint32_t)(1<<0))

#define ADC_ETC_DONE2_ERR_TRIG7_ERR			((uint32_t)(1<<23))
#define ADC_ETC_DONE2_ERR_TRIG6_ERR			((uint32_t)(1<<22))
#define ADC_ETC_DONE2_ERR_TRIG5_ERR			((uint32_t)(1<<21))
#define ADC_ETC_DONE2_ERR_TRIG4_ERR			((uint32_t)(1<<20))
#define ADC_ETC_DONE2_ERR_TRIG3_ERR			((uint32_t)(1<<19))
#define ADC_ETC_DONE2_ERR_TRIG2_ERR			((uint32_t)(1<<18))
#define ADC_ETC_DONE2_ERR_TRIG1_ERR			((uint32_t)(1<<17))
#define ADC_ETC_DONE2_ERR_TRIG0_ERR			((uint32_t)(1<<16))
#define ADC_ETC_DONE2_ERR_TRIG7_DONE2		((uint32_t)(1<<7))
#define ADC_ETC_DONE2_ERR_TRIG6_DONE2		((uint32_t)(1<<6))
#define ADC_ETC_DONE2_ERR_TRIG5_DONE2		((uint32_t)(1<<5))
#define ADC_ETC_DONE2_ERR_TRIG4_DONE2		((uint32_t)(1<<4))
#define ADC_ETC_DONE2_ERR_TRIG3_DONE2		((uint32_t)(1<<3))
#define ADC_ETC_DONE2_ERR_TRIG2_DONE2		((uint32_t)(1<<2))
#define ADC_ETC_DONE2_ERR_TRIG1_DONE2		((uint32_t)(1<<1))
#define ADC_ETC_DONE2_ERR_TRIG0_DONE2		((uint32_t)(1<<0))

#define ADC_ETC_DMA_CTRL_TRIG7_REQ			((uint32_t)(1<<23))
#define ADC_ETC_DMA_CTRL_TRIG6_REQ			((uint32_t)(1<<22))
#define ADC_ETC_DMA_CTRL_TRIG5_REQ			((uint32_t)(1<<21))
#define ADC_ETC_DMA_CTRL_TRIG4_REQ			((uint32_t)(1<<20))
#define ADC_ETC_DMA_CTRL_TRIG3_REQ			((uint32_t)(1<<19))
#define ADC_ETC_DMA_CTRL_TRIG2_REQ			((uint32_t)(1<<18))
#define ADC_ETC_DMA_CTRL_TRIG1_REQ			((uint32_t)(1<<17))
#define ADC_ETC_DMA_CTRL_TRIG0_REQ			((uint32_t)(1<<16))
#define ADC_ETC_DMA_CTRL_TRIG7_ENABLE		((uint32_t)(1<<7))
#define ADC_ETC_DMA_CTRL_TRIG6_ENABLE		((uint32_t)(1<<6))
#define ADC_ETC_DMA_CTRL_TRIG5_ENABLE		((uint32_t)(1<<5))
#define ADC_ETC_DMA_CTRL_TRIG4_ENABLE		((uint32_t)(1<<4))
#define ADC_ETC_DMA_CTRL_TRIG3_ENABLE		((uint32_t)(1<<3))
#define ADC_ETC_DMA_CTRL_TRIG2_ENABLE		((uint32_t)(1<<2))
#define ADC_ETC_DMA_CTRL_TRIG1_ENABLE		((uint32_t)(1<<1))
#define ADC_ETC_DMA_CTRL_TRIG0_ENABLE		((uint32_t)(1<<0))

#define ADC_ETC_TRIG_CTRL_SYNC_MODE			((uint32_t)(1<<16))
#define ADC_ETC_TRIG_CTRL_TRIG_PRIORITY(n)	((uint32_t)(((n) & 0x07) << 12))
#define ADC_ETC_TRIG_CTRL_TRIG_CHAIN(n)		((uint32_t)(((n) & 0x07) << 8))
#define ADC_ETC_TRIG_CTRL_TRIG_MODE			((uint32_t)(1<<4))
#define ADC_ETC_TRIG_CTRL_SW_TRIG			((uint32_t)(1<<0))

#define ADC_ETC_TRIG_COUNTER_SAMPLE_INTERVAL(n)	((uint32_t)(((n) & 0xff) << 16))
#define ADC_ETC_TRIG_COUNTER_INIT_DELAY(n)		((uint32_t)(((n) & 0xff) << 0))

#define ADC_ETC_TRIG_CHAIN_IE1(n)			((uint32_t)(((n) & 0x03) << 29))
#define ADC_ETC_TRIG_CHAIN_B2B1				((uint32_t)(1<<28))
#define ADC_ETC_TRIG_CHAIN_HWTS1(n)			((uint32_t)(((n) & 0xff) << 20))
#define ADC_ETC_TRIG_CHAIN_CSEL1(n)			((uint32_t)(((n) & 0x0f) << 16))
#define ADC_ETC_TRIG_CHAIN_IE0(n)			((uint32_t)(((n) & 0x03) << 13))
#define ADC_ETC_TRIG_CHAIN_B2B0				((uint32_t)(1<<12))
#define ADC_ETC_TRIG_CHAIN_HWTS0(n)			((uint32_t)(((n) & 0xff) << 4))
#define ADC_ETC_TRIG_CHAIN_CSEL0(n)			((uint32_t)(((n) & 0x0f) << 0))
// DO we copy for chain 3-2 ...

#define ADC_ETC_TRIG_RESULT_DATA1(n)		((uint32_t)(((n) & 0xff) << 16))
#define ADC_ETC_TRIG_RESULT_DATA0(n)		((uint32_t)(((n) & 0xff) << 0))

Note: depending on if/how we create structure, may need to edit the a above like:

#define ADC_ETC_TRIG_CHAIN_IE1(n)			((uint32_t)(((n) & 0x03) << 29))
#define ADC_ETC_TRIG_CHAIN_B2B1				((uint32_t)(1<<28))
#define ADC_ETC_TRIG_CHAIN_HWTS1(n)			((uint32_t)(((n) & 0xff) << 20))
#define ADC_ETC_TRIG_CHAIN_CSEL1(n)			((uint32_t)(((n) & 0x0f) << 16))
#define ADC_ETC_TRIG_CHAIN_IE0(n)			((uint32_t)(((n) & 0x03) << 13))
#define ADC_ETC_TRIG_CHAIN_B2B0				((uint32_t)(1<<12))
#define ADC_ETC_TRIG_CHAIN_HWTS0(n)			((uint32_t)(((n) & 0xff) << 4))
#define ADC_ETC_TRIG_CHAIN_CSEL0(n)			((uint32_t)(((n) & 0x0f) << 0))

To either create duplicates for each of the other CHAIN/RESULT B2B1 would be B4B2 ... for the 2nd one...
Or leave or change N and NP1... or NP1 NP2...

Thoughts?

[neurofun]

@neurofun

That's really strange results you are getting with your RA8875. Watching the display there is no noticeable delay at all. I can't seem to duplicate your problems with my Adafruit display. Its like your SPI settings are way off. To get anywhere to what you are seeing I have to run at 180khz clock vs 18mhz, then I will see about 2700ms to update the screen.

It is indeed very strange. The display i'm using is the 4.3" from buydisplay.
I even wonder if it has anything to do with SPI because in my main application I also use the SPI1 bus to read the contents of 10 shiftregisters(74hc165) @2MHz.
The time to read the shiftregisters is about 33usec both in beta2 & beta3.

@KurtE
yes teensy4 and 800x480 4.3" RA8875 from buydisplay.

[mjs513]

@neurofun
Just installed b2 over a copy of the 1.8.10 I had already installed. I am still seeing 272 ms/page @600Mhz for the adafruit display. Unless its something with the Adafruit display vs the buydisplay RA8875

EDIT: Oops - cross post.

[defragster]

The slowdown is clearly visible on the display.
Changing clockspeed.c does not resolve the slowdown.


Yes, I'm sure about 2940ms. But that was yesterday.
Today the times vary around 2300ms, which I really don't understand.

After investigating a little further I noticed changing USB Type has an influence on the speed.
Serial = +-2000ms
Serial + MIDI = +-2000ms
MIDI = +-2300ms
Raw HID = +-2300ms

With that change reverted AFAIK it says any slowdown isn't related to that clockspeed.c change.

And if slowdown clearly visible - it isn't a time measure issue.

[manitou]

I ran neurofun's sketch on T4@600mhz, but I have nothing attached to SPI (i have no RA8875). With scope hooked to 13 (SPI CLK), here are my results for various SPI CLK settings in tft.begin()

  Teensyduino 1.48  T4@600mhz  -O2
 SPImhz   ms   scopemhz
   def   237      18.9
     8   437       7.6
    13   304      12.5
    16   276      15.1
    50   173      43.7
  Teensyduino 1.49-beta3
   def   196      20.8
     8   390       8
    13   281      12.6
    16   239      15.9
    30   164      35
    50   132      54

this is using mjs513's branch of RA8875 lib (_t4)

[neurofun]

Located the problem in SPI.cpp around line 1281
changed

	CCM_CBCMR = (CCM_CBCMR & ~(CCM_CBCMR_LPSPI_PODF_MASK | CCM_CBCMR_LPSPI_CLK_SEL_MASK)) |
		CCM_CBCMR_LPSPI_PODF(2) | CCM_CBCMR_LPSPI_CLK_SEL(1); // pg 714
//		CCM_CBCMR_LPSPI_PODF(6) | CCM_CBCMR_LPSPI_CLK_SEL(2); // pg 714

back to

	CCM_CBCMR = (CCM_CBCMR & ~(CCM_CBCMR_LPSPI_PODF_MASK | CCM_CBCMR_LPSPI_CLK_SEL_MASK)) |
//		CCM_CBCMR_LPSPI_PODF(2) | CCM_CBCMR_LPSPI_CLK_SEL(1); // pg 714
  		CCM_CBCMR_LPSPI_PODF(6) | CCM_CBCMR_LPSPI_CLK_SEL(2); // pg 714

and my display performs the same as in beta2.