Forum Rule: Always post complete source code & details to reproduce any issue!
Page 101 of 137 FirstFirst ... 51 91 99 100 101 102 103 111 ... LastLast
Results 2,501 to 2,525 of 3413

Thread: Teensy 4.0 First Beta Test

  1. #2501
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,347
    Quote Originally Posted by defragster
    @KurtE / @mjs513 - let me know where the latest usable 9488 / 9341 / USBHost are and perhaps that can be next.
    ILI9488: https://github.com/mjs513/ILI9488_t3, all changes have been pushed.

    ILI9341_t3: https://github.com/KurtE/ILI9341_t3/tree/T4_Beta, This is Kurt's version, the PR is in to update the master. Only works on SPI, I only tested on SPI1 (UPDATE: TESTED WORKING ON SPI)

    ILI9341_t3n: Haven't tested it yet. https://github.com/KurtE/ILI9341_t3n/, I think that's the latest. (UPDATE: TESTED WORKING ON SPI)
    Last edited by mjs513; 04-26-2019 at 11:21 AM. Reason: Updated test results

  2. #2502
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,347
    Quote Originally Posted by KurtE View Post
    Me too - As Paul pulled our stuff in to the master branch (and beta build), the PR should be against his master branch...
    Ok PR #47 submitted.

  3. #2503
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,098
    I've been looking into the SD issues using SPI. This commit "fixes" SD card access on the audio shield (when CS is set to pin 10), at least well enough for "listfiles" to work, with the 1 card I tested here (Samsung EVO 32GB).

    https://github.com/PaulStoffregen/SD...dea142ed21e95b

    I'm a little concerned this may be a symptom of a SPI timing or signal quality issue...

  4. #2504
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,722
    @defragster - I have not done much yet figuring out the non-boot with Serial4 connected. I tried again with the Adafruit CP2104...

    If I have only GND and RX(adapter)-TX(T4) the T4 boots when I apply power...
    And I get the normal stuff like:
    Code:
    ***********IMXRT Startup**********
    test 1 -1234567 3
    CCM_ANALOG_PLL_USB1=80003000
      enable USB clocks
    CCM_ANALOG_PLL_USB1=80003040
    Increasing voltage to 1250 mV
    need to switch to alternate clock during reconfigure of ARM PLL
    USB PLL is running, so we can use 120 MHz
    Freq: 12 MHz * 100 / 2 / 1
    ARM PLL=80002042
    ARM PLL needs reconfigure
    ARM PLL=80002064
    New Frequency: ARM=600000000, IPG=150000000
    USB reset took 6 loops
    analogInit
    usb_cdc_line_coding, baud=0
    before C++ constructors
    after C++ constructors
    before setup
    after setup
    And Blink program blinks

    But if I also connect the the TX(adapter) - RX(T4) and then apply power to Teensy
    Nothing. Nothing in the T4 monitor and no blinking. Pressing the program button does nothing, but pressing the power button for something like 10 seconds does turn off the power LED on the board pressing it again does start the LED again but still nothing else.

    AND I now tried with an FTDI adapter where the USB connector is marked: TTL-RS232R-3.3V and the T4 is happy... It shows debug information and T4 boots with it attached... Something different on the RX pin...

  5. #2505
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,722
    @defragster, @Paul, @mjs513 - SPI, ILI9488, ILI9341...

    I think most of the answers are in Mikes answer on #2501...

    The update to ILI9341_t3 to work at all on T4 is in PR: https://github.com/PaulStoffregen/ILI9341_t3/pull/52
    Some of this is based off of changes put into: ILI9488 - Although only the parts to work with SPI (not SPI1 and SPI2...)

    To make the ILI9488 work with SPI1 and SPI2, I did some rather gross hacks, as to not use SPIN library which has some additional support that SPI does not (YET), although the data is there in SPI library to make it work properly.

    In Particular: in order to select between using SPI or SPI1 or SPI2, the code needs to be able to select the right set of registers for the SPI port. So we hold onto a pointer to structure of SPI registers... Likewise it needs to know some additional information, like on T3.x how large the FIFO queues are, maybe information on DMA... Again the data is in the SPI library but we don't give APPS a real way to get this information.

    Internal to the SPI library we have access to these bits of information:
    To get access to the hardware registers we use the internal method: port() So on T4 to write to the SPI output register we do: port().TDR = data;
    Likewise to get the additional information to the hardware information, we use the: hardware() function. to gain access.
    Note: the return values/types returned by these functions is public...

    So there are a couple of ways we could make this information easier to get to:
    a) Move port() and hardware() functions into the public part of the SPI definitions... (obviously the easiest way)
    b) Make them protected - and then those who want to use maybe create a subclass of SPI to gain access - would work but...

    Or the hack I did in the ILI9488 library, which is knowing that the first two things in the SPI object are these pointers...
    So something along the line of: Suppose you have pointer to SPI object like: _pspi;
    Code:
        uintptr_t *pt = (uintptr_t*)_pspi;
        _port = (IMXRT_LPSPI_t *)pt[0];   // assuming T4 here
        _phardware = (SPIClass::PI_Hardware_t *)pt[1];
    Note: in current code I used (uint32_t*) instead of uintptr_t...

    Question is should we make a more valid way to do this? If we did I would probably update my ILI9341_t3n library to remove the SPIN library usage

  6. #2506
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,605
    Kurt, I get some warnings:
    Code:
    C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp: In member function 'void ILI9341_t3n::drawFontChar(unsigned int)':
    
    C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp:3002:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    
          while(screen_x<=end_x) {
    
                        ^
    
    C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp:3004:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    
           if ((screen_x >= _displayclipx1) && (screen_x < _displayclipx2) && (screen_y >= _displayclipy1) && (screen_y < _displayclipy2)) {
    
                         ^
    
    C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp:3004:53: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    
           if ((screen_x >= _displayclipx1) && (screen_x < _displayclipx2) && (screen_y >= _displayclipy1) && (screen_y < _displayclipy2)) {
    
                                                         ^
    
    C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp:3006:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    
            if ((screen_x<origin_x) || (screen_x>=glyphend_x)){
    
                         ^
    
    C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp:3139:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    
          while(screen_x<=end_x) {
    
                        ^
    
    C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp:3141:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    
           if ((screen_x >= _displayclipx1) && (screen_x < _displayclipx2) && (screen_y >= _displayclipy1) && (screen_y < _displayclipy2)) {
    
                         ^
    
    C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp:3141:53: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    
           if ((screen_x >= _displayclipx1) && (screen_x < _displayclipx2) && (screen_y >= _displayclipy1) && (screen_y < _displayclipy2)) {
    
                                                         ^
    
    C:\Users\Frank\Documents\Arduino\libraries\ILI9341_t3n\ILI9341_t3n.cpp:3143:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    
            if ((screen_x<origin_x) || (screen_x>=glyphend_x)){
    
                         ^
    Some more warnings in NXP_SDHC.cpp:

    Code:
    :\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp: In function 'int SDHC_CardReadBlock(void*, uint32_t)':
    
    C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:583:13: warning: unused variable 'pData' [-Wunused-variable]
    
       uint32_t* pData = (uint32_t*)buff;
    
                 ^
    
    C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp: In function 'int SDHC_CardWriteBlock(const void*, uint32_t)':
    
    C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:646:19: warning: unused variable 'pData' [-Wunused-variable]
    
       const uint32_t *pData = (const uint32_t *)buff;
    
                       ^
    
    C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp: In function 'void sdhc_setSdclk(uint32_t)':
    
    C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:881:12: warning: unused variable 'm_sdClkKhz' [-Wunused-variable]
    
       uint32_t m_sdClkKhz = f_pll / (1000 * sdclkfs * dvs);
    
                ^
    
    C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp: At global scope:
    
    C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:428:13: warning: 'void SDHC_SetClock(uint32_t)' declared 'static' but never defined [-Wunused-function]
    
     static void SDHC_SetClock(uint32_t sysctl);
    
                 ^
    
    C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:430:12: warning: 'int SDHC_ReadBlock(uint32_t*)' declared 'static' but never defined [-Wunused-function]
    
     static int SDHC_ReadBlock(uint32_t* pData);
    
                ^
    
    C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:431:12: warning: 'int SDHC_WriteBlock(const uint32_t*)' declared 'static' but never defined [-Wunused-function]
    
     static int SDHC_WriteBlock(const uint32_t* pData);
    
                ^
    
    C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:1196:12: warning: 'int SDHC_CMD12_StopTransferWaitForBusy()' defined but not used [-Wunused-function]
    
     static int SDHC_CMD12_StopTransferWaitForBusy(void)
    
                ^
    
    C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:1230:12: warning: 'int SDHC_CMD17_ReadBlock(uint32_t)' defined but not used [-Wunused-function]
    
     static int SDHC_CMD17_ReadBlock(uint32_t sector)
    
                ^
    
    C:\Arduino\hardware\teensy\avr\libraries\SD\utility\NXP_SDHC.cpp:1250:12: warning: 'int SDHC_CMD24_WriteBlock(uint32_t)' defined but not used [-Wunused-function]
    
     static int SDHC_CMD24_WriteBlock(uint32_t sector)
    
                ^

  7. #2507
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,347
    @Frank B and @KurtE

    I have this bad tendency to forget about warnings but Frank is right you do get those warnings for both SDCard and ILI9341_t3n libraries. If you want I will take a look at the libs and see if I can sort it out. Will start now anyway. Know you all are busy with other things.

    EDIT:
    Errors seemed to be centered around the last commit of the anti-aliased fonts. The additional code is using uint32_t's for:
    Code:
    glyphend_x = origin_x+width; // origin_x previous defined in other places as int32_t's
    screen_x     //previously defined at int's in other places.
    
    Looks like end_x is defined as int in the rest of file
    
    So question - save to change to match rest of the .cpp.  Think so.
    Last edited by mjs513; 04-26-2019 at 03:15 PM.

  8. #2508
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,722
    @Frank - Yes I need to go back into ILI9341_t3n and clean up some of these. I think some of them came in with more recent merges...

    As for SD stuff, That part I have not touched.

  9. #2509
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,347
    @KurtE
    Looks like our posts hit at the same time

  10. #2510
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,347
    Quote Originally Posted by PaulStoffregen View Post
    I've been looking into the SD issues using SPI. This commit "fixes" SD card access on the audio shield (when CS is set to pin 10), at least well enough for "listfiles" to work, with the 1 card I tested here (Samsung EVO 32GB).

    https://github.com/PaulStoffregen/SD...dea142ed21e95b

    I'm a little concerned this may be a symptom of a SPI timing or signal quality issue...
    The card I am testing with is a SansDisk Ultra 64Gb and appears to working normally. I ran CardInfo and listfiles with no problems. I ran the datalogger example and then read the file back with dumpfile without a problem. So not sure how to test this?

    EDIT: Which Samsung EVO 32Gb card do you have? Amazon seems to have 3 different versions

  11. #2511
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,605
    I've patched interrupt.c to allow attachInterrupt() with GPIO6..9
    Would be great if you test it? Any way to make it faster?
    https://github.com/PaulStoffregen/cores/pull/370

  12. #2512
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,620
    Quote Originally Posted by KurtE View Post
    @defragster - I have not done much yet figuring out the non-boot with Serial4 connected. I tried again with the Adafruit CP2104...

    If I have only GND and RX(adapter)-TX(T4) the T4 boots when I apply power...


    And Blink program blinks

    But if I also connect the the TX(adapter) - RX(T4) and then apply power to Teensy
    Nothing. Nothing in the T4 monitor and no blinking. Pressing the program button does nothing, but pressing the power button for something like 10 seconds does turn off the power LED on the board pressing it again does start the LED again but still nothing else.

    AND I now tried with an FTDI adapter where the USB connector is marked: TTL-RS232R-3.3V and the T4 is happy... It shows debug information and T4 boots with it attached... Something different on the RX pin...
    My DMM shows 23 mA from T_3.1 Tx hitting the T4-2 Rx when it is off - putting Power to the T4-2 stops the current flow but the T4-2 fails to startup.
    A T_3.6 Tx looks like it is under 20 mA - but on T4-2/Rx it stops power up too.

    I can't see the dim glow in daylight. I did touch T_3.1's 3.3V to that Rx pin and the LED went over half bright and again the T4-2 did not power up.
    Probe from T_3.6 Tx touched breakout Rx and Tx together - opps - and the LED did glow

    I put a 460 ohm resistor on 3.3V output of T_3.1 and it was more like 3 mA and the T4-2 powered up - so that current is a factor and as noted why it takes two current source on Rx in your case and my prior case on the T4-1.

    As noted a UART Tx in idle state holds the pin at 3.3V. With multiples of those connected - or a set of external SPI or i2c with pullups on pins this will be repeated when a powered off T4 is powered.

    Of course taking 3.3V power from the T4 itself doesn't cause a problem because the circuits are all live at the same time. But with UART/i2c/SPI connected to external powered device - like these independently powered UART Tx's it seems an issue.

    As I'm not an EE so my fiddling here is just past what I should be doing - but it seems this is an issue Paul hopefully has on a short list.
    T4-2 is fully functional - it just won't startup with the external UART Tx powered before the T4 gets that default high signal on Rx.

    {edit} - back to the breakout for the T4-1 :: It has underside resistors on Rx and Tx lines! I asked about those way back then … and just remembered them
    >> The T4-2 breakout does NOT have those resistors installed - so Rx on breakout is wired to pin without that added resistor.
    If I put a T_3.6 on common USB:GND to the T4-1 and touch the T_3.6 Tx to T4-1 Rx it also fails to startup. That also goes to the T4-1 reported issue noted - where Multiple T_3.x's for Debug on UARTs caused the issue as each resistor limited current.

    [UPDATE]: With this issue I've not gotten a DEBUG UART device on T4-2 yet, as I was connecting Rx and Tx for BiDi comms. So I put a T_3.1 on Serial4 - but left off the Rx - and it still failed to start up ???

    DVM Shows the T_3.1 holding the Rx line at 3.15 volts - connecting that also stops the T4-2 from powering up without resistors on the line.
    Last edited by defragster; 04-26-2019 at 08:21 PM.

  13. #2513
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,620
    @FrankB - not pretty … but I did find and access some words of static RTC RAM with the following code.
    The book said to expect four 32 bit Dwords - but the 4th only has the lower 16 bit writable? And when I incremented toward MAX uint32_t value it stopped taking changes - it didn't change or wrap - it was fine when I dropped power?
    Also on the T_3.x those RTC uint32's could be mapped to a uint16 pointer and accessed - these seem to be 32 bit access only
    Anyhow the method I used was this:
    Code:
    //  Battery backed NV RAM
    // T4: https://forum.pjrc.com/threads/54711-Teensy-4-0-First-Beta-Test?p=204248&viewfull=1#post204248
    
    // https://forum.pjrc.com/threads/45854-Battery-backed-NV-RAM?p=151035&viewfull=1#post151035
    // https://forum.pjrc.com/threads/55330-Info-adc?p=199876&viewfull=1#post199876
    
    // TIME >> https://forum.pjrc.com/threads/55553-RTC-hour-displays-wrong-time?p=202332&viewfull=1#post202332
    #define qBlink() digitalWriteFast( LED_BUILTIN, !digitalReadFast( LED_BUILTIN ) )
    
    // 3 32 bit Dwords - don't write to the 4th as it has bit set in high 16 bits and those 16 bits won't change - and it cause failed restart
    #define NVRAM_UINT32 ((uint32_t *)0x400A4000)
    
    void setup() {
      pinMode( LED_BUILTIN, OUTPUT );
      qBlink();
      while (!Serial && millis() < 4000 );
      Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__);
      qBlink();
      for ( int ii = 0; ii < 3; ii++ ) {  // only safe 0,1,2 !!
        qBlink();
        Serial.print( NVRAM_UINT32[ii], HEX );
        Serial.print( " _[>" );
        Serial.println( NVRAM_UINT32[ii] / (ii * ii) );
        NVRAM_UINT32[ii] += ii * ii;
        // NVRAM_UINT32[ii] =0;
      }
    }
    void loop(){}
    >Works on T4-1 and T4-2
    Last edited by defragster; 04-28-2019 at 05:44 AM.

  14. #2514
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,347
    Quote Originally Posted by Frank B View Post
    I've patched interrupt.c to allow attachInterrupt() with GPIO6..9
    Would be great if you test it? Any way to make it faster?
    https://github.com/PaulStoffregen/cores/pull/370
    @Frank B
    Since I had the KY-040 rotary encoder I wanted to test I figured I would give it a try. I used pins 14 and 15 - hope those correspond to the same GPIO's. It appears to be working and catching everything. I even noticed something that I didn't notice before so was a good exercise. Here's the sketch I used:
    Code:
    /* Arduino New Rotary Encoder Pin states
    Created by Yvan / https://Brainy-Bits.com
    This code is in the public domain...
    You can: copy it, use it, modify it, share it or just plain ignore it!
    Thx!
    */
    
    volatile boolean TurnDetected;  // need volatile for Interrupts
    
    // Rotary Encoder Module connections
    const int PinCLK=15;   // Generating interrupts using CLK signal
    const int PinDT=14;    // Reading DT signal
    
    // Interrupt routine runs if CLK pin changes state
    void rotarydetect ()  {
      TurnDetected = true;  // set variable to true
    }
    
    void setup ()  {
      Serial.begin(2000000);  // high rate to assure good capture
      attachInterrupt (PinCLK,rotarydetect,CHANGE); // interrupt 0 always connected to pin 2 on Arduino UNO
    }
    
    void loop ()  {
      if (TurnDetected)  { // rotary has been moved
          TurnDetected = false;  // do NOT repeat IF loop until new rotation detected 
          Serial.print("CLK Pin: ");
          Serial.println(digitalRead(PinCLK));
          Serial.print("DT Pin: ");
          Serial.println(digitalRead(PinDT));
          //delay(5);
      }
    }
    ADDITIONAL INFO:
    Ran the above sketch on pins 0/1 and worked well. Also ran the encoder library basic sketch on both pinsets 14/15 and 0/1 and it seemed to resolved something I was seeing periodically. So if I used the right pins I think its working.
    Last edited by mjs513; 04-26-2019 at 08:09 PM. Reason: added info

  15. #2515
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,605
    @mjs: thanks any idea to make it more efficient?

    Thank you Tim.
    I'm not sure if it is useful for the RTC. It would, if there was a way to detect a "cold start" or fresh programming. I don't know of a way to detect it. The SRC_SRSR does not help
    So, the way manitou used (Is the current time younger than the compiled time?) is the best way to determine which time is valid. It works good.

    https://github.com/PaulStoffregen/cores/pull/371
    Last edited by Frank B; 04-26-2019 at 09:16 PM. Reason: updated link

  16. #2516
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,347
    @Frank B

    Your kidding right me. Besides how can you improve on perfection . I'm trying to get CAN-FD working with the SDK example I have - running into some issues almost like for CAN until I broke that code

  17. #2517
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,620
    Paul - what value are those inline Serial Rx/Tx resistors? I can't see markings on them ... either none there or they cooked off. Looks like a resistor on the active Breakout pin to unused pins to then connectthat to the incoming Rx/Tx is needed to prevent T4-2 lockout?

    @FrankB - with no power those registers read zero on startup - but other than that they are static and it would be up to code to decide if it was a restart or reprogram ... Getting time from compiler to compare would answer the new code issue - that would represent a compile time "SerialNumber/Version" - and you have a place to store that now Of course a restart or power Off>On always hits setup.


    Quote Originally Posted by mjs513 View Post
    @Frank B
    Since I had the KY-040 rotary encoder I wanted to test I figured I would give it a try. I used pins 14 and 15 - hope those correspond to the same GPIO's. It appears to be working and catching everything. I even noticed something that I didn't notice before so was a good exercise. Here's the sketch I used:

    ADDITIONAL INFO:
    Ran the above sketch on pins 0/1 and worked well. Also ran the encoder library basic sketch on both pinsets 14/15 and 0/1 and it seemed to resolved something I was seeing periodically. So if I used the right pins I think its working.
    Those are nice with real PINS - I got a pair form SFun and AdaF - both have stamped metal legs … they are buttons too and one may be lighted … but much more work to hook up And amazon at $11 for 5.

  18. #2518
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,722
    @frank B an @Paul and @mjs513 and @defragster and ...

    SPI, (SPI1, SPI2), FlexSPI and SPISettings -

    I know that I mentioned this earlier, but thought I would revisit, especially since looking at SPI1/SPI2, plus FlexIO-SPI...

    History:
    With T.x and earlier with T4... when the user did something like: SPI.beginTransaction(SPISettings(20000000, MSBFIRST, SPI_MODE0));
    The compiler would take the SPISettings stuff and reduce all of this down to simply doing a few sets of the SPI Port register (in particular for T4, the CCR and TCR registers0, with constants. This was because since everythng was know at compile time the compiler coudl do all of the calculations and simply fill in with constants.

    But then the change went in to allow the underlying clock to be changed and have the code understand that and calculate base don that...

    In particular to the change:
    Code:
    -
    		uint32_t d, div;
    		uint32_t clkhz = 528000000u / (((CCM_CBCMR >> 26 ) & 0x07 ) + 1);  // LPSPI peripheral clock
    				
    		const uint32_t clk_sel[4] = {664615384,  // PLL3 PFD1
    					     720000000,  // PLL3 PFD0
    					     528000000,  // PLL2
    					     396000000}; // PLL2 PFD2				
    		uint32_t cbcmr = CCM_CBCMR;
    		uint32_t clkhz = clk_sel[(cbcmr >> 4) & 0x03] / (((cbcmr >> 26 ) & 0x07 ) + 1);  // LPSPI peripheral clock
    		
    		uint32_t d, div;
    The problem is, since now the clode depends on variables like CCM_CBCMR - it can no longer be computed at compile time, so there is a lot more code that happens at each of the places that use SPISettings.
    So both grows code and slows it down.

    Also I have not yet verified that the clock selected for SPI is valid for SPI1 and SPi2...

    There are several things to look at:
    Code:
    	void init_AlwaysInline(uint32_t clock, uint8_t bitOrder, uint8_t dataMode)
    	  __attribute__((__always_inline__)) {
    		// TODO: Need to check timings as related to chip selects?
    				
    		const uint32_t clk_sel[4] = {664615384,  // PLL3 PFD1
    					     720000000,  // PLL3 PFD0
    					     528000000,  // PLL2
    					     396000000}; // PLL2 PFD2				
    		uint32_t cbcmr = CCM_CBCMR;
    		uint32_t clkhz = clk_sel[(cbcmr >> 4) & 0x03] / (((cbcmr >> 26 ) & 0x07 ) + 1);  // LPSPI peripheral clock
    		
    		uint32_t d, div;		
    		if (clock == 0) clock =1;
    		d= clkhz/clock;
    		if (d && clkhz/d > clock) d++;
    		if (d > 257) d= 257;  // max div
    		if (d > 2) {
    			div = d-2;
    		} else {
    			div =0;
    		}
    		ccr = LPSPI_CCR_SCKDIV(div) | LPSPI_CCR_DBT(div/2);
    		tcr = LPSPI_TCR_FRAMESZ(7);    // TCR has polarity and bit order too
    
    		// handle LSB setup 
    		if (bitOrder == LSBFIRST) tcr |= LPSPI_TCR_LSBF;
    
    		// Handle Data Mode
    		if (dataMode & 0x08) tcr |= LPSPI_TCR_CPOL;
    
    		// Note: On T3.2 when we set CPHA it also updated the timing.  It moved the 
    		// PCS to SCK Delay Prescaler into the After SCK Delay Prescaler	
    		if (dataMode & 0x04) tcr |= LPSPI_TCR_CPHA; 
    	}
    The question is do all three SPI boejcts share the same Clock Setting? And do you mind if everything has to be recomputed each time?

    That is we are computing everything depending on the values of the register CCM_CBCMR
    Is this the same for SPI versus SPI1 versus SPI2?

    That is for example suppose you crate an SPI object with speed 2000000

    something like mysettings = SPISettings(200000, MSBFIRST, SPI_MODE0);

    Then if you use this on a beginTransaction for SPi as well as SPi2 and SPi2, do you expect that iw till work properly on all 3?

    Likewise do you expect us to be able to pass in the SPISettings into a flexIO version of SPI, which has a different set of registers?

    For the fun of it I should experiment and see if we notice any differences in speed with, some cases. As for using the SPISettings with FlexIO. By default it is
    sort of not able to be used here as registers defiend and used are different

  19. #2519
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,098
    Quote Originally Posted by defragster View Post
    Paul - what value are those inline Serial Rx/Tx resistors?
    Those resistors are only on the first breakout board, for the beta #1 with the 1052 chip. For the second breakout board design (for beta #2 with 1062) I just used wires, since hand soldering so many not-so-necessary resistors really added a lot of manual labor when building a couple dozen boards. The 3rd rev (replacing the 8 tiny pogo pins with FFC cable) also just has wires. Those 3rd rev boards are being fabricated now and should be ready by the time we get the next round of T4 prototypes with the 1mm pads for FFC.

    On some of those first boards I used 330 ohms, on others 220 ohms (when my supply of 330 ohm 0603 size resistors ran out). If your board has resistors without any marking, they're probably 220 ohms.

    If you *really* want to know, just unplug the serial cable and use a multimeter to measure the resistor.

  20. #2520
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,347
    @KurtE

    Your post on spi settings is really interesting. Here's why, at least for me. When I was trying to debug touchscreen with the graphics library I noticed that the clock for the display was at 30Mhz while the clock for the touch library was at 20Mhz. Don't know if this would be conflict using that rationale. I forgot what I tried now - have to revisit.

  21. #2521
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,098
    Quick CAN question, should I consider using a different transceiver chip on the next breakout board?

    Right now we have MCP2558FD (which I haven't tested in any way....) It claims to work up to 8 Mbit/sec, which doesn't allow the full use of 12 Mbit/sec we supposedly have with the 1062 chip. But most of the other chips I see are rated up to only 2 or 5 Mbit/sec.

    I have almost no experience with CAN or CAN FD. If anyone has opinions on this, please speak up.

  22. #2522
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,347
    Quote Originally Posted by PaulStoffregen View Post
    Quick CAN question, should I consider using a different transceiver chip on the next breakout board?

    Right now we have MCP2558FD (which I haven't tested in any way....) It claims to work up to 8 Mbit/sec, which doesn't allow the full use of 12 Mbit/sec we supposedly have with the 1062 chip. But most of the other chips I see are rated up to only 2 or 5 Mbit/sec.

    I have almost no experience with CAN or CAN FD. If anyone has opinions on this, please speak up.
    The only other chip that I have any experience with the MCP2517FD. Its the same chip that is on Mikroe Chip breakout board, https://www.mikroe.com/mcp2517fd-click, that @tonton81 and I used to test FD between Teensies. Think SK Pang uses the same chip. To be honest don't think I have ever seen and chip that supports 12Mbit/sec yet. But that is just me.

  23. #2523
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    5,605
    @Kurt, the alternative is to not beeing able to use alternate, higher (or lower) SPI frequencies. Is this wanted?

    @Paul: I do not intend to use CAN, and I have not a single board or chip to test it

  24. #2524
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,620
    Quote Originally Posted by PaulStoffregen View Post
    Those resistors are only on the first breakout board, for the beta #1 with the 1052 chip. For the second breakout board design (for beta #2 with 1062) I just used wires, since hand soldering so many not-so-necessary resistors really added a lot of manual labor when building a couple dozen boards. ...
    On some of those first boards I used 330 ohms, on others 220 ohms (when my supply of 330 ohm 0603 size resistors ran out). If your board has resistors without any marking, they're probably 220 ohms.
    ...
    220-330 is close enough - since they aren't marked I only assumed they were resistors - and measuring takes disassembly.

    And yes - it is noted above the resistors are NOT on the Beta 2 breakout - that is why T4-2 is failing for me using a single T_3.1 for debug terminal - the UART standby voltage prevents the T4 from starting up.

  25. #2525
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    4,722
    @Frank - SPISettings and SPI.beginTransaction() - The other option would be to move the functionality around. That is don't have all of the stuff to compute ccr and tcr in that code...
    But instead if necessary compute it within the beginTransaction...

    I did this sort of quick and dirty within my FlexIO SPI implementation:

    The whole implementation of the SPISettings:

    Code:
    class FlexSPISettings {
    public:
    	FlexSPISettings(uint32_t clock, uint8_t bitOrder, uint8_t dataMode) : _clock(clock), 
    		_bitOrder(bitOrder), _dataMode(dataMode) {};
    
    	uint32_t _clock;
    	uint8_t _bitOrder;
    	uint8_t	_dataMode;
    };
    And the FlexSPI::beginTransaction has code that does stuff like:
    Code:
    void FlexSPI::beginTransaction(FlexSPISettings settings) {
    	#ifdef SPI_TRANSACTION_MISMATCH_LED
    	if (inTransactionFlag) {
    		pinMode(SPI_TRANSACTION_MISMATCH_LED, OUTPUT);
    		digitalWrite(SPI_TRANSACTION_MISMATCH_LED, HIGH);
    	}
    	_in_transaction_flag = 1;
    	#endif
    
    	// right now pretty stupid
    	if ((settings._clock != _clock) || (settings._dataMode != _dataMode )) {
    		_clock = settings._clock;
    		_dataMode = settings._dataMode;
    
    		uint32_t clock_speed = _pflex->computeClockRate() / 2;   // get speed divide by 
    		uint32_t div = clock_speed / _clock;
    ...
    Potentially the above could be cleaned up by adding some public functions like
    inline uint32_t clock() {return _clock;} ...

    Just an idea. wondering what you all think? I personally think it will probably reduce code size and probably speed up the T4 SPI by a hair...

    Edit: And if we did something like that, could share the SPISettings with the Flex IO SPI code.

    Edit2: I did a quick and dirty version of this...
    Looks like it actually grows the code some putting all of the stuff into beginTransaction... I would probably move some/all of this into spi.cpp...
    But speed wise, I ran our hacked up version of ili9341_t3n graphic test program (requires updated code to run on T4).
    Without changes:
    Code:
    ILI9341 Test!
    Display Power Mode: 0x80
    MADCTL Mode: 0x80
    Pixel Format: 0x87
    Image Format: 0x7
    Self Diagnostic: 0x87
    Benchmark                Time (microseconds)
    Screen fill              245388
    Text                     12923
    Lines                    85415
    Horiz/Vert Lines         21411
    Rectangles (outline)     13747
    Rectangles (filled)      504228
    Circles (filled)         84719
    Circles (outline)        72371
    Triangles (outline)      20134
    Triangles (filled)       180512
    Rounded rects (outline)  31275
    Rounded rects (filled)   562301
    Done!
    With changes:
    Code:
    ILI9341 Test!
    Display Power Mode: 0x80
    MADCTL Mode: 0x80
    Pixel Format: 0x87
    Image Format: 0x87
    Self Diagnostic: 0x87
    Benchmark                Time (microseconds)
    Screen fill              245230
    Text                     12653
    Lines                    85456
    Horiz/Vert Lines         21388
    Rectangles (outline)     13737
    Rectangles (filled)      503832
    Circles (filled)         83910
    Circles (outline)        71028
    Triangles (outline)      20075
    Triangles (filled)       179844
    Rounded rects (outline)  30850
    Rounded rects (filled)   561661
    Done!
    Again only sped up a touch... Is it worth it?
    Last edited by KurtE; 04-27-2019 at 12:02 AM.

Posting Permissions

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