16 May
2014
16 May
'14
7:06 a.m.
On May 16, 2014, at 12:14 AM, Keith Monahan <keithvz at verizon.net> wrote:
On 5/15/2014 11:52 PM, David Riley wrote:
If you?re doing one bit, you can run in MMC mode which I believe is easier. Real SD mode,
which supports your choice of 1 or 4 bits, requires speaking a packet based I/O protocol
(think MSCP, sort of) which includes a rather complex initialization handshake. It?s all
documented, but it?s a fair amount of work.
Don't get me wrong, I think his design is
pretty great. I just
figure that's where most of the bottleneck is coming in. And,
unlike everyone else (including me), he got it out the door
instead of optimizing it to death in his head. :-)
The creator explained the bottlenecks, which seem simple enough to me:
* He's using the 1-bit interface instead of the 4-bit. (I seem to recall the 4-bit
sdcard interface has some proprietary undocumented nature to it, but that's not the
only hurdle related to using the 4-bit interface)
* He's not using the maximum frequency on the SDCARD. The current uC implementation
is driving things around 15mhz (performance numbers on his site were taken @ 18mhz, which
is why he is seeing slightly better numbers) The sdcard interface can do 25mhz.
Or 50 MHz, if it supports high speed mode, and that?s correctly implemented in both card
(usually not a problem) and controller (may be a problem). An oddity of high speed mode
is that the signalling levels are the opposite of standard speed mode (data is latched on
falling edge vs. rising edge, or the other way around).
paul