SD Card SPI Interface

[GlenJ]

Hi All,
I'm new to ZBasic and ZX processors, but have had a bit of experience with PICAXE chips in several previous projects.
The ZBasic system looks very impressive and I'd really like to get an SD Card data logger system setup using the ZX40.
I've read through most of the previous discussions on SD/MMC card interfacing, and have picked up some of the suggested circuits for using the hardware SPI interface to talk to the SD card.
I've decided to adapt the circuit put forward by Tony, but use a 74HC125 to do the interfacing, and have assembled it as shown in the attached file.
However, I'm uncertain about writing interfacing code to talk to/from the SD Card, and would appreciate your responses to the following queries:
1. Does the card have to be formated FAT32? If I just use the card 'as is', will it still read/write information?
2. If the card is FAT32 formatted, are there any particular writing/reading formats/idiosyncracies required to access the data?
2. How does memory addressing work using the SPICmd with the SD Card? If I wanted to read/write a byte to memory location 282,697, how would I structure the SPICmd?
3. What setting up preambles are required to get the card ready for SPI mode and receiving/sending data (reading the Sandisk SD Card specifications, it seems the SD Card wakes up in SD communication mode, and requires a specific reset sequence to change over to SPI mode)?
4. Does the SPICmd automatically parse multibyte variables when reading/writing to the SD Card? Eg. if I write a sequence of values having Single data format (ie. 4 byte values), will SPICmd automatically save them in sets of 4 consecutive bytes to the SD Card, and conversely, read them back into multibyte variables? Or do the variables have to be manually deconstructed/reconstructed before saving them to the SDCard?
5. It seems that maximum storage density occurs when data is saved to the SD Card in 512 byte sectors. It seems this would be best accomplished by defining a vector (1D array) with 512 byte elements, or a 512 byte length queue, and loading these structures with variables until they (the vector or queue) are full, and then saving the contents of the structure to the SD Card. Is this realistic, or is there a better way to do it?
Your help appreciated.
Cheers, Glen

[dkinzer]

4. Does the SPICmd automatically parse multibyte variables when reading/writing to the SD Card?

SPICmd() doesn't know anything about data types. Rather, it reads and writes sequences of bytes. If you are reading and writing 512 byte sectors, it is likely that you will be using a 512 byte buffer (Byte array) and writing the code that packs data into and unpacks data from that buffer. The BlockMove() or MemCopy() subroutines can be used for this purpose or you could use Based variables to get the same effect although the latter may be more complicated than you would want to tackle initially.

Note, particularly, that handling String types is more complicated than handling integral, Boolean and Single types. The simplest solution may be to employ a BoundedString type as an intermediary between the SD buffer array and the String data.

Section 3.23 of the ZBasic Language manual describes how the various types are implemented internally, i.e., how the constituent bytes of each type are used.

[victorf]

I know this sounds heretical, but have a look at:

http://www.sparkfun.com/commerce/produc ... cts_id=752

The work is done for you and all you need to do is send your data to it. SD too!

Vic

[dkinzer]

I know this sounds heretical[...]

Not at all. Buy vs. build is always a legitimate point of discussion.

[spamiam]

The card does NOT need to be formatted into any "format". You wil be doing low level access with random access to each sector.

However, If you understand FAT32, you can write to the card according to FAT guidlines. If you do, then you can share the data to a PC. But it is probably just as easy to keep trach of your own "FAT" and communicate to external devices by some protocol (I2C, Serial, etc)

You do need to write specific stuff to the card to set up SPI mode. The files in the "Files" section show how to do it.

-Tony

[victorf]

OK. how about DOS commands and FAT16/32? check this one out:

http://www.sparkfun.com/commerce/produc ... ts_id=7955

SD, SPI/serial. Yup! All for 40 bucks.

Vic

[GlenJ]

Hi All,
I'm clearly amongst a group of experts. Thanks very much for your helpful and detailed suggestions.

Vic, I've checked out your suggested interface products at Sparkfun, and they look pretty interesting, particularly the interface module that uses the DOSOnChip IC. This chip is actually available (http://chipdos.com) on its own, with some quoted figures of USD5 per chip. I've sent off a request for a quotation from them. Will let you know what the response is.
Another similar chip seems to be the uALFAT (pron. 'micro ALFAT') at GHI Electronics (http://www.ghielectronics.com/). I've also asked them for a quote.

Don, thanks for the clarification on the SPICmd usage. I guess I'm still not clear on how to reference specific addresses on an SPI device using SPICmd. It seems that SPICmd arguments WriteCnt and ReadCnt just tell the command how many bytes from the respective variables WriteData and ReadData to read/write on the SPI device. Where it writes/reads them on the SPI device doesn't seem obvious.

Tony, I've had a look through the Forum Files section, and note one in November 2006 re. the SD/MMC interface circuit, but this doesn't reference any info on instruction sequences for setting up and communicating with the card.
You also have an SD/MMC Interface API back in January 2006, but looking through this it seems adapted to your bit-banged interface rather than using the SPICmd and hardware SPI interface. Am I missing something, or do I need to study your Jan. 06 API more closely?
Thanks again for help everybody.
Cheers,
Glen

[dkinzer]

[...]I'm still not clear on how to reference specific addresses on an SPI device using SPICmd. It seems that SPICmd arguments WriteCnt and ReadCnt just tell the command how many bytes from the respective variables WriteData and ReadData to read/write on the SPI device. Where it writes/reads them on the SPI device doesn't seem obvious.

It is true that the address does not appear anywhere in the parameters provided to SPICmd(). That's because the SPI protocol does not require the use of addresses of any type. Some SPI devices have a single data element that can be read and written while others have many thousands.

Each SPI device defines its own set of commands and also defines the order and meaning of the data bytes that it sends and receives. As an example, consider the AT26256A SPI EEPROM. In order to read data from it you send it three bytes: a read command and a two-byte address. In order to read the first byte at that address, you then send it another byte whose value is completely ignored and the device returns the data byte. (Note that the sending and receiving actually occur simultaneously.) You can read additional sequential bytes by simply sending additional "don't care" bytes and reading what the device returns. You can read the entire EEPROM like this if you wish because the internal address value wraps to zero when the end is reached. Otherwise, you terminate the cycle by deasserting the chip select. A write cycle begins similarly but you send actual data bytes and ignore the returned data. One added wrinkle is that you must deselect the device at page boundaries (each device defines its own page size), wait for the write process to complete, and then start a new cycle if you want to continue writing. (An added complexity is that you have to send the device a "write enable" command before beginning the write sequence.)

So, in order to use any particular SPI device with SPICmd() you must first read its datasheet to find out what commands and data you must send it and how it will respond. With that information, you can determine what and how many data bytes to put in the array before invoking SPICmd().

[spamiam]

Hi All,
You also have an SD/MMC Interface API back in January 2006, but looking through this it seems adapted to your bit-banged interface rather than using the SPICmd and hardware SPI interface. Am I missing something, or do I need to study your Jan. 06 API more closely?
Thanks again for help everybody.
Cheers,
Glen

Well, there are 2 levels of abstraction. One is for the bit banging specifically. Just how to get the bits in and out.

The higher level is what data is to be sent (by whatever method). This IS in the API.

The parts you need to look at are the parts around CMD0 and CMD1.

You have to do some very specific stuff with specific timing to get the card working.

Also, if you check Google, you will find fairly generic recipes for what needs to be sent and returned when initializing the card.

-Tony

[GlenJ]

Hi All,
Don, Thanks for your clear descriptions of the SPI workings. I've got a better understanding now and will look at how I can apply this to the SD Card issue.
Tony, I'll study your API more closely. Thanks for pointing me to the appropriate parts.
I've also had a closer look at those SD Card interface chips from GHI Electronics and DOSOnChip. The GHI chips are USD14.00 (excl. postage), and DOSOnChip say they only sell direct for orders of 100 or more. For smaller orders, they've referred me to Spark Fun Electronics, and indeed they list the chips alone at USD11.95. I've put an order in for 3 of them, and will make a posting when I've got them and tried them out.
Cheers,
Glen