Teensyduino 1.37 Beta #3

Status
Not open for further replies.

Paul

Administrator
Staff member
Here is a third beta test for Teensyduino 1.37.


Old beta download links removed. Please use the latest version:
https://www.pjrc.com/teensy/td_download.html


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
 
I assume they are being uploaded now as system not finding them.

Edit: This time windows one was found...
 
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...
 
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.
 
1.37 beta 1 changes list included gnu11, I thought that was already done in 1.36. Did I misunderstand ?
 
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.
 
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".)
 
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?
 
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.

sc.png

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?
 
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.
 
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:
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.
 
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 = SPI.transfer(buf);

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
 
I tried just now, but couldn't reproduce the problem.

View attachment 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.
 
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 = SPI.transfer(buf);

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.
 
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.
 
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.
 
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());
  }
}
 
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.

sc.png

Admittedly this is a very old Mac, running 10.7.5. I could go get a test machine with Sierra if needed...
 
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?
 
Yes, it does, or at least it's supposed to do so:

https://github.com/PaulStoffregen/cores/blob/master/teensy3/usb_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.
 
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::
gray_Teensy.png

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;
      [U][B]Serial.print("\n millis() now ++ =");[/B][/U]
      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:
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:
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
 
Status
Not open for further replies.
Back
Top