SD read/write without slowing Teensy clock?

[PaulB]

I'm attempting to integrate a number of devices onto a Teensy 3.2 (GPS, LCD or OLED display, OBD-II reader, IMU sensor, SD card).
[I'm essentially building a "black box recorder" for my vehicle.]
I originally started this project with an Arduino Mega, but have discovered that going "round robin" polling many devices appears too much for the 16 MHz CPU.
I'm now testing/prototyping the components individually on the Teensy.
Presently, the only way I can get the SD card adapter & card to operate on the Teensy is to slow the Teensy clock to 24 MHz, which kinda defeats the purpose of making the leap from Arduino to Teensy.

Can anyone provide info on using an SD card & adapter without slowing the Teensy clock?

Thanks.

P.S. I do recognize that the quality of the adapter & card may be part of my problem (I'm currently using a "Catalex" adapter).
Does anyone have experience with using "official Teensy" SD adapters at higher Teensy clock rates? Other suggestions?

 

[tonton81]

i use teensythreads, in a dual lcd setup with many devices and dont experience slowdowns like running a single thread would endure, visually, you can see the difference with the speed of the lcds. you can prioritize tasks in other threads so the rest of your code can run without interruption

the mega was incapable of having enough resources to handle my vehicle project, so teensy 3.5 took over its place

 

[PaulStoffregen]

I'm currently using a "Catalex" adapter

Low quality SD adaptors are a well known problem. Teensy uses much faster SPI clock (default is 24 MHz) than Arduino Mega (default is 4 MHz). Many people have found low quality adaptors made for regular Arduino boards are just too slow.

Does anyone have experience with using "official Teensy" SD adapters at higher Teensy clock rates?

The ones PJRC sells work well.

Other suggestions?

With Teensy 3.2, you really just want to have the 4 signals connect directly, and the SD card can run directly from the 3.3V power pin. There's no need for any parts at all on the adaptor, just wires. Well, adding a capacitor between 3.3V to GND close to the card is a good idea, and at these high speeds you don't want the wires to be too long (a few inches is usually fine).

 

[PaulB]

Thanks to both tonton81 and Paul.
It hadn't dawned on me that multi-threading was an option (or even available!). I'll have to check that out.

Also, I will order a few PJRC adapters. In the meantime, I'd like to ask a follow-up question:
From Paul's description, it sounds like the SPI clock runs at a slower rate than the Teensy clock rate (the numeric value selected in the Arduino/Teensy IDE pull-down prior to compilation).
Is there an (understandable) relationship between the two clocks (Something like: The SPI clock rate is 1/4 the Teensy clock rate)?
Or, can the SPI clock rate be set independently of the Teensy clock rate (and if so, how)?

 

[WMXZ]

Is there an (understandable) relationship between the two clocks (Something like: The SPI clock rate is 1/4 the Teensy clock rate)?
Or, can the SPI clock rate be set independently of the Teensy clock rate (and if so, how)?

You define the desired spi speed when you initialize the spi device
(the actual speed is related to a internal bus clock call F_BUS so not all speeds are possible, check the spi.(c/h) files in cores or spi library)
(note you could have different devices running with different speed on the same spi bus)

 

[PaulStoffregen]

Is there an (understandable) relationship between the two clocks

Yes, but it's a bit complicated.

Teensy has 3 main clocks, for the CPU, peripherals and flash. The SPI runs from the peripheral clock, called F_BUS. The hardware generates F_BUS using an integer division of F_CPU, and the spec is 50 MHz max for Teensy 3.2 and 60 MHz max for Teensy 3.5 & 3.6. So when running at 72 MHz, F_BUS is 36 MHz because it needs to be less than 50 MHz, and can only be made by integer division of 72 MHz. The full list of frequencies can be found in kinetis.h.

From there, the SPI port generates its clock using integer division of F_BUS, where the fastest option is divide by 2. So when running with F_BUS at 36 MHz, the fastest possible SPI clock would be 18 MHz. When Teensy runs at 96 MHz, F_BUS is 48 MHz, which allows for 24 MHz SPI clock.

On top of all that, the SD card spec says cards are only rated to use up to 25 MHz SPI clock. So if F_BUS is 60 MHz, it will end up using only 20 MHz (divide by 3), because division by 2 would be faster than the 25 MHz max that SD cards can handle.

To make matters even more complex, on Teensy 3.5 and 3.6, the card is accessed in 4 bit parallel SDIO mode (using the built-in socket), which is 4X faster for data transfer than 1 bit SPI mode, given the same clock. Similar clock division limits apply, except the clock comes from F_CPU rather than F_BUS.

4 bit SDIO mode is much faster for moving data. But even that isn't the whole store. With either mode, the SD cards have substantial command latency. Currently the Arduino SD library always uses single sector access, which isn't optimal for card latency. Other libs like the newest sdFAT uses multi-sector access, which really reduces the effects of command latency, but requires much more memory for buffering.

 

[PaulB]

Pardon the "newbie" ... I'm unsure of the "proper etiquette" regarding whether or not the "originator of a thread" should try to "close" it.
But I thought I'd share what I've learned, and where I'm going from here:
I was unsuccessful in slowing the SPI clock, while retaining a high speed CPU clock.
After substituting a "PJRC" card adapter for the "Catalex" adapter, however, I was able to successfully read & write to an SD card with a 3.2 at 96 MHz CPU speed.
My conclusion: I will reserve my use of Catalex adapters to (16 MHz) Arduinos, and use the "good stuff" on the Teensies (Is that the plural of Teensy?
With regard to the use of TeensyThreads: I ran the library examples, and all looks good ... but I'll need more practice getting comfortable with multi-threading.
Next step is to start integrating all I've learned into upgrading my project.
Many thanks to all who helped me over this hurdle.