PDA

View Full Version : Teensyduino 1.37 Beta #3



Paul
06-15-2017, 03:16 PM
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 (https://forum.pjrc.com/threads/44596-Teensyduino-1-37-Beta-2-(Arduino-1-8-3-support))

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

KurtE
06-15-2017, 03:19 PM
I assume they are being uploaded now as system not finding them.

Edit: This time windows one was found...

PaulStoffregen
06-15-2017, 03:21 PM
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...

mjs513
06-15-2017, 04:58 PM
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.

DaQue
06-15-2017, 07:09 PM
1.37 beta 1 changes list included gnu11, I thought that was already done in 1.36. Did I misunderstand ?

KurtE
06-16-2017, 02:31 AM
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.

hubbe
06-16-2017, 05:45 AM
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".)

hubbe
06-16-2017, 06:31 AM
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?

PaulStoffregen
06-16-2017, 12:16 PM
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.

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?

PaulStoffregen
06-16-2017, 12:27 PM
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.

mjs513
06-16-2017, 12:35 PM
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.

mjs513
06-16-2017, 01:33 PM
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.

KurtE
06-16-2017, 02:10 PM
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

hubbe
06-16-2017, 04:10 PM
I tried just now, but couldn't reproduce the problem.

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.

hubbe
06-16-2017, 05:48 PM
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.

hubbe
06-17-2017, 03:29 AM
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.

hubbe
06-17-2017, 03:45 AM
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.

defragster
06-17-2017, 11:32 AM
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:


void setup() {
Serial.begin(57600);
if ( Serial ) {
Serial.print("\n >>>>>>>>>>>> setup() millis() now ="); Serial.println(millis());
}
}

PaulStoffregen
06-17-2017, 11:46 AM
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/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?

PaulStoffregen
06-17-2017, 11:51 AM
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.

10826

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

PaulStoffregen
06-17-2017, 11:58 AM
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:



//#define USE_TEENSY3_OPTIMIZED_CODE


Does that make any difference?

defragster
06-17-2017, 03:26 PM
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.

defragster
06-17-2017, 04:29 PM
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::
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



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

mjs513
06-17-2017, 05:18 PM
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:


>>>>>>>>>>>> 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:


>>>>>>>>>>>> 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...

Laur
06-17-2017, 05:29 PM
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

KurtE
06-17-2017, 05:48 PM
@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

hubbe
06-17-2017, 05:52 PM
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:



//#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.

hubbe
06-17-2017, 06:25 PM
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:


SPCR.enable_pins(); // pins managed by SPCRemulation in avr_emulation.h


The new code says:


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.

defragster
06-17-2017, 08:32 PM
Thanks - I was on a T_3.6 BTW - but I think the issue is Win 10 Latest Creators Update 1703 version . . . #.1358


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:


>>>>>>>>>>>> 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:


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

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

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

KurtE
06-17-2017, 10:02 PM
The difference is the drive strength.

The difference is in SPI.begin(), the old code says:


SPCR.enable_pins(); // pins managed by SPCRemulation in avr_emulation.h


The new code says:


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)...

KurtE
06-18-2017, 12:06 AM
@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/ENABLE_PCR_DSE-on-enable-pins

PaulStoffregen
06-18-2017, 11:20 AM
Closed TyComm and opened IDE 1.8.3 and it shows 'teensy' grayed?? - can't test against IDE SerMon::
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.

10838

PaulStoffregen
06-18-2017, 11:31 AM
>>>>>>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().

mjs513
06-18-2017, 12:23 PM
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

PaulStoffregen
06-18-2017, 12:36 PM
I just set it to 2.5 seconds. Hopefully that will be enough for most Windows systems.

mjs513
06-18-2017, 12:42 PM
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:

>>>>>>>>>>>> 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

Paul
06-18-2017, 01:25 PM
1.37-beta4 is now available. Closing this thread.

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