djsundog/circuitpython
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
dc8be7ccad
circuitpython/docs/library/machine.SDCard.rst

125 lines
4.8 KiB
ReStructuredText
Raw Normal View History

docs/machine: Add initial docs for new machine.SDCard class.
2019-05-31 03:04:32 -04:00
.. currentmodule:: machine
.. _machine.SDCard:
class SDCard -- secure digital memory card
==========================================
SD cards are one of the most common small form factor removable storage media.
docs/library/machine.SDCard.rst: Fix various typos.
2019-11-06 01:09:51 -05:00
SD cards come in a variety of sizes and physical form factors. MMC cards are
similar removable storage devices while eMMC devices are electrically similar
docs/machine: Add initial docs for new machine.SDCard class.
2019-05-31 03:04:32 -04:00
storage devices designed to be embedded into other systems. All three form
share a common protocol for communication with their host system and high-level
support looks the same for them all. As such in MicroPython they are implemented
in a single class called :class:`machine.SDCard` .
Both SD and MMC interfaces support being accessed with a variety of bus widths.
When being accessed with a 1-bit wide interface they can be accessed using the
SPI protocol. Different MicroPython hardware platforms support different widths
docs/library/machine.SDCard.rst: Fix various typos.
2019-11-06 01:09:51 -05:00
and pin configurations but for most platforms there is a standard configuration
for any given hardware. In general constructing an ``SDCard`` object with without
docs/machine: Add initial docs for new machine.SDCard class.
2019-05-31 03:04:32 -04:00
passing any parameters will initialise the interface to the default card slot
for the current hardware. The arguments listed below represent the common
docs/library/machine.SDCard.rst: Fix various typos.
2019-11-06 01:09:51 -05:00
arguments that might need to be set in order to use either a non-standard slot
or a non-standard pin assignment. The exact subset of arguments supported will
docs/machine: Add initial docs for new machine.SDCard class.
2019-05-31 03:04:32 -04:00
vary from platform to platform.
esp32/machine_sdcard: Add "freq" keyword arg to SDCard constructor. To allow high speed access.
2020-02-25 10:09:59 -05:00
.. class:: SDCard(slot=1, width=1, cd=None, wp=None, sck=None, miso=None, mosi=None, cs=None, freq=20000000)
docs/machine: Add initial docs for new machine.SDCard class.
2019-05-31 03:04:32 -04:00
This class provides access to SD or MMC storage cards using either
a dedicated SD/MMC interface hardware or through an SPI channel.
docs: Replace ufoo with foo in all docs. Anywhere a module is mentioned, use its "non-u" name for consistency. The "import module" vs "import umodule" is something of a FAQ, and this commit intends to help clear that up. As a first approximation MicroPython is Python, and so imports should work the same as Python and use the same name, to a first approximation. The u-version of a module is a detail that can be learned later on, when the user wants to understand more and have finer control over importing. Existing Python code should just work, as much as it is possible to do that within the constraints of embedded systems, and the MicroPython documentation should match the idiomatic way to write Python code. With universal weak links for modules (via MICROPY_MODULE_WEAK_LINKS) users can consistently use "import foo" across all ports (with the exception of the minimal ports). And the ability to override/extend via "foo.py" continues to work well. Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
2021-08-11 23:59:29 -04:00
The class implements the block protocol defined by :class:`os.AbstractBlockDev`.
docs/machine: Add initial docs for new machine.SDCard class.
2019-05-31 03:04:32 -04:00
This allows the mounting of an SD card to be as simple as::
docs: Replace ufoo with foo in all docs. Anywhere a module is mentioned, use its "non-u" name for consistency. The "import module" vs "import umodule" is something of a FAQ, and this commit intends to help clear that up. As a first approximation MicroPython is Python, and so imports should work the same as Python and use the same name, to a first approximation. The u-version of a module is a detail that can be learned later on, when the user wants to understand more and have finer control over importing. Existing Python code should just work, as much as it is possible to do that within the constraints of embedded systems, and the MicroPython documentation should match the idiomatic way to write Python code. With universal weak links for modules (via MICROPY_MODULE_WEAK_LINKS) users can consistently use "import foo" across all ports (with the exception of the minimal ports). And the ability to override/extend via "foo.py" continues to work well. Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
2021-08-11 23:59:29 -04:00
os.mount(machine.SDCard(), "/sd")
docs/machine: Add initial docs for new machine.SDCard class.
2019-05-31 03:04:32 -04:00
docs/library/machine.SDCard.rst: Fix various typos.
2019-11-06 01:09:51 -05:00
The constructor takes the following parameters:
docs/machine: Add initial docs for new machine.SDCard class.
2019-05-31 03:04:32 -04:00
- *slot* selects which of the available interfaces to use. Leaving this
unset will select the default interface.
- *width* selects the bus width for the SD/MMC interface.
- *cd* can be used to specify a card-detect pin.
- *wp* can be used to specify a write-protect pin.
- *sck* can be used to specify an SPI clock pin.
- *miso* can be used to specify an SPI miso pin.
- *mosi* can be used to specify an SPI mosi pin.
- *cs* can be used to specify an SPI chip select pin.
esp32/machine_sdcard: Add "freq" keyword arg to SDCard constructor. To allow high speed access.
2020-02-25 10:09:59 -05:00
- *freq* selects the SD/MMC interface frequency in Hz (only supported on the ESP32).
docs/machine: Add initial docs for new machine.SDCard class.
2019-05-31 03:04:32 -04:00
Implementation-specific details
-------------------------------
Different implementations of the ``SDCard`` class on different hardware support
varying subsets of the options above.
PyBoard
```````
The standard PyBoard has just one slot. No arguments are necessary or supported.
ESP32
`````
The ESP32 provides two channels of SD/MMC hardware and also supports
access to SD Cards through either of the two SPI ports that are
generally available to the user. As a result the *slot* argument can
take a value between 0 and 3, inclusive. Slots 0 and 1 use the
built-in SD/MMC hardware while slots 2 and 3 use the SPI ports. Slot 0
supports 1, 4 or 8-bit wide access while slot 1 supports 1 or 4-bit
access; the SPI slots only support 1-bit access.
.. note:: Slot 0 is used to communicate with on-board flash memory
on most ESP32 modules and so will be unavailable to the
user.
.. note:: Most ESP32 modules that provide an SD card slot using the
dedicated hardware only wire up 1 data pin, so the default
value for *width* is 1.
The pins used by the dedicated SD/MMC hardware are fixed. The pins
used by the SPI hardware can be reassigned.
.. note:: If any of the SPI signals are remapped then all of the SPI
signals will pass through a GPIO multiplexer unit which
can limit the performance of high frequency signals. Since
the normal operating speed for SD cards is 40MHz this can
cause problems on some cards.
The default (and preferred) pin assignment are as follows:
====== ====== ====== ====== ======
Slot 0 1 2 3
------ ------ ------ ------ ------
Signal Pin Pin Pin Pin
====== ====== ====== ====== ======
sck 6 14 18 14
cmd 11 15
cs 5 15
miso 19 12
mosi 23 13
D0 7 2
D1 8 4
D2 9 12
D3 10 13
D4 16
D5 17
D6 5
D7 18
====== ====== ====== ====== ======
cc3200
``````
You can set the pins used for SPI access by passing a tuple as the
*pins* argument.
*Note:* The current cc3200 SD card implementation names the this class
:class:`machine.SD` rather than :class:`machine.SDCard` .
Reference in New Issue Copy Permalink