Embedded w/ either SD Memory or CompactFlash

Can anyone point me to a good resource on interfacing either SD Memory or CompactFlash to embedded processors? We're an 8051-shop mostly. Either C or Assembler, preference is Assembler.

I need to attach a huge lookup table, on the order of 16GB, maybe even

32GB. Speed is not that critical (I think - I haven't run the math yet)... My preference is to try to do this in 8-bit, but if there's a better, cheaper way that doesn't involve a steep learning curve, I'm possibly up for that too.

-mpm

Reply to
mpm
Loading thread data ...

Look at Elm-ChaN's stuff.

formatting link
formatting link

Chris

Reply to
chrisgj198

formatting link
has some nice ready made modules..

formatting link
"

Reply to
Jamie

isnt compact flash just a modded ide interface?

Steve

Reply to
osr

CF can do IDE if you signal it to act that way. It can also do a couple of other interface modes.

SD does SPI, and a 4-bit variant of SPI that you need to be under NDA to use, IIRC. If you don't need the bandwidth of IDE, use SD with SPI.

Clifford Heath.

Reply to
Clifford Heath

try Mikroe basic/c/pascal compilers for AVR or PIC

bye delo

"mpm" ha scritto nel messaggio news: snipped-for-privacy@r15g2000prh.googlegroups.com...

Reply to
delo

Thanks Chris! That's exactly the sort of resource I was hoping for.

Clifford Heath mentions that SD is only avail for 4-bit without jumping through some legal hoops. I had limited my memory card selections to those I thought did not require licensing. (That's why Sony Memory Sticks are out, for example).

I now need to research whether 4-bit transfers will be too slow for the application, (probably not)?* I also need to review the cost of the connectors (SD vs. CF), as well as the memory itself.

I have to make ~ 1,500 of these devices. (At $100/ea profit). Not a bad week's worth of work!!

I'm OK with SPI as I've worked with that on several past projects and have some libraries built up.

Question to all: All things being equal, which is cheaper to provide: CF or SD? For example, when I go looking for memory card slot connectors, am I going to find SD's a 5x the price of CF, or vice-versa. Looking around the CF/SD prices look reasonably close in the capacities I need, and I'm not sure I'll be supplying these anyway(?) Just looking out for my client... Either technology looks like it will be around for the foreseeable future.

*Note: I've decided on a way to compress the data, and if I can do it without an objectionable clock-cycles hit, I can reduce the memory card requirements to roughly 1 GB.

Also, I didn't mention it, but if possible I want to keep the datafile in FAT-16 (or some other PC-writable format). That's not a dealbreaker, but it would be nice not to have to roll a SC/CF specialized programmer... I'd much rather roll some PC software to create the database file and just use Explorer to copy it to the CF / SD.

Thanks again.

-mpm

Reply to
mpm

tly.

Thanks Jamie. I will look at the Rabbit stuff. I'm not that familiar with them, and heard it was "hobby" stuff. (?) I have to make 1,500 of these and I hate warranty work - so whatever I roll needs to be pretty bulletproof.

Also, cost is a consideration, but at this volume, it might make sense to buy a module and just interface it with the rest of the project. (?) My "gut" tells me it won't be, but it's worth investigating....

Thanks,

-mpm

Reply to
mpm

Thanks for the info. I don't need the bandwidth of IDE.

I think I responded to Chris' post with an error (now that I re-read your post). So, SD just uses standard SPI, and the 4-bit version has the hoops. Am I correct in assuming that the non-4-bit version has better throughput?

Also, I'll want to write these SD cards through Windows (PC). I assume that's no problem with the standard SPI mode.?

Thanks,

-mpm

Reply to
mpm

SD is just the SPI, CF is a bunch of parallel ports configurable to 8 or

16 bit. If you don't have a need for a compatible file system over flash, then the interface is simple.

Something tells me that there should be much better approach. Can you tell what are you actually trying to accomplish?

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

Of course the 4 bit interface has more throughput.

Has nothing to do with the SPI Mode, AFAIK.

I would do it this way: Write a prepared file with fixed name and lenght to a fresh and empty card (they come formatted as FAT12 or FAT16) with Windows. On your 8051: Implement a simple routine to search step by step through the boot-sector, FAT and directory to check for existence and to get the beginning (absolute address) of the file. It is better to place a unique byte-sequence at the beginning and check it to be shure you got the right address.

With this offset address you can access your LUT (beginning at byte #1 of the file) by simple adding.

Take a look at the SD-specs for the commands, up to now I have used only commands for complete sectors (512Byte), which may be not possible in your 8051 due to limited RAM. There are commmands for sequenced reading too if my memory is right.

Important: If you need to replace the file on the card always delete it before you write the new one, don't allow windows to create a recycle bin folder or something. The file may not be fragmented.

If necessary do not try to format the card in Windows file manager, there are special Programs for that purpose. You can use disk-editor software for formatting too (must be capable to access sector 0 on flash cards): Make a backup copy of the first sectors (from real sector 0 to the end of the file system) from a fresh new card. If needed, just write it back. Don't use such images on other card brands with the same capacity, there might be differences.

Jörg.

Reply to
=?UTF-8?B?SsO2cmcgU2NobmVpZGU=

ndows.

he boot-sector, FAT and

ss) of the file.

t

the file)

commands

e to limited RAM.

efore you write

ing.

the file system)

might be differences.

All good info. Thanks!! I had not really though through all the FAT issues. Originally, I was just going to use the physical memory address as the counter for the location, but as you correctly indicate, you cannot rely on Windows to put the data where you want it.

But as it turns out, this is a nice benefit. What I will now do is bust-up the data in "chucks" and assign those chucks in an index of sorts. The data I'm storing is actually rather agreeable to that sort of lookup. I was going to do this anyway to save processor cycles, but now instead of jumping to specific memory location, I can just load the "file" instead, and search though that file only for the data I want. Just as simple on the embedded end - MUCH simpler on the Windows (program/update) end.!!

Also, (and I'm not sure of this yet), allowing Windows to write the SD card might take care of writes to any bad memory bytes on the SD? If my data is corrupted on read, or if read fails, its not the end of the world, but if improved robustness is a consequence of allowing Windows to "relocate" the data, all the more reason to do it that way.

Frankly, the ability to update the product by changing out the SD card pretty much mandates Windows - unless I want to build a bunch of specialized SD programmers too. No thanks...

-mpm

Reply to
mpm

tly.

math yet)...

Sorry Vladimir, We're under a pretty strict NDA on this project.... :(

I agree there are lots of ways to handle large data arrays with 8-bit processors. I thnk we've pretty much got an approach that will do the job.

-mpm

Reply to
mpm

Well, you may rely on Windows if you take care about the mentioned things and use always the same Windows version and card-adaptor. But you can not rely on that cards with a specific capacity, even if its the same brand are always from the same manufacturer and have always the exact (physical) position of the file. Therefore it is better to implement some code to look at a few specific locations on the card to find the file, it also helps to rule out damaged or corrupted cards.

I have done it this way: Read CID with command "9" to check for sector size=512Byte (You can get additional information like SDC/MMC, card size etc. from the CID)

Read sector 0, offset 01C6h (4byte long), this value is the sector where the Bootrecord starts, multiplied with the sector size gives you the absolute address for the BR. Keep this value as "Sect_BR", it is used later.

In this sector at offset 36h check for a five byte string whith the ASCII-coded characters "FAT" followed by the string "12" or "16" describing the FAT-type.

If everything fits you can read a few important parameters at different offsets of the same sector:

SectorsPerCluster=1Byte at 0Dh Nr_ReservedSectors=2Bytes at 0Eh Nr_FATs=1 Byte at 010h Nr_RootEntrys=2Bytes at 011h Sect_perFAT=2Bytes at 016h

Tot_SectPar=2Bytes at 013h If this value reads 0 it means that the filesystems has more than 65535 sectors, in this case you have to take Tot_SectPar=4Bytes at 020h

Then you can calculate the start and end of the directory: Dir_EntryLen=32 SectorSize=512

SectBeginDir = Sect_BR+Nr_ReservedSectors+NR_FATs*Sect_perFAT SectENDDir = SectNrBeginDir+(Nr_RootEntrys*Dir_EntryLen)/SectorSize

This is the area to search for your known file name, the best way to search it would be from address SectBeginDir*SectorSize to SectBeginDir*SectorSize in increments of Dir_EntryLen. If you have found your file name and in case you named your counting variable for the search "N" (incremented by 32 for every step) read the following values from the directory: dirFileStart= 2Bytes at offset 01Ah+N dirFileSize= 4Bytes at offset 01Ch+N

Then you get the start- and end-sector of your file by this calculation:

FileStart_Sect=SectNrENDDir+(dirFileStart-2)*Sect_perCluster FileEnd_Sect =FileStart_Sect+dirFileSize/SectorSize

For the absolute address just multiply by SectorSize.

There is more information about FAT in Wikipedia.

The handling of bad sectors happens completely on the card, neither Windows nor your embedded system needs to take care about that. Bad sectors are saved in reserved sectors and then remapped by the card. But depending on how critical the data is, I would build in some checks as checksums or the like. One should not rely on the internal handling It has a disadvantage too: If you want to write to the card with your embedded system you can have unexpected delays due to the internal error-handling, no problem if there is enough time to wait.

In your case -write once, read often- this (and power loss during write operations) should not be a problem.

For wider temperature range and/or more write cycles there are industrial- grade cards around, but I have not seen connectors yet that are more shock- or vibration resistant.

By the way: There are two modes of SPI-communication, one with CRC and one without.

I use SD-cards for logging and firmware updates in embedded systems. Be prepared that not every customer is able to put an e-mailed file on a card in the right way (or the other way round), sometimes you have to send a prepaired card per real mail and tell the customer to _not_ use the card in any other device or any other card in the delivered system.

Jörg.

Reply to
=?UTF-8?B?SsO2cmcgU2NobmVpZGU=

stuff.http://elm-chan.org/docs/mmc/mmc_e.htmlhttp://elm-chan.org/fsw/ff/00index_e.html

Step up to fat32, nearly universally portable now. Fat16 dies at around 500 MB. All of my big memory sticks are fat32.

Reply to
JosephKK

Windows.

boot-sector, FAT and

of the file.

file)

commands

limited RAM.

before you write

file system)

might be differences.

Why should that be? All of my (USB) multicard reader / writers work flawlessly in Linux and FreeBSD.

Reply to
JosephKK

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.