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

Thread: Teensyduino 1.37 Beta #3

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

    Teensyduino 1.37 Beta #3

    Here is a third beta test for Teensyduino 1.37.

    Linux 32 bit:
    https://www.pjrc.com/teensy/td_137-b...nstall.linux32

    Linux 64 bit:
    https://www.pjrc.com/teensy/td_137-b...nstall.linux64

    Linux ARM:
    https://www.pjrc.com/teensy/td_137-b...stall.linuxarm

    Mac OS-X:
    https://www.pjrc.com/teensy/td_137-b...inoInstall.dmg

    Windows:
    https://www.pjrc.com/teensy/td_137-b...inoInstall.exe


    Changes since Teensyduino 1.37-beta2

    Improve min() max() for C++ compatibility (tni)
    Fix analogWrite to DAC with LTO (tni)
    Fix DMAChannel repeated transferCount (KurtE)
    Fix DMAChannel alignment on Teensy LC (tni)
    Fixes to OctoWS2811

  2. #2
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,534
    I assume they are being uploaded now as system not finding them.

    Edit: This time windows one was found...

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,615
    Opps, yeah. Upload is done, so you should be able to get them now. Well, except for Raspberry Pi. It will take a couple hours to finish building...

  4. #4
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,682
    Hi Paul. Retest the rover sketches which uses std::vector along with multiple libs as noted before and all ok. Tested also with the Kalman filter which uses the Eigen lib and all ok. The min/max issue I had is cleared up. Also, I tested tried the usb host shield 2.0 lib with their board_qc sketch and it worked as well.

    Just wanted to let you know and say thanks.

  5. #5
    Senior Member
    Join Date
    May 2015
    Posts
    329
    1.37 beta 1 changes list included gnu11, I thought that was already done in 1.36. Did I misunderstand ?

  6. #6
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,534
    Installed B3 on W10 1.8.3 and so far so good. Again as I noted in Beta2... Clear Output button does nothing in TeensyMonitor....
    Verified DMAChannel stuff was updated... Thanks

    Was going to try on RPI3, but looks like build still not up.

  7. #7
    If I load the HelloSerialMonitor example and select "MTP Disk (experimental)" I get no printouts in the TeensyMonitor.
    (It works if I select "Serial" or "MIDI".)

  8. #8
    I'm still having a problem with the SPI library. It's causing freezes in my lightsaber code. (https://github.com/profezzorn/TeensySaber)
    I know it's related to the SPI code, because if I copy an older version of the SPI library into the beta folder, everything works fine.
    My code is pretty similar to the WavFilePlayer example, so I tried triggering the bug there, but no luck.
    From reading and comparing the two SPI libraries, it looks like they are supposed to perform identically, but there seems to be *some* difference at least.
    One more clue: When the freeze occurs, if I reset the teensy, but keep the power on, SD.begin() fails, and it keeps failing until I disconnect the power and plug it back in again.

    Any ideas of things I can try to narrow down the problem?
    Is there anything the new SPI library purposely does differently?

  9. #9
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,615
    Quote Originally Posted by hubbe View Post
    If I load the HelloSerialMonitor example and select "MTP Disk (experimental)" I get no printouts in the TeensyMonitor.
    I tried just now, but couldn't reproduce the problem.

    Click image for larger version. 

Name:	sc.png 
Views:	362 
Size:	209.3 KB 
ID:	10819

    I used Teensy 3.6 testing on Ubuntu 14.04 64 bit, with the setting you can see in this screenshot. The printing is appearing in the serial monitor.

    Can you give me more specific details on how you tested, so I can try to reproduce it?

  10. #10
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,615
    Quote Originally Posted by DaQue View Post
    1.37 beta 1 changes list included gnu11, I thought that was already done in 1.36. Did I misunderstand ?
    Maybe you're thinking of the toolchain update? From version 1.21 to 1.35, we were using gcc 4.8.4. Before that, version 1.12 (the first to support 32 bit Teensy 3.0) to 1.20 used gcc 4.7.2.

    Version 1.3.6 updated to gcc 5.4.1. This update has been attempted on 1.34-beta1, but we reverted back to gcc 4.8.4 when many issues were found and an unexpected Arduino release prompted the need to wrap up 1.34 quickly.

    For a very long time, we've been compiling with "-std=gnu++0x". Version 1.37 changes to "-std=gnu++11", which apparently is the same for gcc 5.4.

    Shortly after the 1.37 release, we're going to start 1.38-beta1 with exactly the same code as 1.37, but using "-std=gnu++14". Like the aborted toolchain update of 1.34-beta1, if we run into lots of compatibility issues, I'll probably revert to C++11. But the idea of a quick 1.38-beta1 is to give us time to test.

  11. #11
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,682
    I used Teensy 3.6 testing on Ubuntu 14.04 64 bit, with the setting you can see in this screenshot. The printing is appearing in the serial monitor.
    Was reading about MTP in the forum so I decided to give it a try. I used a Teensy 3.5 on my Windows 10 laptop and it printed "Hello World". However, if I closed the monitor and reopened the monitor it showed that the connection was connection was closed. If I closed it again and reopened the Serial Monitor right away it would start the printing to the monitor again.

    Not sure if this is the expected behavior. Just getting into it.

    Mike

    UPDATE: Just tried the Blinky_mtp sketch from the MTP library and it worked fine. Windows 10 recognized it as a MTP device and was able to read the sd card.
    Last edited by mjs513; 06-16-2017 at 12:52 PM. Reason: Update

  12. #12
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,682
    After trying out the MTP Blinky_mtp sketch I tried to re-run the HelloSerialMonitor sketch. After loading I opened the serial monitor got a "no connection" mention and the monitor showed closed. If I closed the monitor and reopened it, the monitor showed it was online but nothing was printing out. However, after a few minutes of leaving the serial monitor open it would start printing "Hello World" again. But after it started printing the first time and closed, reopen, closed, reopen process (described in message 11) it would print right away. The process is repeatable if i disconnect the teensy 3.5 and plug it back in.

  13. #13
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,534
    Quote Originally Posted by hubbe View Post
    I'm still having a problem with the SPI library. It's causing freezes in my lightsaber code. (https://github.com/profezzorn/TeensySaber)
    I know it's related to the SPI code, because if I copy an older version of the SPI library into the beta folder, everything works fine.
    My code is pretty similar to the WavFilePlayer example, so I tried triggering the bug there, but no luck.
    From reading and comparing the two SPI libraries, it looks like they are supposed to perform identically, but there seems to be *some* difference at least.
    One more clue: When the freeze occurs, if I reset the teensy, but keep the power on, SD.begin() fails, and it keeps failing until I disconnect the power and plug it back in again.

    Any ideas of things I can try to narrow down the problem?
    Is there anything the new SPI library purposely does differently?
    What older version of SPI works and which one does not? In particular: does the one from Teensyduino 1.36 work? or was it 1.35? Again trying to narrow down what changes....

    With 1.35 to 1.36, the SPI.transfer(buf, cnt) was updated for faster speed. That is before then, it worked something like:
    for(int i=0; i< cnt; i++) buf[i] = SPI.transfer(buf[i]);

    So there were gaps of time between transfers. With the 1.36 version the transfer was sped up to use the queue... But my quick look through your sketch I don't see anywhere you are using SPI directly? I don't think you are using FAST_LED? So maybe the SD library code. So far I don't see anywhere that uses transfer with buf...

    With this beta of code, the main difference is that all of the SPI objects use the same Class. So all are SPIClass. There is no longer SPI1Class/SPI2Class or the like...
    The only places I expect this to hit are code like maybe DMASPI library, maybe my SPIN library...

    Might help to know more, like what your setup is? T3.2? With Propshield? minimal setup needed to reproduce.

    Thanks

  14. #14
    Quote Originally Posted by PaulStoffregen View Post
    I tried just now, but couldn't reproduce the problem.

    Click image for larger version. 

Name:	sc.png 
Views:	362 
Size:	209.3 KB 
ID:	10819

    I used Teensy 3.6 testing on Ubuntu 14.04 64 bit, with the setting you can see in this screenshot. The printing is appearing in the serial monitor.

    Can you give me more specific details on how you tested, so I can try to reproduce it?
    I'm using a Teensy 3.2 on Ubuntu 16.04.02 64-bit.
    I can try it on a teensy 3.6 after work.

  15. #15
    Quote Originally Posted by KurtE View Post
    What older version of SPI works and which one does not? In particular: does the one from Teensyduino 1.36 work? or was it 1.35? Again trying to narrow down what changes....

    With 1.35 to 1.36, the SPI.transfer(buf, cnt) was updated for faster speed. That is before then, it worked something like:
    for(int i=0; i< cnt; i++) buf[i] = SPI.transfer(buf[i]);

    So there were gaps of time between transfers. With the 1.36 version the transfer was sped up to use the queue... But my quick look through your sketch I don't see anywhere you are using SPI directly? I don't think you are using FAST_LED? So maybe the SD library code. So far I don't see anywhere that uses transfer with buf...

    With this beta of code, the main difference is that all of the SPI objects use the same Class. So all are SPIClass. There is no longer SPI1Class/SPI2Class or the like...
    The only places I expect this to hit are code like maybe DMASPI library, maybe my SPIN library...

    Might help to know more, like what your setup is? T3.2? With Propshield? minimal setup needed to reproduce.

    Thanks
    Hmm, I don't know what version of teensyduino I had before. How do I find out? (Paul, would it be possible to put version number in the installer filenames?)
    However, I compared the working SPI installation with stuff from github, and found that the working SPI has this revision: a8af486c7be94edee0854e7673badb7310a691e1
    There are a couple of revisions between this and HEAD (which is what the beta is using), and I can try those later today to pinpoint where the problem starts to occur.

    My setup is a Teensy 3.2 with a TeensySaber V2 shield. However, a prop shield and an sd adapter wired up like this: http://fredrik.hubbe.net/lightsaber/electronics.html should work just as well.
    To reproduce the problem using lightsaber.ino, I just play a wav file by typing "play title.wav" in the serial console. It usually plays for a few seconds, then hangs.

    lightsaber.ino is basically reading WAV file data from the sd card when it hangs. It's quite similar to what the WavFilePlayer example does, however there are a few differences, like:
    1. It's about 7 thousand lines longer...
    2. WAV file reading is handled by a software interrupt instead of doing it directly from the audio DMA interrupt
    3. My wav decoder reads 512-byte aligned data, one block at a time.
    4. There is some i2c communication going on with the motion chip at the same time. (I'm going to try disabling this to see if makes any difference.)

    Later today, I will try it with a prop shield to make sure the problem occurs there too. (It should, but you never know...)
    Next I'm going to take an axe to my code and see if I can come up with a smaller example.

  16. #16
    Quote Originally Posted by hubbe View Post
    Hmm, I don't know what version of teensyduino I had before. How do I find out? (Paul, would it be possible to put version number in the installer filenames?)
    However, I compared the working SPI installation with stuff from github, and found that the working SPI has this revision: a8af486c7be94edee0854e7673badb7310a691e1
    There are a couple of revisions between this and HEAD (which is what the beta is using), and I can try those later today to pinpoint where the problem starts to occur.

    My setup is a Teensy 3.2 with a TeensySaber V2 shield. However, a prop shield and an sd adapter wired up like this: http://fredrik.hubbe.net/lightsaber/electronics.html should work just as well.
    To reproduce the problem using lightsaber.ino, I just play a wav file by typing "play title.wav" in the serial console. It usually plays for a few seconds, then hangs.

    lightsaber.ino is basically reading WAV file data from the sd card when it hangs. It's quite similar to what the WavFilePlayer example does, however there are a few differences, like:
    1. It's about 7 thousand lines longer...
    2. WAV file reading is handled by a software interrupt instead of doing it directly from the audio DMA interrupt
    3. My wav decoder reads 512-byte aligned data, one block at a time.
    4. There is some i2c communication going on with the motion chip at the same time. (I'm going to try disabling this to see if makes any difference.)

    Later today, I will try it with a prop shield to make sure the problem occurs there too. (It should, but you never know...)
    Next I'm going to take an axe to my code and see if I can come up with a smaller example.
    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.

  17. #17
    Quote Originally Posted by hubbe View Post
    I'm using a Teensy 3.2 on Ubuntu 16.04.02 64-bit.
    I can try it on a teensy 3.6 after work.
    Tried it on a Teensy 3.6, with the same result.
    Also tried a different USB hub, and I tried killing gvfs-mtp-volume-monitor, but it seems to make no difference.
    I should be able to try it on mac & windows later or tomorrow.

  18. #18
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,441
    Does Serial.begin(57600); still wait up to 1 second before returning to allow Serial to come online in 1.37b3?

    I'm not seeing it act that way as I don't see this print - maybe it is something with my system - and it is late:
    Code:
    void setup() {
      Serial.begin(57600);
      if ( Serial ) {
        Serial.print("\n >>>>>>>>>>>> setup() millis() now =");    Serial.println(millis());
      }
    }

  19. #19
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,615
    Quote Originally Posted by defragster View Post
    Does Serial.begin(57600); still wait up to 1 second before returning to allow Serial to come online in 1.37b3?
    Yes, it does, or at least it's supposed to do so:

    https://github.com/PaulStoffregen/co...b_serial.h#L78

    Maybe 1 second isn't enough. Can you try increasing the number on line 79 from 1000 to something like 10000? Does that make it work on your system?

  20. #20
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,615
    Quote Originally Posted by hubbe View Post
    Tried it on a Teensy 3.6, with the same result.
    Also tried a different USB hub, and I tried killing gvfs-mtp-volume-monitor, but it seems to make no difference.
    I should be able to try it on mac & windows later or tomorrow.
    I tried just now on a Mac with Teensy 3.2. Prints in the serial monitor after every upload.

    Click image for larger version. 

Name:	sc.png 
Views:	260 
Size:	501.7 KB 
ID:	10826

    Admittedly this is a very old Mac, running 10.7.5. I could go get a test machine with Sierra if needed...

  21. #21
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,615
    Quote Originally Posted by hubbe View Post
    Next I'm going to take an axe to my code and see if I can come up with a smaller example.
    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?

  22. #22
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,441
    Quote Originally Posted by PaulStoffregen View Post
    Yes, it does, or at least it's supposed to do so:

    https://github.com/PaulStoffregen/co...b_serial.h#L78

    Maybe 1 second isn't enough. Can you try increasing the number on line 79 from 1000 to something like 10000? Does that make it work on your system?
    I'll try in a few hours to give a better demo - that setup() was minimized. But the time I see after return is NO WAIT on calling Serial.begin().

    This is on my Win10 updated machine, using TyComm as SerMon. Serial does come online in good time - the sketch I picked to test SublimeTest/Stino to work has another leftover edit that needs to go. IDE 1.8.3.

  23. #23
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    6,441
    This sketch DEvolved to this state - but it is showing me no prints from setup() but then does prints after it enters loop().

    Win 10 :: WinVer == 1703.15063.413

    Closed TyComm and opened IDE 1.8.3 and it shows 'teensy' grayed?? - can't test against IDE SerMon::
    Click image for larger version. 

Name:	gray_Teensy.png 
Views:	425 
Size:	23.8 KB 
ID:	10831

    These lines come from within loop() - nothing before?
    millis() now ++ =3004
    BOOT_on_Time=400
    Serial_begin_Time=400
    Serial? setup() wait?=400
    Serial_on_Time loop()=400

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

    millis() = 4005
    Code:
    #define qBlink() * portToggleRegister(LED_BUILTIN) = 1;
    uint32_t BOOT_on_Time;
    uint32_t Serial_begin_Time; // inside setup()
    uint32_t Serial_on_TimeS; // inside setup()
    uint32_t Serial_on_TimeL; // inside loop()
    int DisplayLimit = 2;
    uint32_t blinkWait = 100;
    elapsedMillis doBlink;
    
    void setup()
    {
      BOOT_on_Time = millis();
      pinMode(LED_BUILTIN, OUTPUT);
      digitalWriteFast(LED_BUILTIN, HIGH);
      Serial.begin(57600);
      Serial_begin_Time = millis();
      Serial.print("\n >>>>>>>>>>>> PRE_TEST setup() millis() now =");
      Serial.println(millis());
      if (Serial)
      {
        Serial.print("\n >>>>>>>>>>>> setup() millis() now =");
        Serial.println(millis());
      }
      Serial_on_TimeS = Serial_on_TimeL = millis();
      while (!Serial && millis() < 2000)
      {
        if (doBlink > blinkWait)
        {
          qBlink();
          doBlink = 0;
        }
        Serial_on_TimeS = millis();
        Serial_on_TimeL = millis();
      }
      if (Serial)
      {
        Serial.print("\n >>>>>>>>>>>> TRUE Serial :: setup() millis() now =");
        Serial.println(millis());
      }
      blinkWait = 250;
      // another option is to use the bitband toggle macro like this
      while (millis() < 3000)
      {
        if (Serial)
        {
          Serial.print("\n >>>>>>LATE  setup() millis() now =");
          Serial.println(millis());
          while (millis() < 3000);
        }
        * portToggleRegister(LED_BUILTIN) = 1;
        delayMicroseconds(4500);
      }
    }
    
    void loop()
    {
      static int mCnt = 11;
      if (!Serial)
      {
        Serial_on_TimeL = millis();
      }
      else
        if (Serial && DisplayLimit)
        {
          DisplayLimit -= 1;
          Serial.print("\n millis() now ++ =");
          Serial.println(millis());
          Serial.print("BOOT_on_Time=");
          Serial.println(BOOT_on_Time);
          Serial.print("Serial_begin_Time=");
          Serial.println(Serial_begin_Time);
          Serial.print("Serial? setup() wait?=");
          Serial.println(Serial_on_TimeS);
          Serial.print("Serial_on_Time loop()=");
          Serial.println(Serial_on_TimeL);
          doBlink = 0;
          blinkWait = 1000;
        }
      if (doBlink > blinkWait)
      {
        qBlink();
        doBlink -= blinkWait;
        if (++mCnt > 10)
        {
          Serial.print(" \n millis() =");
          mCnt = 0;
        }
        Serial.print(" ");
        Serial.print(millis());
      }
    }
    Last edited by defragster; 06-17-2017 at 04:32 PM. Reason: WinVer == 1703.15063.413

  24. #24
    Senior Member
    Join Date
    Jul 2014
    Location
    New York
    Posts
    1,682
    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
     
     millis() = 3000 3000 3000 3000 3157 3407 3657 3907
     millis() now ++ =4126
    BOOT_on_Time=400
    Serial_begin_Time=1401
    Serial? setup() wait?=2000
    Serial_on_Time loop()=4125
    
     millis() now ++ =4126
    BOOT_on_Time=400
    Serial_begin_Time=1401
    Serial? setup() wait?=2000
    Serial_on_Time loop()=4125
     5127 6127 7127 
     millis() = 8127 9127 10127 11127 12127 13127 14127 15127 16127 17127 18127 
     millis() = 19127 20127 21127 22127 23127 24127 25127 26127 27127 28127 29127 
     millis() = 30127 31127 32127 ...
    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
    
     millis() now ++ =3004
    BOOT_on_Time=400
    Serial_begin_Time=1401
    Serial? setup() wait?=1922
    Serial_on_Time loop()=1922
    
     millis() now ++ =3004
    BOOT_on_Time=400
    Serial_begin_Time=1401
    Serial? setup() wait?=1922
    Serial_on_Time loop()=1922
     
     millis() = 4005 5005 6005 7005 8005 9005 10005 11005 12005 13005 14005 
     millis() = 15005 16005 17005 18005 19005 20005 21005 22005 23005 24005 25005 
     millis() = 26005 27005 28005 29005 30005 31005 32005...
    Last edited by mjs513; 06-17-2017 at 05:46 PM. Reason: Update

  25. #25
    Visual Studio Code + Arduino plugin on OS X does not see Teensy as a board option. It sees all the other boards, and can manage and install new ones by invoking Arduino CLI, but Teensy is not available.

    It's not important, as I can still use the Arduino IDE to compile+build. But since with VS Code you can configure each window with a separate target/port, I found it useful.

    Arduino 1.8.2

Posting Permissions

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