Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 2 1 2 LastLast
Results 1 to 25 of 46

Thread: Teensyduino 1.49 Beta #3

  1. #1
    Administrator Paul's Avatar
    Join Date
    Oct 2012
    Posts
    352

    Teensyduino 1.49 Beta #3

    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

  2. #2
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,810
    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:
    Code:
     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
    Code:
    ..
    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.

  3. #3
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,810
    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
    Last edited by mjs513; 12-15-2019 at 02:31 PM.

  4. #4
    Senior Member
    Join Date
    Aug 2017
    Posts
    198
    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.

  5. #5
    Senior Member ETMoody3's Avatar
    Join Date
    Mar 2014
    Location
    New Ulm, Mn
    Posts
    118
    No issues as with 1.49 b2

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,476
    Quote Originally Posted by mjs513 View Post
    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.

  7. #7
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,953
    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?

  8. #8
    Senior Member
    Join Date
    Nov 2017
    Location
    Belgium
    Posts
    215
    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.
    Last edited by neurofun; 12-16-2019 at 12:55 AM. Reason: added more info

  9. #9
    Senior Member
    Join Date
    Nov 2017
    Location
    Belgium
    Posts
    215
    T4 @ 600MHz
    With this example beta 3 is about 10x slower than beta2. 2940ms vs 283ms.
    Code:
    #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(){}

  10. #10
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,570
    Quote Originally Posted by neurofun View Post
    T4 @ 600MHz
    With this example beta 3 is about 10x slower than beta2. 2940ms vs 283ms.
    or millis() was wrong in beta2?

  11. #11
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,953
    @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
    Code:
    	//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:
    Code:
    	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
    Last edited by defragster; 12-16-2019 at 08:27 AM.

  12. #12
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,953
    Quote Originally Posted by WMXZ View Post
    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:
    Code:
    #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.

  13. #13
    Senior Member
    Join Date
    Jul 2014
    Posts
    2,570
    Quote Originally Posted by defragster View Post
    I know, that was the reason for suggestion, stated only as question.

  14. #14
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,810
    Quote Originally Posted by defragster
    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:
    Code:
     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

  15. #15
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,810
    Quote Originally Posted by neurofun View Post
    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:
    Code:
    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?

  16. #16
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,476
    Quote Originally Posted by WMXZ View Post
    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.

  17. #17
    Senior Member
    Join Date
    Nov 2017
    Location
    Belgium
    Posts
    215
    Quote Originally Posted by defragster View Post
    @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
    Code:
    	//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:
    Code:
    	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.

    Quote Originally Posted by mjs513 View Post
    @nerofun

    Just ran your example using a Adafruit 800x480 display with their RA8875 controller. Also ran it at a couple SPI speeds:
    Code:
    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

  18. #18
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,810
    @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.

  19. #19
    Senior Member
    Join Date
    Nov 2017
    Location
    Belgium
    Posts
    215
    Did some more tests and USB Type does have some influence.
    With this new test I get opposite results
    Code:
    #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
    Code:
    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
    Code:
    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
    Code:
    80 ms/page
    USB Type : Raw HID
    USB Type : MIDI
    give a solid
    Code:
    86 ms/page

  20. #20
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    6,347
    @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:
    Code:
    #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...
    Code:
    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:
    Code:
    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:
    Code:
    #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:
    Code:
    #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?

  21. #21
    Senior Member
    Join Date
    Nov 2017
    Location
    Belgium
    Posts
    215
    Quote Originally Posted by mjs513 View Post
    @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.

  22. #22
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    4,810
    @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.

  23. #23
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    10,953
    Quote Originally Posted by neurofun View Post
    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.

  24. #24
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,394
    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()
    Code:
      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)
    Last edited by manitou; 12-16-2019 at 06:03 PM.

  25. #25
    Senior Member
    Join Date
    Nov 2017
    Location
    Belgium
    Posts
    215
    Located the problem in SPI.cpp around line 1281
    changed
    Code:
    	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
    Code:
    	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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •