|
|
| Line 1: |
Line 1: |
|
| |
|
| ==Memory card types==
| |
| {{notes}}
| |
|
| |
|
|
| |
|
| For different kinds of memory cards, see [[Common plugs and connectors#Memory_cards]]
| | ==On fake flash== |
| | |
| | |
| ===Secure Digital (SD, miniSD, microSD), and MMC details=== | |
| {{stub}} | | {{stub}} |
|
| |
|
| | Fake flash refers to a scam where cards's controller reports a larger size than the actual storage has. |
|
| |
|
| '''Capacity types / families'''
| |
|
| |
|
| * SD (now named SDSC, 'standard capacity', to distinguish it)
| | These seem to come in roughly two variants: |
| ** size (somewhat artificially) limited to 1-4GB
| | : addressing storage that isn't there will fail, |
| | : or it will wrap back on itself and write in existing area. |
|
| |
|
| * SDHC (high capacity), since approx 2006
| | ...which isn't an important distinction, in that the result is just that it appears to be broken. |
| ** physically identical but conforming to a new standard that allows for higher capacity and speed.
| | It will seem to work for a little while, and in both cases it will corrupt later. |
| ** adressing limited to 32GB
| |
|
| |
|
| * SDXC (eXtended-Capacity), since approx 2009
| |
| ** successor to SDHC that allows for higher capacity and speed
| |
| ** UHS was introduced since roughly then. Note that only ''some'' cards use UHS.
| |
| ** adressing limited to 2TB
| |
|
| |
|
| * Ultra-Capacity (SDUC), since approx 2018
| | There are some tools to detect fake flash. You can e.g. read out what flash memory chips are in there and whether that adds up. |
| ** limited to 128TB
| | Scammers don't go so far to fake this. |
|
| |
|
| * SDIO
| | But the more thorough check is a write-and-verify test, see below. |
| ** allows more arbitrary communication, basically a way to plug in specific accessories ''on supporting hosts'' - not really an arbitrarily usable bus for consumers
| |
| ** (supports devices like GPS, wired and wireless networking)
| |
|
| |
|
| | ==Memory card health== |
| | {{stub}} |
|
| |
|
| | While memory cards and USB sticks are flash memory much like SSDs, |
| | most lack all wear leveling and health introspection. |
|
| |
|
| | | So you should assume that they will fail completely, without warning. |
| The above is partly about capacity, and partly about function.
| |
| It's also not entirely aligned with SD versions,
| |
| protocolwise it's even more interesting,
| |
| particularly with the extra buses for the faster (UHS and Express) modes.
| |
| | |
| I think most people have list track of the details by now.
| |
| | |
| | |
| | |
| | |
| | |
| | |
| '''Electrically'''
| |
| | |
| Power is 3.3V, though there are some lower-voltage details - in particular the LVDS being lower voltage (1.8V{{verify}}).
| |
| | |
| (MMC had 7 pins)
| |
| | |
| SD has 9 pins before up until UHS-II
| |
| | |
| SD with UHS-II adds 8 pins for a total of 17 pins
| |
| : two more [https://en.wikipedia.org/wiki/Low-voltage_differential_signaling LVDS] pairs, and more power and ground
| |
|
| |
|
|
| |
|
| MicroSD has 8 pins <!--(which is one less than SD, but it's just one less ground pin)-->
| | At lower level, even if they are still completely readable (and that's not a guarantee), |
| | filesystems are not made to deal with write failure, so you may need |
| | special tools and/or a technical friend for recovery. |
|
| |
|
| MicroSD with UHS-II has 17 pins
| |
|
| |
|
| | You can check whether it's still readable (non-destructive) with test consisting of "read all disk surface" {{comment|(for chkdsk it's the 'scan for an attempt recovery of bad sectors" checkbox)}} |
|
| |
|
| | The only real test of whether it's fully writable is to write to all of it (necessarily destructive). |
| | But this only proves that it hasn't failed already, not that it won't soon. |
|
| |
|
|
| |
|
| '''Protocol (and DIY options)'''
| | One useful tool is {{search|H2testw}}, |
| | which creates a file in free space (if empty, then almost all the SD card) |
|
| |
|
| Since there are a a few card types and more transfer modes over the years,
| | It will also tell you ''actual'' average write and read speed, not the potential lie on the front. |
| supporting all the possible things a card can do is fairly involved.
| |
|
| |
|
| Even detecting what kind of card is there is interesting.
| | And implicitly be a fake flash test. |
| You'ld think this is part of negotiation, but for historical reasons
| |
| you need some fallback logic even in the initialisation commands.
| |
| | |
| | |
| Since you're talking to the flash controller, there is a minimal mode, namely to start talking SPI.
| |
| | |
| There are a handful of protocol variations, that are basically negotiated from the most basic one.
| |
| Any fancy device ''will'' want to do that for speed, but for DIY that choice of SPI is much simpler.
| |
| {{comment|(note there are some recent cards where SPI mode is optional, though{{verify}})}}
| |
| | |
| In SPI mode the pins are mostly just SPI's MOSI, MISO, SCLK, select, and ground, and Vcc.
| |
| | |
| Code-wise, you'll want to find a library. If you don't, you'll probably end up writing much of one anyway.
| |
|
| |
|
| | ==What's stored== |
| <!-- | | <!-- |
| See e.g. https://electronics.stackexchange.com/questions/77417/what-is-the-correct-command-sequence-for-microsd-card-initialization-in-spi
| |
|
| |
|
| {{comment|(Arduino's Sd2Card.cpp seems to follow that part of the spec well. Its type 1 and 2 refers to SDSC version 1.x and "2.0 or later". Larger capacity can be seen as part of "2 or later" or as their own thing{{verify}})}}
| | Embedded flash will often contain a bootloader, and store image types according. |
|
| |
|
| Frankly, you want to be using a library anyway,
| | e.g. on linux you'll see |
| because if you don't you'll probably end up writing much of one anyway.
| | (e.g. uBoot, looks for uImage, which itself is mostly just a wrapper, and created by mkimage) |
| | SquashFS (for rootfs), JFFS2 (for storage), and others. |
|
| |
|
| Also, in DIY you generally won't get any of the faster modes, not without some planning.
| | http://www.isysop.com/unpacking-and-repacking-u-boot-uimage-files/ |
|
| |
|
|
| |
|
| | And some special cases, such as that SPIFFS was used on [[ESP]] [https://github.com/pellepl/spiffs] [https://tttapa.github.io/ESP8266/Chap11%20-%20SPIFFS.html], later switched to LittleFS[https://arduino-esp8266.readthedocs.io/en/latest/filesystem.html]. |
|
| |
|
| MMC 1.0 ~ 3
| |
|
| |
|
| MMC 4 to 4.3
| |
|
| |
|
| MMC 4.4
| | Portable USB things will often be FAT32, NTFS, or exFAT |
|
| |
|
| | They are often unpartitioned. |
|
| |
|
| SD version 1.0 ~ 1.01
| | You can partition it, but windows will only detect the first partition, and built-in windows tools won't be the one to create such a partitioning. (this seems to have changed in Win10) |
|
| |
|
| SD version 1.1 ~ 2.0
| | It seems this is behaviour tied to it being marked as removable or not. But this is not recommended as it'll buffer a lot more and leave it much more likely to leave the filesystem in a bad state. |
| : SDHC introduced in 2?
| |
|
| |
|
| SD version 3
| |
| : SDXC introduced in 3?
| |
|
| |
|
| | Linux will often treat it as any other disk. |
|
| |
|
| https://www.sdcard.org/downloads/pls/index.html
| |
|
| |
| http://uditagarwal.in/index.php/2018/03/17/understanding-sd-sdio-and-mmc-interface/
| |
|
| |
| https://www.sdcard.org/downloads/pls/simplified_specs/archive/part1_301.pdf
| |
|
| |
| http://elm-chan.org/docs/mmc/mmc_e.html
| |
|
| |
| -->
| |
| <!--
| |
|
| |
| '''Formatting'''
| |
|
| |
| SD cards are often partitioned{{verify}},
| |
| typically MBR style, though are also seen partitionless using the entire block device for a filesystem.
| |
|
| |
| Most tools will default to partition to a single FAT32 partition,
| |
| because that's best supported all around, but some things need more flexibility.
| |
|
| |
| For example the typical setup for raspberry Pi has a mix of partitions, mostly for practical reasons.
| |
|
| |
|
| |
| Earlier SD cards often come formatted as FAT32 (and small ones occasionally FAT16 or FAT12 {{verify}}), larger and later variants as exFAT, for size reasons
| |
|
| |
| There is no special status to this, it's just the likely default (and OS support) of the times in which they first appeared.
| |
|
| |
| -->
| |
|
| |
| ====SD Speed rating====
| |
|
| |
|
| |
|
| |
| '''Actual performance'''
| |
|
| |
|
| |
| There are '''two gotchas''' to speed ratings:
| |
| * due to the nature of flash, it will read faster than it will write.
| |
| : how much faster/slower depends, but it's easily a factor 2
| |
| : if marketers can get away with it, they will specify the read speed
| |
| : note that the differences vary, due to differences in controlles. E.g. external card readers tend to be cheap shit, though there are some examples of slow
| |
|
| |
| * writes can be faster in short bursts.
| |
| : because you're actually talking to a storage controller, managing the flash
| |
| : You usually care about sustained average write instead
| |
| : And sometimes about the guaranteed speed, i.e. the minimum per second-or-so
| |
|
| |
|
| |
|
| |
| [[File:SD speed labels.jpg|thumb|400px|right|This tells us it's a UHS-I card, it's video class 10, UHS class 1, and speed class 10]]
| |
| Marking-wise
| |
| * '''Speed class''' - looks like a circle with a number in it - one of 2, 4, 6, or 10
| |
| : (and a class 0, which doesn't specify performance so is meaningless)
| |
| : tyhat figure is which is MB/s
| |
| : apparently this was intended as a minimum sustained write speed, but practice proves not everyone keeps to this, so if specs look optimistic, they probably are. It seems to vary with honesty, so a good Class 6 card may well perform better than a bad Class 10 one.
| |
| : there is no larger-than-10, no matter how much fast it actually is
| |
| : those details (and the fact that these days most SD can sustain 10MB/s) means this class system is no longer informative
| |
|
| |
| * '''Video speed class''' - V with a number, V6, V10, V30, V60, or V 90.
| |
| : again, it's just MB/s
| |
| : These were introduced because realtime-not-too-compressed HD video tends to want
| |
| :: perhaps 10MByte/s for 1080p
| |
| :: perhaps 30MByte/s for FHD
| |
| :: perhaps 60MByte/s for 4k
| |
| :: perhaps 90MByte/s for 8k
| |
| : These are apparently required to be sustained speeds{{verify}}
| |
|
| |
| * '''UHS speed class''' - looks like a U with a number in it (1, 2, or 3)
| |
| : 1 is 10MB/s
| |
| : 3 is 30MB/s
| |
| : ...so UHS speed class has very little to do with UHS version
| |
|
| |
| * Packaging may try to stunt with speed, but tend to say "up to" (possibly in tiny print)
| |
| : For example, I have a card that says writes <small>up to</small> 80MB/s and reads <small>up to</small> 170MB/s, yet all the logos on it suggest it can't guarantee sustaining more than 30MB/s. Curious...
| |
| : so assume this is marketing bullshit in general
| |
|
| |
| <!--
| |
| * Application class -
| |
| : A1: Random read at 1500 [[IOPS]], random write at 500 IOPS
| |
| : A2: Random read at 4000 IOPS, random write at 2000 IOPS
| |
| -->
| |
|
| |
|
| |
| For video, you probably want 10MB/s for standard definition, 30MB/s for 1080p, 60MB/s for 4K, and 90MB/s for 8K
| |
|
| |
|
| |
|
| |
| <!--
| |
| Some use a an '''x rating'''
| |
|
| |
| Units of 150kByte/sec (like CDs did).
| |
|
| |
| For ''some'' numeric idea, though:
| |
| * 13x is ''roughly'' equivalent to class 2
| |
| * 40x is ''roughly'' equivalent to class 6
| |
| * 66x is ''roughly'' equivalent to class 10
| |
|
| |
| * 300x is ~45MB/s
| |
| * 666x is ~100MB/s
| |
|
| |
| Apparently these are '''not required to be sustained speed ''or'' write speed'''{{verify}}, or at least practice proves not everyone keeps to this, so if it looks dubious, it probably is.
| |
|
| |
| -->
| |
|
| |
|
| |
|
| |
|
| |
| {{zzz|
| |
| '''Bus speed:'''
| |
|
| |
| Bus speed is how much the wiring can carry data.
| |
| Note this says nothing about whether the card actually will, so this is mostly unimportant
| |
|
| |
| Classically there's
| |
| * Standard
| |
| : 12MB/s max
| |
|
| |
| * High-speed - clocks SDSC and SDHC at double the rate
| |
| : 25MB/s max
| |
|
| |
|
| |
| * UHS-I
| |
| :: Introduced in version 3.01 (~2010, basically around when SDXC was introduced)
| |
| :: for SDHC and SDXC
| |
| :: one LDVS pair on the same row, ''bus speed'' specced at ~100MB/s max
| |
|
| |
| * UHS-II
| |
| :: Introduced in version 4.0 (~2011)
| |
| :: for SDHC and SDXC?
| |
| :: an extra row of eight pins: two extra LDVS pairs, and more power and ground)
| |
| :: ''bus speed'' specced at ~300MB/s max
| |
|
| |
| * UHS-III is only part of SDUC{{verify}}
| |
| :: introduced in version 6.0
| |
| :: ''bus speed'' specced at ~600MB/s max
| |
| :: Also introduced "Video Speed Class" rating
| |
| : Express, which are primarily about extra speed --
| |
|
| |
| * SD Express (introduced in version 7.0)
| |
| :: ''bus speed'' specced at ~900MB/s max
| |
|
| |
| I'm still confused about how SD Express and UHS-III relate
| |
| }}
| |
|
| |
| ====Latency====
| |
| <!--
| |
| Read latency is often in the 1ms to 2ms range (with no hard correlation to speed class).
| |
|
| |
|
| |
| Write latency is not constant, because you're actually talking to a storage controller
| |
| that typically buffers your data, and is managing flash blocks.
| |
|
| |
| Each card may act differently, and there is no direct relation to speed class.
| |
|
| |
| Writing ~1K blocks
| |
| : you can assume at least 30ms on a longer term average
| |
| :: usually many smaller, and one much longer one every so often
| |
| : on a shorter term can take anywhere from 15ms to 200ms
| |
| :: or more, but variants of the specs say ~200, 250ms, 500ms max{{verify}}
| |
| : with some outliers around 4ms and 700ms
| |
|
| |
| The same cards will tend to do better average latency for larger write sizes, up to some amount.
| |
|
| |
|
| |
| As such, things like fast continuous sensor logging
| |
| will have to be able to buffer ~0.5 second of sampling,
| |
| and sample parallel to the writing.
| |
|
| |
|
| |
|
| |
| -->
| |
| <!--
| |
|
| |
|
| https://jitter.company/blog/2019/07/31/microsd-performance-on-memory-constrained-devices/
| |
| --> | | --> |