AVR-Chat

Anyone have an idea as to how fast an AVR can read an SD card or CF
card? Am in need of sustaining 10E6 bits/sec. At first glance this gives
me 16 clock cycles per byte at 20 MHz. This could work if the timing on
the memory card is deterministic without periodic pauses, that I don't
have to buffer in AVR memory, and have interrupts disabled.

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

On Thu, Sep 18, 2008 at 1:36 PM, David Kelly <dkelly@hiwaay.net> wrote:
> Anyone have an idea as to how fast an AVR can read an SD card or CF
> card? Am in need of sustaining 10E6 bits/sec. At first glance this gives
> me 16 clock cycles per byte at 20 MHz. This could work if the timing on
> the memory card is deterministic without periodic pauses, that I don't
> have to buffer in AVR memory, and have interrupts disabled.


Well... Define "read"..  :)

In that video project, I had to stream 30 fps to a color LCD display.
I only actually looked at 16 words of the data from the nandflash, for
the rest of it, I set up the hardware so that the low edge of the read
pin was a read pulse to the nandflash and the high edge of the same
pulse was the write to the display.  So, to do a frame, all I had to
do was cbi and sbi 20,000 times.  While that's tedious to write in
straightline code, it's blisteringly fast.

On 18 Sep 2008 at 15:07, David VanHorn wrote:

> On Thu, Sep 18, 2008 at 1:36 PM, David Kelly <dkelly@hiwaay.net>
> wrote:
> > Anyone have an idea as to how fast an AVR can read an SD card or
> CF
> > card? Am in need of sustaining 10E6 bits/sec. At first glance this
> gives
> > me 16 clock cycles per byte at 20 MHz. This could work if the
> timing on
> > the memory card is deterministic without periodic pauses, that I
> don't
> > have to buffer in AVR memory, and have interrupts disabled.
> 
> 
> Well... Define "read"..  :)
> 
> In that video project, I had to stream 30 fps to a color LCD
> display.
> I only actually looked at 16 words of the data from the nandflash,
> for
> the rest of it, I set up the hardware so that the low edge of the
> read
> pin was a read pulse to the nandflash and the high edge of the
> same
> pulse was the write to the display.  So, to do a frame, all I had
> to
> do was cbi and sbi 20,000 times.  While that's tedious to write in
> straightline code, it's blisteringly fast.
> 
> ------------------------------------


	"out PORT, reg" would be two times faster...

	Mark Jordan

>        "out PORT, reg" would be two times faster...

True..
But it was fast enough.

I had nothing else to do except the odd timer int while this was happening.

On Thu, Sep 18, 2008 at 03:07:12PM -0400, David VanHorn wrote:
> On Thu, Sep 18, 2008 at 1:36 PM, David Kelly <dkelly@hiwaay.net> wrote:
> > Anyone have an idea as to how fast an AVR can read an SD card or CF
> > card? Am in need of sustaining 10E6 bits/sec. At first glance this gives
> > me 16 clock cycles per byte at 20 MHz. This could work if the timing on
> > the memory card is deterministic without periodic pauses, that I don't
> > have to buffer in AVR memory, and have interrupts disabled.
> 
> 
> Well... Define "read"..  :)

Ideally, "read a 400 MB file sequentially from start to end, then stop."

Less ideal, sequentially read the first 400 MB off the card, raw. This
means I'll have to provide a utility for placing the data on the card.

> In that video project, I had to stream 30 fps to a color LCD display.
> I only actually looked at 16 words of the data from the nandflash, for
> the rest of it, I set up the hardware so that the low edge of the read
> pin was a read pulse to the nandflash and the high edge of the same
> pulse was the write to the display.  So, to do a frame, all I had to
> do was cbi and sbi 20,000 times.  While that's tedious to write in
> straightline code, it's blisteringly fast.

20,000 times 30 frames per second is 600,000 bytes per second. Am
thinking 600,000 * 16 * 2 bytes/word is a bit beyond advertised SD
speeds.

But back to my original question, during that read there wasn't any
period where the SD was non-responsive? The way DRAM might have wait
states during refresh?

-- 
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.

> Ideally, "read a 400 MB file sequentially from start to end, then stop."

What I'm asking is wether you need to actually READ those bytes, or
just cause them to go from one device to the other, external of the
AVR.
This might be solvable with some simple hardware.

> Less ideal, sequentially read the first 400 MB off the card, raw. This
> means I'll have to provide a utility for placing the data on the card.

I used raw data, with links between each of the frames, so that any
frame tells you the address of the next frame, and other frames that
it could branch to under certain conditions, plus the delay in mS
between this frame and the default next frame.

On Sep 18, 2008, at 6:21 PM, David VanHorn wrote:

>> Ideally, "read a 400 MB file sequentially from start to end, then  
>> stop."
>
> What I'm asking is wether you need to actually READ those bytes, or
> just cause them to go from one device to the other, external of the
> AVR.
> This might be solvable with some simple hardware.

You are asking whether I have to read *and* write the data. "No." If I  
can source a clean clock off the AVR and have a steady data stream  
coming off an SD card via SPI then the AVR doesn't have to re-write  
the data to another device. But this means there can be no pauses. The  
clock and data must never stop.

Could put a serial FIFO between the data and my output. Clock the  
output of the FIFO with a continuous 10 MHz clock. Clock the SD even  
faster while controlling chip select on the FIFO input to keep control  
information from being sent to the other device. But last time I  
checked hardware FIFO chips were not cheap. I'd be of a mind to  
upgrade my CPU and handle it there rather than add expensive or rare  
hardware.

--
David Kelly N4HHE, dkelly@HiWAAY.net
========================================================================
Whom computers would destroy, they must first drive mad.