Teensyduino 1.54 Beta #5

Status
Not open for further replies.
Hi

not sure if this is known issue, or not - I upgraded to BigSur on Macbook pro 2018
When i run the installer I get Screenshot 2020-12-08 at 15.50.12.jpg

I recently started using VS Code with the Arduino expansion, but I have not been using Teensy in the projects up to now, but I now need Teensy and ran into this issue.
...So you can perhaps just stop me if the VSCode+Teensy will work or not.

I started with root and tried some command line hacks , If I click around the grey area I hit some buttons, at least cancel ;

- Benni
 
I have noticed an issue where using a microSD over SPI is now at reduced speed and performance in Teensyduino 1.54 Beta 5.

While using Teensy 4.0 with Audio Shield Adapter with 1.54 Beta 5, I noticed that some of my sketches had a significantly reduced speed/performance.

After running the "SDCardTest" here were my results (Teensy 4.0 with Audio Shield Adapter):

Teensyduino 1.51
Code:
SD Card Test
------------
SD card is connected :-)
Card type is SDHC
File system space is 15466.05 Mbytes.
SD library is able to access the filesystem

Reading SDTEST1.WAV:
  [COLOR="#008000"]Overall speed = 1.67 Mbyte/sec[/COLOR]
  Worst block time = 0.72 ms
    24.78% of audio frame time

Reading SDTEST1.WAV & SDTEST2.WAV:
  [COLOR="#008000"]Overall speed = 1.51 Mbyte/sec[/COLOR]
  Worst block time = 1.34 ms
    46.15% of audio frame time

Reading SDTEST1.WAV & SDTEST2.WAV staggered:
  [COLOR="#008000"]Overall speed = 1.51 Mbyte/sec[/COLOR]
  Worst block time = 1.02 ms
    35.02% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV:
  [COLOR="#008000"]Overall speed = 1.49 Mbyte/sec[/COLOR]
  Worst block time = 1.98 ms
    68.35% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV staggered:
  [COLOR="#008000"]Overall speed = 1.50 Mbyte/sec[/COLOR]
  Worst block time = 1.59 ms
    54.80% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV, SDTEST4.WAV:
  [COLOR="#008000"]Overall speed = 1.49 Mbyte/sec[/COLOR]
  Worst block time = 2.59 ms
    89.17% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV, SDTEST4.WAV staggered:
  [COLOR="#008000"]Overall speed = 1.49 Mbyte/sec[/COLOR]
  Worst block time = 1.64 ms
    56.42% of audio frame time

Teensyduino 1.53
Code:
SD Card Test
------------
File system space is 15466.05 Mbytes.
SD library is able to access the filesystem

Reading SDTEST1.WAV:
  [COLOR="#008000"]Overall speed = 1.63 Mbyte/sec[/COLOR]
  Worst block time = 0.74 ms
    25.33% of audio frame time

Reading SDTEST1.WAV & SDTEST2.WAV:
  [COLOR="#008000"]Overall speed = 1.48 Mbyte/sec[/COLOR]
  Worst block time = 1.35 ms
    46.67% of audio frame time

Reading SDTEST1.WAV & SDTEST2.WAV staggered:
  [COLOR="#008000"]Overall speed = 1.48 Mbyte/sec[/COLOR]
  Worst block time = 1.00 ms
    34.33% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV:
  [COLOR="#008000"]Overall speed = 1.46 Mbyte/sec[/COLOR]
  Worst block time = 1.97 ms
    68.04% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV staggered:
  [COLOR="#008000"]Overall speed = 1.46 Mbyte/sec[/COLOR]
  Worst block time = 1.33 ms
    45.84% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV, SDTEST4.WAV:
  [COLOR="#008000"]Overall speed = 1.46 Mbyte/sec[/COLOR]
  Worst block time = 2.65 ms
    91.41% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV, SDTEST4.WAV staggered:
  [COLOR="#008000"]Overall speed = 1.46 Mbyte/sec[/COLOR]
  Worst block time = 1.68 ms
    57.87% of audio frame time

Teensyduino 1.54 Beta 5
Code:
SD Card Test
------------
SD card is connected :-)
Card type is SDHC
File system space is 15466.05 Mbytes.
SD library is able to access the filesystem

Reading SDTEST1.WAV:
  [COLOR="#FF0000"]Overall speed = 1.01 Mbyte/sec[/COLOR]
  Worst block time = 0.99 ms
    33.98% of audio frame time

Reading SDTEST1.WAV & SDTEST2.WAV:
  [COLOR="#FF0000"]Overall speed = 0.89 Mbyte/sec[/COLOR]
  Worst block time = 2.59 ms
    89.27% of audio frame time

Reading SDTEST1.WAV & SDTEST2.WAV staggered:
  [COLOR="#FF0000"]Overall speed = 0.89 Mbyte/sec[/COLOR]
  Worst block time = 2.14 ms
    73.79% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV:
  [COLOR="#FF0000"]Overall speed = 0.89 Mbyte/sec[/COLOR]
  Worst block time = 3.57 ms
    123.01% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV staggered:
  [COLOR="#FF0000"]Overall speed = 0.89 Mbyte/sec[/COLOR]
  Worst block time = 2.74 ms
    94.37% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV, SDTEST4.WAV:
  [COLOR="#FF0000"]Overall speed = 0.87 Mbyte/sec[/COLOR]
  Worst block time = 4.84 ms
    166.82% of audio frame time

Reading SDTEST1.WAV, SDTEST2.WAV, SDTEST3.WAV, SDTEST4.WAV staggered:
  [COLOR="#FF0000"]Overall speed = 0.90 Mbyte/sec[/COLOR]
  Worst block time = 2.97 ms
    102.37% of audio frame time
 
An other question:
https://github.com/PaulStoffregen/SPI/blob/master/SPI.h#L1236
Code:
    uint8_t transfer(uint8_t data) {
        // TODO: check for space in fifo?
        port().TDR = data;
        while (1) {
            uint32_t fifo = (port().FSR >> 16) & 0x1F;
            if (fifo > 0) return port().RDR;
        }
        //port().SR = SPI_SR_TCF;
        //port().PUSHR = data;
        //while (!(port().SR & SPI_SR_TCF)) ; // wait
        //return port().POPR;
    }
Why is the check for free space in the queue still missing?
From my understanding, this can lead to serious errors, esp with foreign code that does not use the block transfer functions.
Just assume very slow SPI (khz Range).

I'm asking here, because this is so obvious (too obvious) that I must assume I miss something.
Otherwise I'd already done a PR...

Edit:
Oh, it waits for an incomming byte.. so this never fills the fifo... :) think before post..
 
Last edited:
Mine is even slower.. 0.82MB/s for a single file (T4 + Audioshield, Sandisk Ultra 16GB, formatted with official tool)
That's a serious regression.
Any Idea what happened?
 
GCC 10 says:
Code:
"C:\\Arduino\\hardware\\teensy/../tools/arm10/bin/arm-none-eabi-g++" -c -O2 -g -Wall -ffunction-sections -fdata-sections -nostdlib -MMD -std=gnu++14 -fexceptions -fpermissive -fno-rtti -fno-threadsafe-statics -felide-constructors -Wno-error=narrowing -mthumb -mcpu=cortex-m7 -mfloat-abi=hard -mfpu=fpv5-d16 -D__IMXRT1062__ -DTEENSYDUINO=154 -DLOG_LEVEL=0 -DARDUINO=10813 -DARDUINO_TEENSY40 -DF_CPU=816000000 -DUSB_SERIAL -DLAYOUT_US_ENGLISH "-Ie:\\temp\\arduino_build_966437/pch" "-IC:\\Arduino\\hardware\\teensy\\avr\\cores\\teensy4" "-IC:\\Arduino\\hardware\\teensy\\avr\\libraries\\SD\\src" "-IC:\\Arduino\\hardware\\teensy\\avr\\libraries\\SdFat\\src" "-IC:\\Arduino\\hardware\\teensy\\avr\\libraries\\SPI" "e:\\temp\\arduino_build_966437\\sketch\\SdCardTest.ino.cpp" -o "e:\\temp\\arduino_build_966437\\sketch\\SdCardTest.ino.cpp.o"
In file included from C:\Arduino\hardware\teensy\avr\libraries\SdFat\src/SdCard/SdSpiCard.h:35,
                 from C:\Arduino\hardware\teensy\avr\libraries\SdFat\src/SdCard/SdCard.h:28,
                 from C:\Arduino\hardware\teensy\avr\libraries\SdFat\src/SdFat.h:32,
                 from C:\Arduino\hardware\teensy\avr\libraries\SD\src/SD.h:27,
                 from C:\Arduino\hardware\teensy\avr\libraries\Audio\examples\HardwareTesting\SD_Card\SdCardTest\SdCardTest.ino:15:
SdCardTest: In function 'void setup()':
c:\arduino\hardware\teensy\avr\libraries\sdfat\src\spidriver\sdspidriver.h:49:38: [COLOR=#ff0000]warning: conversion from 'long unsigned int' to 'uint8_t' {aka 'unsigned char'} changes value from '50000000' to '128' [-Woverflow]
   49 | #define SD_SCK_MHZ(maxMhz) (1000000UL*(maxMhz))[/COLOR]
      |                            ~~~~~~~~~~^~~~~~~~~~
c:\arduino\hardware\teensy\avr\libraries\sdfat\src\spidriver\sdspidriver.h:52:24: note: in expansion of macro 'SD_SCK_MHZ'
   52 | #define SPI_FULL_SPEED SD_SCK_MHZ(50)
      |                        ^~~~~~~~~~
C:\Arduino\hardware\teensy\avr\libraries\Audio\examples\HardwareTesting\SD_Card\SdCardTest\SdCardTest.ino:57:22: note: in expansion of macro 'SPI_FULL_SPEED'
   57 |   status = card.init(SPI_FULL_SPEED, SDCARD_CS_PIN);
      |                      ^~~~~~~~~~~~~~
Compiling libraries...
 
One explanation could be that with transition to FS.h and SdFat_V2 the configuration must be (re)considered.
 
One explanation could be that with transition to FS.h and SdFat_V2 the configuration must be (re)considered.

Looks like ist just uses the SPI library.
I have my instruments in the cellar(still) - can you measure the SPI clock?
 
sd.h:
Code:
#define SD_CARD_TYPE_SD1 0
#define SD_CARD_TYPE_SD2 1
#define SD_CARD_TYPE_SDHC 3
class Sd2Card
{
public:
    bool init(uint8_t speed, uint8_t csPin) {
        return SD.begin(csPin);
    }
I'd change that to bool init(uint32_t speed, uint8_t csPin)
...and as speed seems to be ignored anyway, i'd mark it deprecated (with the correspronding gcc attribute) and add a new bool init(uint8_t csPin).
This is more tranparent for the user(and me ;) ), too, as it don't makes him think "Oh, I can adjust the speed"

@Paul, do you want a PR?
 
not sure if it is my installation or something else... the GCC-9 linker gets confused by SdCardTest example:
Code:
e:\temp\arduino_build_729709\libraries\SD\[COLOR=#ff0000]SD.cpp[/COLOR].o:(.ARM.extab.text._ZN7SDClass4openEPKch[_ZN7SDClass4openEPKch]+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/arduino/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
e:\temp\arduino_build_729709\libraries\SD\SD.cpp.o:(.ARM.exidx.text._ZN7SDClass4openEPKch[_ZN7SDClass4openEPKch]+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZN7SDClass4openEPKch'
e:\temp\arduino_build_729709\sketch\[COLOR=#ff0000]SdCardTest.ino[/COLOR].cpp.o:(.ARM.extab.text._ZN6SDFile12openNextFileEh[_ZN6SDFile12openNextFileEh]+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/arduino/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
e:\temp\arduino_build_729709\sketch\SdCardTest.ino.cpp.o:(.ARM.exidx.text._ZN6SDFile12openNextFileEh[_ZN6SDFile12openNextFileEh]+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZN6SDFile12openNextFileEh'
e:\temp\arduino_build_729709\sketch\SdCardTest.ino.cpp.o:(.ARM.extab.text._ZN6SDFileD0Ev[_ZN6SDFileD5Ev]+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/arduino/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
e:\temp\arduino_build_729709\sketch\SdCardTest.ino.cpp.o:(.ARM.exidx.text._ZN6SDFileD0Ev[_ZN6SDFileD5Ev]+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZN6SDFileD0Ev'
e:\temp\arduino_build_729709\sketch\SdCardTest.ino.cpp.o:(.ARM.extab.text._ZN6SDFileD2Ev[_ZN6SDFileD5Ev]+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/arduino/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
e:\temp\arduino_build_729709\sketch\SdCardTest.ino.cpp.o:(.ARM.exidx.text._ZN6SDFileD2Ev[_ZN6SDFileD5Ev]+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text._ZN6SDFileD2Ev'
e:\temp\arduino_build_729709\sketch\SdCardTest.ino.cpp.o:(.ARM.extab.text.setup+0x0): relocation truncated to fit: R_ARM_PREL31 against symbol `__gxx_personality_v0' defined in .text.__gxx_personality_v0 section in c:/arduino/hardware/tools/arm9/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+dp/hard\libstdc++.a(eh_personality.o)
e:\temp\arduino_build_729709\sketch\SdCardTest.ino.cpp.o:(.ARM.exidx.text.setup+0x4): relocation truncated to fit: R_ARM_PREL31 against `.ARM.extab.text.setup'
e:\temp\arduino_build_729709\libraries\SdFat\FatLib\FatFileLFN.cpp.o:(.ARM.exidx.text._ZN7FatFile4openEPS_P7fname_ti+0x4): additional relocation overflows omitted from the output
collect2.exe: error: ld returned 1 exit status
 
can you measure the SPI clock?
running the program (SdCardTest) on T4.0+AudioCard SPI clock is 16 MHz with 0.19 us between bytes

Yes, that is set in SD
BUT you can override this with SD.sdfs.begin(...)
That is why sdfs is public in FS
 
Yes, that is set in SD
BUT you can override this with SD.sdfs.begin(...)
That is why sdfs is public in FS

That does not help much...
A) nobody (including me) knows that
B) the examples do not use it
C) the existing libraries do not use it.


It is a bit strange that it does not use a higher Speed by default.
Everything in Arduino is made for beginners-we do not even have the simplest "recompile" or the possibility to set project defines.. and on the other hand this beginner gets a slow SD without any warning or hints how to solve that :) this is not intuitive. we really should change this :)

You just can't give the user a slow SD on the fastest Microcontroller..

Even if this means to wait with this update.
 
Last edited:
...if the 50MHZ is too high, ok, then we have to write a speed-test that tests the max possible, reliable speed (can run on init() ) and uses that for SD.
 
It is a bit strange that it does not use a higher Speed by default.

I had the default at 24 MHz. Then during testing 16 MHz was suggested, maybe for certain non-PJRC hardware. Maybe we should put it back higher again?

I believe the SD card spec says 25 MHz is the official limit for SPI, though that is from memory.... should probably look it up.
 
I had the default at 24 MHz. Then during testing 16 MHz was suggested, maybe for certain non-PJRC hardware. Maybe we should put it back higher again?

I believe the SD card spec says 25 MHz is the official limit for SPI, though that is from memory.... should probably look it up.

Consequently, you would then have to make it so slow that those awful adapters with level-shifters work.
I don't think that's a good argument.
You shouldn't make your hardware slower to support bad 3rd party adapters.
But that's just my opinion.

In addition you disturb existing programs with it, which depend on higher speed - which did exist. So you introduce a new incompatibility.
I would not do that :)
 
My memory says, all SDHC cards support 50MHz.. but have to look it up, too.. :)

(And now I'll try to find my scope and LA... and try to find the reason for the 190ns gaps)
 
By default I think it should be the same speed as the last Teensyduino release...
Which I believe was:
Code:
#define SD_SPI_SPEED  SPISettings(25000000, MSBFIRST, SPI_MODE0)

It will be interesting to see how many compatibility issues we run into with the FS.h introduction and differences in things like File Open options.
 
There is more than speed on SPI performance
here are the three cases as I see them
Code:
  status = SD.begin(SDCARD_CS_PIN); // 0.92 MB/s - 0.91 Mb/s
//  status = SD.sdfs.begin(SdSpiConfig(SDCARD_CS_PIN, SHARED_SPI, 50'000'000)); // 1.36 Mb/s - 1.35 MB/s
//  status = SD.sdfs.begin(SdSpiConfig(SDCARD_CS_PIN, DEDICATED_SPI, 50'000'000)); // 5.18 Mb/s - 1.35 MB/s
(first speed number single file access, second number multiple file access)

Apart from the discussion what should be the default speed: speed that works always, or speed someone is used to,
switching from shared_spi to dedicated spi increases speed by a factor of 4,
switching between files may reduce the effective speed significantly.
Anyhow I appreciate the fact that I can bypass SD.begin
 
(And now I'll try to find my scope and LA... and try to find the reason for the 190ns gaps)
The reason for the gaps is this:
Code:
_ccr = LPSPI_CCR_SCKDIV(div)  [COLOR=#ff0000][B]| LPSPI_CCR_DBT(div/2) | LPSPI_CCR_PCSSCK(div/2)[/B][/COLOR];
I have not enough experience with SPI-Hardware. I guess we can reduce "DBT" and "PCSSCK", or make it const - not "div" dependend - but that should do someone with more experience.
However, it has only a small impact.
 
I see the same speedup.
What is different with "DEDICATED_SPI"?
I could be wrong, but I only find it in the library SdFs....

If I remember correctly @WMXZ mentioned it recently as a possible extension to one or more of our libraries, where you more or less say that the SD is the only thing on the SPI buss and as such, you can avoid calling beginTransaction and endTransaction.
 
What is different with "DEDICATED_SPI"?

Bill explained (at least as I recall) that is leaves the card in a state where you're still making a multi-block access even your code isn't really accessing the card. It gives a huge improvement in sequential access for a single file, when that file is stored sequentially on the media.

However, it might negatively impact random access performance or accessing multiple files.
 
AFAIK, DEDICATED_SPI effectively does not call begin and end transaction.
@FrankB a change from 1.36 MHz to 5.18 MHz is indeed a a major improvement from SHARED_SPI to DEDICATED_SPI
 
Status
Not open for further replies.
Back
Top