Commands to get Size of a SDCARD

[neochrome32]

I've gone dumb... can't find the info and commands needed to determine the size of an SDCARD.


I understand there's going to be multiplying stuff such as for a 2gig card. For example, I'll be multiplying the 512 sectors but just need to know HOW MANY of these sectors there are :(

Cannot remember the commands for this :(

Any help is cool

Thank you:D

[Ttelmah]

This is the CSD structure on the card.

Tells you how fast the card is, what features it has, and it's size. 'C_SIZE'.
Values of 0xEDF, 0xF03, 0xF13, 0xF1E, 0xF22, and 0xF24, for 64, 128, 256, 512, 1024, and 2048MB. There are then extended values for the V2 CSD structure.
'Card Specific Data'.

If you are using the mmcsd driver, look at the 'mmcsd_print' function, which shows how to read this, and displays the value calculated from this.

Best Wishes

[dyeatman]

A great reference is page 114 of this document:

https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

Then see page 164 CMD9 for more info...
_________________
Google and Forum Search are some of your best tools!!!!

[neochrome32]

ok getting some strange resulsts mainly all zero's...

its a problem with my code, and not yet got stuck..

this is the info i needed...

THANK YOU again :D
[edit] CODE working now...

NOW to make the OS understand this stuff...
i love this stuff... still slow :( cant get 25Mhz, when i do that, things go wrong :(
64Mhz / 4 (the highest i can get with the 64Mhz Cryst... its good enough, it just feels like using a floppy disc drive again !Lol

[neochrome32]

No, not getting it :(

i got the numbers, but for the life of me.. they just dont add up!!!

C_SIZE = 0xA5
C_SIZE_MULT = 7
READ_BL_LEN = 0x0A

this is a 2GIG card

the function

size = (C_SIZE + 1) * (512) * READ_BL_LEN+1

but the number is WRONG.. it doesn't even come close,


[EDIT]

Sorted



C_SIZE = 0EFF+1 IS (3840)
READ_BL_LEN 0x0A is (2^10 = 1024)
C_SIZE_MULT = 7 IS (2^(2+7) = 512)
//should get (2,013,265,920 bytes)
//GOT 2013265920

[temtronic]

query...

C_size is 22 bits wide, according to the PDF in the thread.

Perhaps you're not reading it back correctly?

from the same PDF file....
• C_SIZE
This parameter is used to compute the user's data card capacity (not include the security protected area). The memory capacity of the card is computed from the entries C_SIZE, C_SIZE_MULT and READ_BL_LEN as follows:
memory capacity = BLOCKNR * BLOCK_LEN
Where
BLOCKNR = (C_SIZE+1) * MULT
MULT = 2C_SIZE_MULT+2 (C_SIZE_MULT < 8)
BLOCK_LEN = 2READ_BL_LEN, (READ_BL_LEN < 12)
To indicate 2 GByte card, BLOCK_LEN shall be 1024 bytes.
Therefore, the maximal capacity that can be coded is 4096*512*1024 = 2 G bytes.
Example: A 32 Mbyte card with BLOCK_LEN = 512 can be coded by C_SIZE_MULT = 3 and C_SIZE = 2000.
The Maximum Data Area size of Standard Capacity SD Card is 4,153,344 sectors (2028MB).

me thinks 'something' you're reading isn't right...or the 'math' is wrong ..

hth
jay

[neochrome32]

yeah it was my math that was wrong, turns out my PDF reader was NOT displaying everything!!


the C_size_mult = 7

bit i didn't see the 2 squared function!

C_SIZE_MULT = (7+2) ^ 2

gave me the correct data!

also the MMSCD Print SCD info is wrong too! its trying to get data in 8 bits! NOT that 16bit i needed

have to say the SD Spec PDF is a MESS!





Thanks temtronic

[Ttelmah]

Remember MMCSD, is only built to handle the V1.0 CSD....

As a further comment, depending on how important 'time' versus 'price' is, and what size cards you might want to handle in the future, have a look at the Brush Electronics SD card drivers. These are not expensive, and run very well, supporting SD, SDHC etc.
No connection to Andrew, just a 'happy customer', who reckoned these saved far more time than trying to expand to SDHC 'DIY'....

Best Wishes

[neochrome32]

I got the drivers, but the ones i got are for the pic24... which to be fair work ...
i made adjustments to the files to work on 18f, and they DO detect cards and i can read from them all, but the FAT32 is all this pic18f has RAM/Space for so 2GIG max cards is all i really needed.

the device im working on is not really advanced.. but it IS slow :(

at 25Mhz, i am reading 2bytes from a bitmap.

using the Fat32 engine, this is rather slow too

Get this, two of the cards seem to run on clocks much higher than 25Mhz SPI mode! i dont get it since the specs say this isn't normal... its nice to see that the chip is THAT fast..

currently on ALL cards it takes 20seconds to load a file 700K to the screen :( to me this is sub floppy disc speeds :( lol

[Ttelmah]

Several conflicting statements here:

1) You talk about FAT32, and being limited to 2GB. Er. Something wrong here.
2) Unless you are throwing away the data you are reading, the odds are that a lot of the time is being used by transferring it to whatever else is receiving it.
3) There is no speed delay associated with any of the 'FAT engines', when actually transferring sectors. The file allocation size on a 2GB card, will be 32KB, so all you are doing is direct reads in 64 sector blocks. FAT only enters the equation, when moving to the next block.

I'd have a nasty suspicion that your SPI interface is actually running in software mode. Then (of course), the code has to wait for each transfer, and actual speeds will be far below what is requested.

Using the PIC18 brush drivers and transferring to USB, I can see over 1MB/second....

Best Wishes

[neochrome32]

[neochrome32]

... also, the limitations of RAM and program space,

i dont want to use any more than 2GIG.

the CARD will open up can read and write to the 8GIG stuff, BUT because of the formatting of them 1024Bytes per sector (its just too much for my poor ram) lol

the command for this is,

[Ttelmah]

Seriously, no wonder it is slow.

You are using it like a person trying to move a car, with a screwdriver. Levering it forward a quarter inch at a time. If you are transferring 565 pixels, this is the size you should be reading. If your PIC hasn't got enough RAM, then get one with more. In many cases the larger PIC's are cheaper than their older brethren now.

Then the fact that output_high, then output_low works without any delay, says that you are probably using standard_io. For speed consider using fast_io, but then add one cycle of delay between the high/low.

Then why start at 20KHz?. All cards support 400KHz minimum. Normally recommendation is for the startup data rate to be 100Khz to 400KHz.

Then 'setup_spi', allows you to change the SPI rate.

Operating at fast rates, makes the layout of the tracks to the card, and pull-ups more critical. _All_ full speed cards support 25MHz _minimum_.

Cards can support well over this. They will tell you if they go faster. This is the TRAN_SPEED value again in the CSD data, and repeated in the TPLFID_FUNCION field. This is given as the maximum rate on a single line.

This is coded as low three bits = multiplier 0=100K, 1=1M, 2=10M, 3=100M 4..7 reserved, then the next four bits are 'time value'.
Sequentially 0..15
0 not used
1, 1.2, 1.3, 1.5, 2, 2.5, 3, 3.5, 4, 4.5, 5.0, 5.5, 6, 7, 8
Top bit = 0.

So a card supporting 30Mb/sec will have 0, 7 (in four bits), then 2 (in the low three bits) = 0 0111 010 = 0x3A.

Read this and set the speed accordingly, or just use 25MHz.

Again you talk about the fat32 engine, but an SD card of 2GB or under will be formatted FAT16 by default. There is no advantage to using FAT32 if you are not going over 2GB, and it is slower (though a tiny amount compared to your way of working).

It is worth realising, that a single access to a byte in an array, will cost typically ten machine cycles+. You are asking the driver to pull two bytes out of it's buffer array, and transfer them to another, then using these to send to the LCD.

[Douglas Kennedy]

mmc/sd cards use 512 blocks..sure they can access bytes but all writes are 512 bytes. When pulling out just two bytes most since the sd card controller has a 512 page requirement expect the controller to fetch the 512 byte block....just to get the 2 bytes.
The card's controller might help out if it has logic to realize the next 2 bytes you fetch are in the same block. But why take a chance.Today's PIC's for a few pennies extra (if that)have massive ROM code space and capacious RAM
ex.PIC 24FJ256GA110 has 256k of ROM and 16k of RAM.
This allows a block of FAT32 and a block in the data area to be in RAM providing via block transfers immediate access to 128 cluster numbers and 512 bytes of data space.In the case of 16 bit pixels 256 pixels.
That's just 1k of 16k of ram and if the pixel clusters are contiguous a new cluster block only needs fetching every 128x256 pixels.

[neochrome32]

the newer chips tend to be onlu 28 legs...

i haven't found a pic 40pin Dips with 256k Rom and 32K ram... would love those,

seriously the SDcard is stored into 512 buffer, and the read function does indeed read from the same "loaded sector"

the output_low, and output_high is on fast_io due to the fact the chip is running the display too.. (well transfering data)

im pointing to the register anyways so should be even faster.

#byte porthigh = 0xF8C; // for example, latched doesn't do so well with capturing data, as i still needed these to be both in and out.

ordinarily, if the ram and space was available, it would be
16bit MPU

READCHUNK