Searching \ for '[EE] SDHC card analysis' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/index.htm?key=sdhc+card+analysis
Search entire site for: 'SDHC card analysis'.

Exact match. Not showing close matches.
PICList Thread
'[EE] SDHC card analysis'
2011\08\29@062749 by IVP

face picon face
Hi all,

I've been reading these two pdfs

http://www.cs.ucr.edu/~amitra/sdcard/ProdManualSDCardv1.9.pdf

http://www.mikrocontroller.net/attachment/.../SDHC_SDM04G7B7_08G7B7.pdf

The first, SanDisk, says (page 3-24) that there are 20480 sectors
of 512 bytes in the protected system area. The second, Toshiba,
says (page 34) that its cards have 65536 * 512 bytes in the protected
area

I read that the MBR doesn't always start at Sector/Block 0. I'm
not wanting to use FAT with a particular test card (made by Phison
AFAICT from the CID response), just straight data storage in an
embedded environment, so I'd like to know the writable sectors of
any card I end up using for this product

The card in a reader comes up as I: on my PC, and I tried a
couple of XP utilities to try and find out which sectors are in
use after formatting, but nothing was forthcoming

Is there a utility anyone could recommend for finding out what
sectors FAT is installed in ? I *could* read the whole card a
sector at a time and log which are not FF but .......

TIA

Jo

2011\08\29@083055 by M.L.

flavicon
face
On Mon, Aug 29, 2011 at 6:27 AM, IVP <spam_OUTjoecolquittTakeThisOuTspamclear.net.nz> wrote:

> Is there a utility anyone could recommend for finding out what
> sectors FAT is installed in ? I *could* read the whole card a
> sector at a time and log which are not FF but .......
>
> TIA
>
> Joe

Joe,
When I was debugging FAT on SDHC cards I used the utility called dd
It's traditionally a Unix-like utility, but there is a Windows port that works.
I read the first several megabytes to a file and then viewed the data
in a hex editor (FRHED.) It was quite helpful to see what was going
on.


-- Martin K

2011\08\29@122754 by V G

picon face
On Mon, Aug 29, 2011 at 6:27 AM, IVP <.....joecolquittKILLspamspam@spam@clear.net.nz> wrote:

{Quote hidden}

You can use dd (Linux, Mac, Qnx, BSD, even available for winbloze) to read
pull raw binary data (of your choosing) from the card to file. Then open up
the file with a hex editor or something. dd is very easy to use

2011\08\30@060752 by IVP

face picon face
> When I was debugging FAT on SDHC cards I used the utility called
> dd. It's traditionally a Unix-like utility, but there is a Windows port
> that
> works. I read the first several megabytes to a file and then viewed the
> data in a hex editor (FRHED.) It was quite helpful to see what was
> going on

Thanks Martin. That worked out really well

Joe

2011\08\30@062547 by Nicola Perotto

picon face
Hi,

On 29/08/2011 10.27, IVP wrote:
> Hi all,
>
> I've been reading these two pdfs
>
> http://www.cs.ucr.edu/~amitra/sdcard/ProdManualSDCardv1.9.pdf
>
> http://www.mikrocontroller.net/attachment/.../SDHC_SDM04G7B7_08G7B7.pdf
>
> The first, SanDisk, says (page 3-24) that there are 20480 sectors
> of 512 bytes in the protected system area. The second, Toshiba,
> says (page 34) that its cards have 65536 * 512 bytes in the protected
> area
I think that "protected system area" is related to the "extended" functio of SD card.
The size is returned in the SD Status data block (512 bit) with command ACMD13 (CMD55 + CMD13).

>
> I read that the MBR doesn't always start at Sector/Block 0.
FALSE!
{Quote hidden}

Read sector 0, some card has MBR http://en.wikipedia.org/wiki/Master_boot_record and only 1 partition (more not alloved by specs) other has only Boot sector http://en.wikipedia.org/wiki/Fat16#Boot_Sector

My datalogger write chunks of 2MB so I wrote a library for FAT16 to find and allocate a contiguous space and to write a file descriptor in the main directory, after this I write directly to the sectors.

If you need to "fill" the card you can just allocate a single file and use some "spare" byte in the boot sector to say to firmware: first sector, size (in sector or bytes), etc

I'm curious: how many bytes/sec are you able to write?

2011\08\30@062812 by Nicola Perotto

picon face


On 30/08/2011 10.06, IVP wrote:
>> When I was debugging FAT on SDHC cards I used the utility called
>> dd. It's traditionally a Unix-like utility, but there is a Windows port
>> that
>> works. I read the first several megabytes to a file and then viewed the
>> data in a hex editor (FRHED.) It was quite helpful to see what was
>> going on
> Thanks Martin. That worked out really well
>
> Joe
>
Some hex editor can read (and write) disk directly and also display structured information.
I use Hex Workshop for this.

       Nic

2011\08\30@080759 by IVP

face picon face
part 1 2019 bytes content-type:text/plain; charset="iso-8859-1" (decoded quoted-printable)

>> I read that the MBR doesn't always start at Sector/Block 0.
> FALSE!

Yes, I now believe that is false. I've been reading WP FAT
articles and going through FHRED's display, comparing the data.
Very informative

> I think that "protected system area" is related to the "extended" function
> of SD card.
> The size is returned in the SD Status data block (512 bit) with command
> ACMD13 (CMD55 + CMD13)

The FAT entry at 0x20 for this one is 0x00760000 (7,733,288)
sectors, or 3,959,422,976 bytes total. Names for files which used to
be on the card start at 0x800000, presumably where FAT has placed
the directory. The entry at 0x0e (number of sectors before the first
FAT in the file system image) is 0x24 -> * 512 = 0x4800, and there's
a short string there (f8 ff ff f0 ff ff ff ff ff ff ff f0), in an ocean of 0's

Still reading about FAT, SDHC specs and the card controller. Maybe
0x4800 is where the card's protected area ends

> I'm curious: how many bytes/sec are you able to write?

For the single-block operation I'm trying now, 512 bytes go down to
the card in 2.4ms @ 9.8MHz, then there's ~600us Busy wait from
the card. Still at the get-it-working-then-make-it-pretty stage, and
trying to find what limitations this PIC's bugs put on the transfer rate

Each byte actually takes 900us, and I'm trying to trim the required
wait (because SPITBF is broken) after loading SPIBUF, so it should
be 1.11MB/s but presently it's only 171kB/s, including all the delays
and waits

In the attached is a write of 1 block (512 bytes) and then reading it
back twice. I notice that Nac isn't always the same. The first takes
770us, the second 480us, before receiving the 0xFE token. Still
experimenting. Shouldn't think I'll be working with single blocks too
often though, but I'm not quite at writing/reading multiple blocks to
test the timing. Most likely I'll eventually write a very simple file
system running with DMA

Joe

part 2 1106 bytes content-type:image/gif; name="write_2_read.gif" (decode)


part 3 181 bytes content-type:text/plain; name="ATT00001.txt"
(decoded base64)

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2011\08\30@094302 by Nicola Perotto

picon face


On 30/08/2011 12.06, IVP wrote:
> I've been reading WP FAT
> articles and going through FHRED's display, comparing the data.
> Very informative
Search the web for "fatgen103.doc" is a m$ doc on FAT16/32, very informative and somewhat simple!
Also in the SD card specification there is a chapter on File System specification.


{Quote hidden}

From Boot Sector to first FAT there is often a reserved area, this is NOT the "protected system area".
Thrust me: forget for now the protected area!! ;-)


{Quote hidden}

I was not able to write at more than 64KB/s, continuous.
The problem, I think, is that we write the internal SD buffer at full speed and then we must wait the real write! With only 2*512 byte buffer this is a bootleneck.


>
> Joe
>
>
      Nic

2011\08\30@135703 by M.L.

flavicon
face
On Tue, Aug 30, 2011 at 9:40 AM, Nicola Perotto <nicolaspamKILLspamnicolaperotto.it> wrote:
> I was not able to write at more than 64KB/s, continuous.
> The problem, I think, is that we write the internal SD buffer at full speed and
> then we must wait the real write! With only 2*512 byte buffer this is a bootleneck.
>

The problem with all embedded devices using SD cards is that we are
using them in SPI mode which almost never works according to the way
they say it should. And SPI mode is very very slow compared to 4-bit
wide bus that real controllers can use.

-- Martin K

2011\08\30@194716 by Harold Hallikainen

face
flavicon
face

> Some hex editor can read (and write) disk directly and also display
> structured
> information.
> I use Hex Workshop for this.
>
>         Nic

I use that too!

Harold




-- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2011\08\30@221355 by IVP

face picon face
> Search the web for "fatgen103.doc" is a m$ doc on FAT16/32, very
> informative and somewhat simple!

Thanks. A lot of it is covered in the Wikipedia FAT article

> Thrust me: forget for now the protected area!! ;-)

OK ;-) I'm not bothered at all about any FAT system on the card. I
thought that maybe the card maker had write-protected some portion
of it. Writes I've tried at low address work OK. And TBH 4GB is
an awful lot of memory so losing a few k here and there would hardly
make a difference (to me anyway). One embedded application I have
right now is speech and/or music. Around 6 1/2 hours of 44.1k 16-bit
stereo .wav will fit on a 4GB card

> I was not able to write at more than 64KB/s, continuous

For the immediate application write speed isn't too much of an issue.
I'll be copying files from a USB drive into the card, and that will just
take as long as it takes. If I have to I'll look at bit-banged 4-bit comms

> The problem, I think, is that we write the internal SD buffer at full
> speed and then we must wait the real write!

Yes, that write wait does bring the average down. I'm more interested
in the read transfer rate. Even with single sector reads, the average is
about 600us access time and 600us to fetch 512B of data, which is
around 400kB/s and that's plenty for what I'm planning. In the music
example above an average retrieval rate of ~172kB/s is sufficient

Joe

2011\08\31@045243 by alan.b.pearce

face picon face
> > I've been reading WP FAT
> > articles and going through FHRED's display, comparing the data.
> > Very informative
> Search the web for "fatgen103.doc" is a m$ doc on FAT16/32, very informative and
> somewhat simple!

It is also the Bible on FAT.


-- Scanned by iCritical.


'[EE] SDHC card analysis'
2011\09\01@044243 by Nicola Perotto
picon face


On 30/08/2011 17.56, M.L. wrote:
> On Tue, Aug 30, 2011 at 9:40 AM, Nicola Perotto<.....nicolaKILLspamspam.....nicolaperotto.it>  wrote:
>> I was not able to write at more than 64KB/s, continuous.
>> The problem, I think, is that we write the internal SD buffer at full speed and
>> then we must wait the real write! With only 2*512 byte buffer this is a bootleneck.
>>
> The problem with all embedded devices using SD cards is that we are
> using them in SPI mode which almost never works according to the way
> they say it should. And SPI mode is very very slow compared to 4-bit
> wide bus that real controllers can use.
>
I think that is only an half of the problem: the SD card controller (inside the card) write the data with his own rules and different card has different rules.
The buffering is in most cases more important that transfer speed!

2011\09\01@071151 by IVP

face picon face
> I think that is only an half of the problem: the SD card controller
> (inside the card) write the data with his own rules and different
> card has different rules. The buffering is in most cases more
> important that transfer speed!

The multi-card reader I have has a Realtek RTS5161 controller in
it. A 600MB file downloaded via USB from the HDD to the card
takes only 83 seconds, a transfer/write rate of > 7MB/s

Sometime I will put the analyser on it to see exactly how it does that.
Presumably it will be in the native 4-bit mode

Joe

2011\09\01@073334 by alan.b.pearce

face picon face
> > I think that is only an half of the problem: the SD card controller
> > (inside the card) write the data with his own rules and different
> > card has different rules. The buffering is in most cases more
> > important that transfer speed!
>
> The multi-card reader I have has a Realtek RTS5161 controller in
> it. A 600MB file downloaded via USB from the HDD to the card
> takes only 83 seconds, a transfer/write rate of > 7MB/s
>
> Sometime I will put the analyser on it to see exactly how it does that.
> Presumably it will be in the native 4-bit mode

I suspect you will also find the USB is doing 480 MB/s



-- Scanned by iCritical.

2011\09\01@075723 by IVP

face picon face
>> Sometime I will put the analyser on it to see exactly how it does
>> that. Presumably it will be in the native 4-bit mode
>
> I suspect you will also find the USB is doing 480 MB/s

No doubt. I'm just impressed that this particular Class 4 (> = 4MB/s)
card can sustain > 7MB/s writes, which is better than minimum spec
for a Class 6. JFTHOI I'd give 4-bit a go when I'm happy with SPI

Joe

2011\09\01@081501 by M.L.

flavicon
face
On Thu, Sep 1, 2011 at 7:56 AM, IVP <EraseMEjoecolquittspam_OUTspamTakeThisOuTclear.net.nz> wrote:
> No doubt. I'm just impressed that this particular Class 4 (> = 4MB/s)
> card can sustain > 7MB/s writes, which is better than minimum spec
> for a Class 6. JFTHOI I'd give 4-bit a go when I'm happy with SPI
>
> Joe

IIRC 4-bit mode isn't an open standard. I don't think it's reasonable
to achieve it without specialized hardware even if you can get the
spec.
This would probably mean you need an FPGA, or to use a microcontroller
with an SD card port. I've never seen one, myself.

-- Martin K

2011\09\01@195841 by IVP

face picon face
> IIRC 4-bit mode isn't an open standard. I don't think it's reasonable
> to achieve it without specialized hardware even if you can get the
> spec

The spec papers from http://www.sdcard.org do provide some information
which controllers *should* adhere to, so you can back-engineer to
some extent

> This would probably mean you need an FPGA, or to use a microcontroller
> with an SD card port. I've never seen one, myself.

This is probably blurring the line between microcontrollers and
microprocessors

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC5121e

I found AN3805 a few weeks ago when Googling for SDHC How-Tos.
Not useful at the time because I didn't understand enough of the basics

Jo

2011\09\06@053103 by Electron

flavicon
face
At 19.56 2011.08.30, you wrote:
>On Tue, Aug 30, 2011 at 9:40 AM, Nicola Perotto
><nicolaspamspam_OUTnicolaperotto.it> wrote:
>> I was not able to write at more than 64KB/s, continuous.
>> The problem, I think, is that we write the internal SD buffer at
>full speed and
>> then we must wait the real write! With only 2*512 byte buffer this
>is a bootleneck.
>>
>
>The problem with all embedded devices using SD cards is that we are
>using them in SPI mode which almost never works according to the way
>they say it should. And SPI mode is very very slow compared to 4-bit
>wide bus that real controllers can use.

Is it easy to bit-bang this on PICs/dsPICs/PIC32s?

>
>--
>Martin K.
>

2011\09\06@053104 by Electron

flavicon
face

Another good similar program is Win Hex.


At 01.47 2011.08.31, you wrote:
{Quote hidden}

>

2011\09\06@062852 by IVP

face picon face
> 4-bit wide bus that real controllers can use
>
> Is it easy to bit-bang this on PICs/dsPICs/PIC32s?

Assuming that have the resources to process 4-bit parallel data, you
should be able to improve on serial SPI speed

https://www.sdcard.org/developers/tech/pls/

Click 'I Accept' to get to

https://www.sdcard.org/developers/tech/sdcard/pls/simplified_specs/

Part 1, Physical Layer Simplified Specification Version 3.01 describes
the Bus Protocols in Section 3.6

Joe

2011\09\07@043925 by IVP

face picon face
>> 4-bit wide bus that real controllers can use.
>
> Is it easy to bit-bang this on PICs/dsPICs/PIC32s?

BTW, I mentioned the multi-card reader I have has a Realtek
RTS5161 controller inside. I'm sure I read that it's based on a
6502. No doubt the 5161 has fast dedicated h/w for the data
interfacing. Perhaps the 6502 is to blink the LED ;-)

Jo

2011\09\07@091618 by Harold Hallikainen

face
flavicon
face

>>> 4-bit wide bus that real controllers can use.
>>
>> Is it easy to bit-bang this on PICs/dsPICs/PIC32s?
>
> BTW, I mentioned the multi-card reader I have has a Realtek
> RTS5161 controller inside. I'm sure I read that it's based on a
> 6502. No doubt the 5161 has fast dedicated h/w for the data
> interfacing. Perhaps the 6502 is to blink the LED ;-)
>
> Joe

That reminds me of a circuit I saw many years ago. The circuit computed
logs using a Z80. It put the Z80 in the feedback of an op amp, using it as
a diode.

Harold

---
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available

2011\09\07@210557 by IVP

face picon face

> That reminds me of a circuit I saw many years ago. The circuit computed
> logs using a Z80. It put the Z80 in the feedback of an op amp, using it as
> a diode.

Ouch. That's harsh

2011\09\11@212645 by IVP

face picon face
part 1 906 bytes content-type:text/plain; charset="iso-8859-1" (decoded quoted-printable)

> I was not able to write at more than 64KB/s, continuous

My preliminary timing tests show around that figure, if using a
simple sequential UART fetch from source, SPI write to card

Attached shows typical card behaviour, which results in an
average storage of of ~ 61kbps

This is seen as 7 fast sector writes followed by 3 slow ones (a
looooong 170ms Busy), which really drags the average down. If
the writes were all as fast as each of the fast 7, the average would
go up to about 240kbps. The lower traces shows a transfer in
more detail

The simplest step to improve speed would be concurrent fetch
and write, and I've ordered dsPICs with more I/O to try 4-bit
parallel

I love to know why the card does that 7-3 thing and if / how it
can be got around. Timing patterns are consistent and repeatable.
Maybe it's just how the card works with SPI

Joe

part 2 5520 bytes content-type:image/gif; name="61kbs.gif" (decode)


part 3 181 bytes content-type:text/plain; name="ATT00001.txt"
(decoded base64)

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2011\09\12@033827 by Nicola Perotto

picon face


On 12/09/2011 1.24, IVP wrote:
>> I was not able to write at more than 64KB/s, continuous
>
> My preliminary timing tests show around that figure, if using a
> simple sequential UART fetch from source, SPI write to card
>
> Attached shows typical card behaviour, which results in an
> average storage of of ~ 61kbps
>
> This is seen as 7 fast sector writes followed by 3 slow ones (a
> looooong 170ms Busy), which really drags the average down. If
> the writes were all as fast as each of the fast 7, the average would
> go up to about 240kbps. The lower traces shows a transfer in
> more detail
It is related to the SDcard internal buffer.

>
> The simplest step to improve speed would be concurrent fetch
> and write, and I've ordered dsPICs with more I/O to try 4-bit
> parallel
I think not! You will saturate the internal buffer faster but after that you will wait 170ms...
Of course the average speed will be little better BUT if you need to store data at costant rate will be in trouble.


>
> I love to know why the card does that 7-3 thing and if / how it
> can be got around. Timing patterns are consistent and repeatable.
> Maybe it's just how the card works with SPI
I tried only SPI but different cards and the behaviour is the same only different buffer size and "wait" time (better card has smaller wait time).

>
> Joe
>
>

2011\09\12@040656 by Richard Prosser

picon face
On 12 September 2011 13:24, IVP <@spam@joecolquittKILLspamspamclear.net.nz> wrote:
{Quote hidden}

>

2011\09\12@043019 by IVP

face picon face

> Have you looked at the signals while reading/writing the card
> using a card reader & PC to see what the timing is like under
> this condition ?

On the to-do list. Nicola might have a point about the buffers
but the fact remains that a writer can sustain > 7Mbs with this
very same card

Jo

2011\09\12@052455 by IVP

face picon face
>> This is seen as 7 fast sector writes followed by 3 slow ones

> It is related to the SDcard internal buffer.

Hi Nicola. That doesn't explain to me the consistent 7 fast 3 slow
pattern. I would have expected something more regular, perhaps
not a '10' grouping. If it was 1-1, 7-1 or 15-1 maybe, more 'hex'

Jo

2011\09\12@071600 by IVP

face picon face
part 1 730 bytes content-type:text/plain; charset="iso-8859-1" (decoded quoted-printable)

> Have you looked at the signals while reading/writing the card
> using a card reader & PC to see what the timing is like under
> this condition?

Attached

CLK is 50MHz, D0-D3 are the data lines. Top traces captured at
1MHz, expanded view of two transfers captured at 200MHz. It
maintains this speed and pattern for the whole of a 200MB transfer.
It's certainly pumping the data into the card

In a 690us burst (comparable to my time for 512 bytes, with 4096
pulses at 7.4MHz SCLK) there are 34,500 CLK pulses. I don't
know what to make of that, or that there are 4 distinct transfer blocks
within an overall 7448us CLK burst, until I read up on 4-bit interfacing

Joe

part 2 8445 bytes content-type:image/gif; name="4-bit_SDHC.gif" (decode)


part 3 181 bytes content-type:text/plain; name="ATT00001.txt"
(decoded base64)

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist

2011\09\12@072012 by Nicola Perotto

picon face


On 12/09/2011 9.24, IVP wrote:
>>> This is seen as 7 fast sector writes followed by 3 slow ones
>> It is related to the SDcard internal buffer.
> Hi Nicola. That doesn't explain to me the consistent 7 fast 3 slow
> pattern. I would have expected something more regular, perhaps
> not a '10' grouping. If it was 1-1, 7-1 or 15-1 maybe, more 'hex'
>
> Joe
You are right: this is strange!
Maybe the rule says: after a time X write the sectors that are in buffer.
So changing the data rate will change the 7:3 pattern...

      Nicola

2011\09\12@120119 by Joe Wronski

flavicon
face
On 9/12/2011 5:24 AM, IVP wrote:
>>> This is seen as 7 fast sector writes followed by 3 slow onesup on th
>> It is related to the SDcard internal buffer.
> Hi Nicola. That doesn't explain to me the consistent 7 fast 3 slow
> pattern. I would have expected something more regular, perhaps
> not a '10' grouping. If it was 1-1, 7-1 or 15-1 maybe, more 'hex'
>
> Joe
I'm not at all up on this, but it might be base 2 if, for instance, there are 8 buffers and filling the 8th (high water mark) causes slow, and reducing to 4 hits a low water mark, enabling fast.  Just a BWAG.  Plus or minus some magnitude of fencepost error.
Joe W

2011\09\12@132426 by William \Chops\ Westfield

face picon face

>> I love to know why the card does that 7-3 thing

You might want to check out this thread that explains that many  utilities do not "properly" format SD for optimal access:
http://www.adafruit.com/forums/viewtopic.php?f=31&t=20861&start=0&hilit=fat16lib

BillW

2011\09\12@133031 by alan.b.pearce

face picon face
> >>> This is seen as 7 fast sector writes followed by 3 slow onesup on
> th
> >> It is related to the SDcard internal buffer.
> > Hi Nicola. That doesn't explain to me the consistent 7 fast 3 slow
> > pattern. I would have expected something more regular, perhaps
> > not a '10' grouping. If it was 1-1, 7-1 or 15-1 maybe, more 'hex'
> >
> > Joe
> I'm not at all up on this, but it might be base 2 if, for instance,
> there are 8 buffers and filling the 8th (high water mark) causes slow,
> and reducing to 4 hits a low water mark, enabling fast.  Just a BWAG.
> Plus or minus some magnitude of fencepost error.
> Joe W

It certainly sounds to me as though for the 3 slow buffer periods you are fighting the card doing its write. It may well be that the card has a very simple single buffer arrangement for the SPI interface, whereas the 4 bit parallel interface is optimised for speed (that is where the money is after all). The SPI interface may even be very old VHDL tacked on the later code just to maintain compatibility with the standard, so may not perform very fast at all.
-- Scanned by iCritical.

2011\09\12@181742 by IVP

face picon face
> http://www.adafruit.com/forums/viewtopic.php?f=31&t=20861&start=0&hilit=fat16lib

Interesting, thanks

2011\09\12@192543 by IVP

face picon face
re: buffer theories

All grist to the mill

> 4 bit parallel interface is optimised for speed (that is where the
> money is after all)

I've seen 4-bit referred to as 'native'. I think an analogy could
be '4-bit is to SPI as assembler is to BASIC'

In BillW's link, fat16lib said he was able to write audio samples
at 44k without dropping any. Unfortunately he didn't specify
whether that's 44.1k 16-bit stereo (176k4 bytes/sec). If his
write latency is a consistent ~1ms that implies, at a rough guess,
512 bytes per 2ms or 256k bytes/sec

Some smarter preparation is certainly worth looking into, even
if the maximum SPI rate is well short of 4-bit

Jo

More... (looser matching)
- Last day of these posts
- In 2011 , 2012 only
- Today
- New search...