Go Down

Topic: Maximum Capacity for microSD Card used with Arduino+SD module: 2GB or 32GB? (Read 3315 times) previous topic - next topic

card5

Hi all


Many times, when I see a microSD card module for Arduino,
the product page says "Max. card size is 2GB".
Once I also saw 4GB being mentioned.


But when searching with google for the words arduino microsd size limit,
I saw in several places 32GB being mentioned, and not 2GB.. and also not 4..


So why do the modules specify that value?
Are they incorrect?


I should mention that most microSD odules don't contain any IC on them,
they just seem to be a breakout module for the microSD card metal slot, which has SMD legs.
So thuis means that the module should not have any effect of the card Type/Capacity,
and it is all affected by the MCU, and by the Library being used.


Please help me solve this,
since the 2GB limit is problematic,
not because I need to store larger amounts of data,
but because 2GB cards (or less) are rare, and hard to find,
and even if you find them, they will be expensive because of their rarity...


Thank you

ShermanP

I can't think of a reason why the module would have anything to do with maximum size.  That would be a library limitation.  However, SD cards are 3.3V devices.  So if you are using them with a 5V Arduino, you would need to use a microSD module that has the level-shifter I/C on it and a 3.3V voltage regulator.  Even so, that has nothing to do with maximum card size.

card5

So all these modules' specifications are mostlikely wrong?

Lucario448

So why do the modules specify that value?
Are they incorrect?
Most likely because those modules aren't more than just physical and electrical adapters, there's no "brain" on those. So the controller unit is the limit.


This limit actually comes from software (library) support and SPI support on the card. For example: the SD library is compatible up to SDHC, thus up to 32 GB cards.
Although I'm not sure if SdFat handles SDXC (up to 2 TB), or even if XC cards support SPI at all.

card5

I see, thank you very much.


OK, then I can safely buy upto 32GB cards.
It's better, because the 16GB/32GB sizes are cheaper today than the old sizes of 2GB and less.

ShermanP

I don't think you'll have a problem.  I've tested an 8GB SDHC card with some of the SD example sketches, and it works fine.

card5

Great.


BTW, I read in this forum, in an old post, that SD/microSD cards have a 16KB block size.
Does this mean that If I write 1 Byte to the card, a whole 16KB block needs to be written be cause of that?

ShermanP

SD cards have a sector size of 512 or 1024 bytes, or perhaps more for XD and such, and this is defined by the card manufacturer.  16K would be the cluster size (typically 32 sectors), which is the smallest amount by which the space occupied by a file can be increased.  That's a FAT thing.  So if you create a new file, it will occupy at least one cluster.  But if you are appending data to an existing file, it will fill up the current cluster before allocating another one.  Sectors within a cluster are always consecutive.  The clusters making up a file need not be consecutive.  The File Allocation Table (FAT) is used to map the clusters in a file.


card5

Thank you for that Info.


I am aware to the sectors and clusters subjects,
but what about writing 1 byte?
Does it mean a whole block (whicever size it is) will have to be rewritten just because of it?

Lucario448

but what about writing 1 byte?
Does it mean a whole block (whicever size it is) will have to be rewritten just because of it?
Yes, but just a physical sector, not a whole filesystem-defined cluster (unless it's also set as 512 bytes). It's also because how NAND flash memories write data (page erase-program cycle).

card5

Wow, this means writing byte after byte will be both slow, and also wear out the card.


Is there maybe some article about how to optimally write to a card using Arduino and a microSD card module?

Lucario448

Is there maybe some article about how to optimally write to a card using Arduino and a microSD card module?
Both SD and SdFat already do that, and in fact is the reason why they take a good chunk of RAM. By it's function is called a "disk cache" (often wrongly called a buffer), an space in RAM used to record pending changes to a disk sector, in order to waste less time and minimize wear by saving ("flushing") big changes at once instead of small consecutive ones.

So, writting a single byte should not update immediately the physical medium, unless:

  • The library has to work with another sector (every 512 bytes).
  • flush() is called afterwards.
  • The file is closed afterwards.

One downside of this is when those changes reside only in cache and for whatever reason the system powers-off or resets; the new data will be essentially lost.
Thus, with any mass-storage medium there's always that trade-off between reliability and performance.

card5

Both SD and SdFat already do that, and in fact is the reason why they take a good chunk of RAM.
Good to know this,
thank you very much Lucario448 for such useful information - spares me the need to write it.



So, writting a single byte should not update immediately the physical medium, unless:
  • The library has to work with another sector (every 512 bytes).
  • flush() is called afterwards.
  • The file is closed afterwards.

The first one is interesting..
That's for example when the program writes in one location, and then wants to read or write from another location..
Tho for logging, this is rarely a problem.
I wonder If people who use Arduino ever stumble upon case #1
(or did you simply mean in #1 the case inwhich the buffer got full, and needs to be emptied?)


One downside of this is when those changes reside only in cache and for whatever reason the system powers-off or resets; the new data will be essentially lost.
For this reason, a wize use of .flush() is needed,
for example, after a big write() of data, and before a big delay of not writing data..
Or, before performing an operation that is "risky", in terms of potentially causing any problem that might cause a reset/power-off/etc

Lucario448

I wonder If people who use Arduino ever stumble upon case #1
(or did you simply mean in #1 the case inwhich the buffer got full, and needs to be emptied?)
Yes, and they don't even have to realize that since it happens automatically when needed.
This situation most likely occurs when logging at a relatively high rate (like above 10 Hz), or downloading a bulk of data from an external source.


For this reason, a wize use of .flush() is needed,
for example, after a big write() of data, and before a big delay of not writing data..
Or, before performing an operation that is "risky", in terms of potentially causing any problem that might cause a reset/power-off/etc
Of course, because abusing this cause degraded performance and increased wear. So that's why I've said there's a trade-off.

card5

I am curious about the Program-Erase cycles:

but what about writing 1 byte?
Does it mean a whole block (whicever size it is) will have to be rewritten just because of it?
Yes, but just a physical sector, not a whole filesystem-defined cluster (unless it's also set as 512 bytes).
It's also because how NAND flash memories write data (page erase-program cycle).
Regarding these NAND Blocks/Pages,
is the size of them always 512Bytes, in all microSD cards no matter the card's capacity?
(meaning this 512 number is defined by the manufacturer of the microSD card, in hardware)
Or is this number affected by the user somehow, for example when Formatting the card?

(from what I remember from Format programs, you can only choose the Cluster size, not the Sector size..)

Go Up