<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">>> Ignoring the multiplicity of
standards overlaid onto SD / MMC, you can talk to all cards with a
simple SPI port; the only complication is the requirement to go
slow until a faster rate is negotiated.<br>
<br>
This is a common misunderstanding. In SPI mode there is no need
to go slow initially, you can go at full speed right away. The
need for slow speed is in SD or MMC mode where the pins are
initially open-drain in order to support multiple cards on the
same bus. In SPI mode the signaling is always push-pull and you
can clock the card at typically up to 25 MHz from the start.<br>
<br>
See Appendix A in this document
<a class="moz-txt-link-freetext" href="http://www.circlemud.org/jelson/sdcard/SDCardStandardv1.9.pdf">http://www.circlemud.org/jelson/sdcard/SDCardStandardv1.9.pdf</a><br>
<br>
<i>Timing specifications </i><i><br>
</i><i>Design engineers must meet the rise, fall, setup, hold, and
other SD Card and MultiMediaCard bus timing specifications. If
they want to support MultiMediaCards in their design, the clock
speed should be controllable by the host. This is due to the
MultiMediaCard's open-drain mode; the MultiMediaCard powers up
in the open-drain mode and cannot handle a clock faster than 400
Khz. Once the MultiMediaCard completes the initialization
process, the card switches to the push-pull mode. In the
push-pull mode the MultiMediaCard can run at the maximum clock
speed<br>
</i><br>
Magnus<br>
<br>
On 2/13/2016 11:12 AM, enso wrote:<br>
</div>
<blockquote cite="mid:56BF8025.3010903@apple2.x10.mx" type="cite">SD
cards are not entirely KISS, but close (or is it MMC that is
simple?). Well, if you read
<br>
<br>
<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/MultiMediaCard">https://en.wikipedia.org/wiki/MultiMediaCard</a>
<br>
<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/SD_cards">https://en.wikipedia.org/wiki/SD_cards</a>
<br>
<br>
you should be satisfyingly confused.
<br>
<br>
Ignoring the multiplicity of standards overlaid onto SD / MMC, you
can talk to all cards with a simple SPI port; the only
complication is the requirement to go slow until a faster rate is
negotiated. Communication is relatively simple once you figure out
a consistent way to initialize the card (that works for all the
different brands), mostly reading and writing fixed-size
'sectors'.
<br>
<br>
Unlike USB and HDMI, you can use a few FPGA pins directly
connected to the port and no proprietary 'black boxes'.
<br>
<br>
Like VGA and PS/2, these are from a simpler time, before
businesses blindly followed the Jobsian obfuscation requirements
to keep 'consumers' from 'looking under the hood' or 'knowing what
they want'.
<br>
<br>
On 02/13/2016 05:55 AM, eas lab wrote:
<br>
<blockquote type="cite">Yes SDs are magically cost-effective.
<br>
And the problem about finite-life and <even wearing> seems
not relevant.
<br>
I guess they don't have the monsterous software requirement
problem that
<br>
USB has, since they don't need to ID what class of USB they are.
<br>
Another example of KISS ?
<br>
<br>
Does any of the ETHO documentation describe the SD driver, down
to the
<br>
register level?
<br>
<br>
== Chris Glur.
<br>
--
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related
systems
<br>
<a class="moz-txt-link-freetext" href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
<br>
<br>
</blockquote>
<br>
--
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related
systems
<br>
<a class="moz-txt-link-freetext" href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
<br>
<br>
</blockquote>
<br>
</body>
</html>