Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 37 of 37

Thread: Teensyduino 1.37 Beta #3

  1. #26
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,653
    @Laur - It has been a long time since I tried the Visual Studio code + the Arduino plug in as I moved to using other setups that load faster and can run on different platforms (like SublimeText)... But I remember there were readme or was it wiki that showed you how to get the Teensy to work with it... You might do a search on this forum as well

  2. #27
    Quote Originally Posted by PaulStoffregen View Post
    Before you do that, could you give the optimized SD lib a try?

    Edit hardware/teensy/avr/libraries/SD/SD_t3.h. Uncomment this line:

    Code:
    //#define USE_TEENSY3_OPTIMIZED_CODE
    Does that make any difference?
    Well, yes. SD.begin(0) returns zero.
    It gets to this line: if (vol->u16[255] != 0xAA55) return false; but the value in that location is 0xd503, not 0xAA55.
    I think this is what happened last time I tried USE_TEENSY3_OPTIMIZED_CODE too.

  3. #28
    Quote Originally Posted by hubbe View Post
    So I tried the git revisions:
    This is the last one that works for me: b2dd72f634ec0fff3d8c00d222a28b13e0ead8a9
    The next check-in is "Single SPIClass for Teensy 3.x".

    I tried commenting out some parts of my code (like reading the motion chip, and the WS2811 support) but that didn't seem to make any difference.

    However, here is the weird part: I tried this on a prop shield, but didn't have a problem. So I tried on a different TeensySaber V2, and that also worked!
    So, apparently, the problem only shows up on my test bed, and only with the newer SPI code....

    So; that makes me think that maybe the timing is tighter, the speed is faster or the drive current is lower. (My test bed has longer traces than the other two things I tested.)
    Next I'm going to dig out my old oscilloscope and see if I can tell what the difference is.
    The difference is the drive strength.

    The difference is in SPI.begin(), the old code says:
    Code:
            SPCR.enable_pins(); // pins managed by SPCRemulation in avr_emulation.h
    The new code says:
    Code:
            reg = portConfigRegister(hardware().mosi_pin[mosi_pin_index]);
            *reg = PORT_PCR_MUX(hardware().mosi_mux[mosi_pin_index]);
            reg = portConfigRegister(hardware().miso_pin[miso_pin_index]);
            *reg= PORT_PCR_MUX(hardware().miso_mux[miso_pin_index]);
            reg = portConfigRegister(hardware().sck_pin[sck_pin_index]);
            *reg = PORT_PCR_MUX(hardware().sck_mux[sck_pin_index]);
    If I look in SPCR.enable_pin, it also sets PORT_PCR_DSE on the relevant pins, while it seems that the new code doesn't.
    I tried using the new code, but calling SPCR.enable_pins() instead of doing the portConfigRegister stuff, and then everything works again.

  4. #29
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,860
    Thanks - I was on a T_3.6 BTW - but I think the issue is Win 10 Latest Creators Update 1703 version . . . #.1358

    Quote Originally Posted by mjs513 View Post
    defragster. Didn't have a 3.2 handy but ran for a 3.5 using the SerMon in IDE 1.8.3 on a windows 10 64bit machine (Version 1607, build 14292.1358:

    Code:
    >>>>>>>>>>>> PRE_TEST setup() millis() now =1401
    hope this helps. Ok, I pulled out a 3.2 and this is what I got with your sketch:
    Code:
     >>>>>>>>>>>> PRE_TEST setup() millis() now =1401
    
     >>>>>>>>>>>> TRUE Serial :: setup() millis() now =1922
    
     >>>>>>LATE  setup() millis() now =1922

  5. #30
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,653
    Quote Originally Posted by hubbe View Post
    The difference is the drive strength.

    The difference is in SPI.begin(), the old code says:
    Code:
            SPCR.enable_pins(); // pins managed by SPCRemulation in avr_emulation.h
    The new code says:
    Code:
            reg = portConfigRegister(hardware().mosi_pin[mosi_pin_index]);
            *reg = PORT_PCR_MUX(hardware().mosi_mux[mosi_pin_index]);
            reg = portConfigRegister(hardware().miso_pin[miso_pin_index]);
            *reg= PORT_PCR_MUX(hardware().miso_mux[miso_pin_index]);
            reg = portConfigRegister(hardware().sck_pin[sck_pin_index]);
            *reg = PORT_PCR_MUX(hardware().sck_mux[sck_pin_index]);
    If I look in SPCR.enable_pin, it also sets PORT_PCR_DSE on the relevant pins, while it seems that the new code doesn't.
    I tried using the new code, but calling SPCR.enable_pins() instead of doing the portConfigRegister stuff, and then everything works again.
    I wonder which pins need this and which ones don't?
    Example in old code SPI.setMOSI()
    If I set pin 11 (default) it sets: CORE_PIN11_CONFIG = PORT_PCR_DSE | PORT_PCR_MUX(2);
    But if I tell it to use pin 7 it simply does: CORE_PIN7_CONFIG = PORT_PCR_MUX(2);

    So I see three different ways to fix this:
    a) always set DSE on these all of these pins
    b) add another table to my hardware() structure which says to add or not to add.
    c) Change the table that has the mux number to instead have the uint32_t reg value: so for most it would have PORT_PCR_MUX(2), but others could have the DSE mapped in as well..

    Right now thinking a) or c)...

  6. #31
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,653
    @Paul - I generated a version c) of above where instead of holding a 8 bit value for the mux value, I am storing the 32 value to assign to the port register for the pin...

    I then converted all of the 2,2,2 into the correct PORT_PCR_MUX(2), ... and for pins 11, 13 I added on the PORT_PCR_DSE as that is what the old code does
    SPCR.enable_pins().

    Again not sure why we only push the speed up on these pins. Like should I update all MOSI and SCK pin to have this option?

    Also it may be overkill I did it for all of the pin types include CS pins.

    Anyway you might want to take a look, I put it in as a Pull Request: https://github.com/PaulStoffregen/SPI/pull/27/files

    It would be good if others tried it out, the updated files are up at: https://github.com/KurtE/SPI/tree/EN...on-enable-pins

  7. #32
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,355
    Quote Originally Posted by defragster View Post
    Closed TyComm and opened IDE 1.8.3 and it shows 'teensy' grayed?? - can't test against IDE SerMon::
    Attachment 10831
    I don't understand how you've getting "COM8" without "(Teensy)".

    Here's what I see when I test on Windows 10 ver 1703.

    Click image for larger version. 

Name:	Capture2.PNG 
Views:	208 
Size:	307.4 KB 
ID:	10838

  8. #33
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,355
    >>>>>>LATE setup() millis() now =1922
    Ok, seems obvious some Windows systems open the serial port quite slowly.

    I'll try lengthening the wait in Serial.begin().

  9. #34
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,839
    I went ahead and changed line 79 in usb_serial.h to 4000 (checked GitHub first) and this is what I get after the changed (T3.5):

    >>>>>>>>>>>> PRE_TEST setup() millis() now =1913

    >>>>>>>>>>>> setup() millis() now =1913

    >>>>>>>>>>>> TRUE Serial :: setup() millis() now =1913

    >>>>>>LATE setup() millis() now =1913

    millis() now ++ =3004
    BOOT_on_Time=400
    Serial_begin_Time=1913
    Serial? setup() wait?=1913
    Serial_on_Time loop()=1913

    millis() now ++ =3004
    BOOT_on_Time=400
    Serial_begin_Time=1913
    Serial? setup() wait?=1913
    Serial_on_Time loop()=1913

    millis() = 4005 5005 6005

  10. #35
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    18,355
    I just set it to 2.5 seconds. Hopefully that will be enough for most Windows systems.

  11. #36
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,839
    Gave it a whirl at 2.5 seconds, looks like it should work. Have a Win 7 desktop will give it a shot over there in a little bit:
    Code:
    >>>>>>>>>>>> PRE_TEST setup() millis() now =2432
    
     >>>>>>>>>>>> setup() millis() now =2432
    
     >>>>>>>>>>>> TRUE Serial :: setup() millis() now =2432
    
     >>>>>>LATE  setup() millis() now =2432
    
     millis() now ++ =3004
    BOOT_on_Time=400
    Serial_begin_Time=2432
    Serial? setup() wait?=2432
    Serial_on_Time loop()=2432
    
     millis() now ++ =3004
    BOOT_on_Time=400
    Serial_begin_Time=2432
    Serial? setup() wait?=2432
    Serial_on_Time loop()=2432

  12. #37
    Administrator Paul's Avatar
    Join Date
    Oct 2012
    Posts
    306
    1.37-beta4 is now available. Closing this thread.

    https://forum.pjrc.com/threads/44937...no-1-37-Beta-4

Posting Permissions

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