Teensyduino 1.37 Beta #3

[KurtE]

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

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]

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]

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]

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]

@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

[PaulStoffregen]

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.

[PaulStoffregen]

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

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]

I just set it to 2.5 seconds. Hopefully that will be enough for most Windows systems.

[mjs513]

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]

1.37-beta4 is now available. Closing this thread.

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