AVR Freaks

Thanks for the quick responses,

Condemned, I will definitely try out pre-erasing sectors in advance. What sort of range do you think I should attempt to pre-erase (perhaps 25% of the card or more?). Currently my multiple block write function call issues the set_erase_wr_block commands (perhaps wrong wording there) which is CMD55-APPCMD23 which specifies the amount of blocks to pre-erase before each write, but that is only write specific, not clearing large sections of the card.

Clawson, first of all, love the signature... would have been nice to see that when I was first playing around with AVRs (had a fun run in with not setting making a flag in an ISR volatile). Yes I believe that the internal workings of the cards are proprietary information for the development company, all I really have is the good ol' Physical Layer specification document, which of course only covers interfacing, and doesn't seem to have much information on these kinds of write delays, although it does hint towards some kind of possible write issues.

Currently for my application I am essentially reading in streaming video data from a CMOS camera (at very low resolutions, as the data is coming in at 15 FPS @ 12MHz bursts) which totals to ~360 KB/s. I am using an CPLD to handle the actual data reading as the XMEGA doesn't have quick enough edge detection to handle the 12MHz data bursts. However I should have the write speeds to tackle the data rates no problem, except that during these huge write delays I will certainly overflow the buffers available on the XMEGA (we only have about 16KB of buffer available).

Yes I realize that this certainly isn't the optimum setup for handling this kind of data throughput, but this is an education oriented project and we are all learning... in a very frustrating way sometimes, but none-the-less learning.

Does anyone perhaps have suggestions on pushing the write speeds even higher? So that if we did find a way to buffer the write delays, rather than simply disregarding that data, we could clear the buffer quick enough to be ready for the next write delay?

Thanks in advance,

Josh

Clawson, currently we are using a CPLD to read the data bursts and storing them in a FIFO hardware buffer that we can clock to the MCU at our leisure, which should work out great. As it stands, 15 FPS on the camera will give the data out such that we have 96 bytes of data, followed by a ~190us delay before the next 96 byte burst. It currently takes the MCU 24us to clock the data from the FIFO buffer to the MCU so the rest of the time is purely for writing and should work out just fine (approximately 600 KB/s write speeds and only 360 KB/s incoming data). However when we get those write delays we will simply have to lose the data as it would require approximately at 60 KB or larger buffer to hold all the images that get clocked in during that time.

My wonder is what exactly these write delays are (once again refer to the above O-Scope image), is it possible they are write block gaps where the SD card is switching between different blocks of physical memory? I tried pre-erasing almost the entire card (75% or 3GB of it) and we still got the write delays so they must not be a pre-erase delay. The Physical Layer specifies that there may be delays up to 250ms during write block gaps, anyone have any insight into this? It really would be nice if the manufacturers of the card would give some spec sheets or something.

- Josh

Well, that is unfortunate that the manufacturer's don't have to meet their data throughput specifications on both interfaces, but I can understand why. So moving over to a 4-wire interface would guarantee that we would see the advertised throughputs, or at least be capable of reaching them? I guess the only other option if we don't have the time/opportunity for the hardware switch to 4-wire would be to find an SD card with a faster SPI interface... is it perhaps possible to identify the data throughputs of SD cards based on their SPI interface modes? That would be handy.

Thanks,

Josh