Teensy 3 MicroSD guide

Status
Not open for further replies.
Very true. For datalogger design did last year, gave up on the non-deterministic response to lo-pwr mode commands for the various peripheral ICs so used logic-level FETs as series power switches to turn various stuff on/off as needed. The only code-monkeying left to do was controlling lo-pwr modes for the T3.1 itself and buffering blocks of data for burst writes. Sometimes the shortest route is to just do it in hardware.

BTW, most of my uSD block writes consumed approx 155 mA peak. Those little memory cards are piggies.
 
BTW, most of my uSD block writes consumed approx 155 mA peak. Those little memory cards are piggies.

Wow. Thank you for measuring. I'm on the verge of adding a dedicated power supply just for the uSD! :)

The good news is that the TLV70233 I like to use is good for 300mA, assuming I've done my homework right. Should leave ample for the uSD, esp. in conjunction with decoupling caps at 0.1, 10, and 47uF nearby.
 
Last edited:
Busy with work last couple of day's
Seen all the mails and really appreciate the info!

Had some spare time this evening and removed the Teensy SD card reader.
Replaced it with a SD to uSD plastic adapter card which I got with a new uSD card.

No more errors in my sketch
Logged NMEA data from my GPS

SdFormatter and SdInfo are working
Formatted 2, 4, 16 and 32GB cards

For the time being I can use my proto device and I will order a new Teensy card reader.

More info/feedback in August when I return from my holiday:cool:
 
Hi Paul,
Is there a way to use the SD adaptor or the TEENSY3_AUDIO adaptor + W25Q128FV device to increase code space? I am looking for min 2MB of code space.

Thanks in advance
 
That's a lot of code space; what is it for? There may be a better solution than a solitary Teensy.
 
Hi Cosford,
I am planning to use the code space for video processing. Prefer to have video routines, some of which require local memory for processing. Perhaps, SD is not the appropriate type ... may be more DRAM? But DRAM requires too many interface pins..Still trying to figure out anoptimum way to do that (SD - slow, DRAM-fast.. etc)

Thanks
 
I would imagine if you are doing video processing, it is better to do it on a machine with much more memory, hardware floating point, a faster clock rate, and probably a dedicated graphics processor (GPU). A Raspberry Pi 2.0, Beagle Bone Black, or pcDunio might be easier to handle video than a Teensy. If you need real time processing, then consider doing the real time stuff in the Teensy and the video stuff on the Pi/BBB/etc. You would use some sort of communication between the two parts (serial uart, i2c, spi, etc.).

Even without the code limitations, a Teensy 3.1 can only store maybe 8 frames of 1080p video (1920 x 1080 x 3 bytes is 5-6 megabytes) in read/write memory.
 
Hi Paul,
Is there a way to use the SD adaptor or the TEENSY3_AUDIO adaptor + W25Q128FV device to increase code space? I am looking for min 2MB of code space.

Thanks in advance

The only way would be to copy small parts to the ram and execute there. This is not very practical...
 
Last edited:
I'm confused. The request says "increase code space", but then talks about needing "local memory for processing" video.

There seems to be a lack of info about the video data, whether it's live real-time streaming or stored on media, whether real-time or offline processing is to be done, or even what that processing might be, or what sort of format, resolution, frame rate and compression is used. Lack of such details really takes away any sort of context which could allow better understanding of this memory request.

In general, I'd agree with MichaelMeissner, that with today's technology, single-board computers like Beaglebone and Raspberry Pi are much better for most video processing. In a few years, as microcontrollers start moving to smaller than 90 nm transistors and superscaler processor cores like Cortex-M7, real-time video processing will become much more feasible.
 
Busy with work last couple of day's
Seen all the mails and really appreciate the info!

Had some spare time this evening and removed the Teensy SD card reader.
Replaced it with a SD to uSD plastic adapter card which I got with a new uSD card.

No more errors in my sketch
Logged NMEA data from my GPS

SdFormatter and SdInfo are working
Formatted 2, 4, 16 and 32GB cards

For the time being I can use my proto device and I will order a new Teensy card reader.

More info/feedback in August when I return from my holiday:cool:

Just to inform everybody I could not fix the Teensy SD reader issue... despite the fact I ordered a new one.
I also ordered a Sparkfun SD reader to test and it works like a charm.
So somewhere in my design there is something different with the two boards.

As this is a prototype design I will leave it as-is, my final design will have an "insert brand here" push-push slot directly on the pcb. ;)
 
Hello, I'm meeting up a problem with micro SD,
with SD library from arduino, 1.6.5 , teensy loader 1.25 beta-2, and teensy 3.1
example->SD->listfile.ino
with chip select set to pin 10, (as I use 10,11,12,13 for the pins)
it seems like if I switch the setting to more than 24Mhz I got a "initialization failed!"
clock equal or lower than 24Mhz, i got my files printed out fine
and however teensy LC works properly with 48MHz clock.

Then I tried on SdFat library, with the similar file lister.
example->SD->OpenNext.ino
found that it worked properly with sd.begin(chipSelect, SPI_HALF_SPEED)
and everything went wrong with sd.begin(chipSelect, SPI_FULL_SPEED) && Clock above 24Mhz

and with the bench example (i didnt get any read speed, seems the example ino was different than the previous of this thread)
I get the results (KB/Sec,usec,usec,usec) 251.04,97473,1074,2030 on both teensy 3.1 and LC( with the clock setting as high as it could)
which were pretty close or slighty faster than other results at previous of the thread

so I have to ask: is this due to the limit speed of the microSD card(with SPI?) , or are there any faster library exist?
 
Oh yes... I'm not sure what I was thinking....2MB/Sec is still plenty fast for my application.

Thanks for the additional information... I'll give it a try later tonight
 
Status
Not open for further replies.
Back
Top