Ok All the SD card guru's

James Long

While I've been starting a business to build the boards, all of you guys have gotten so far ahead of me, I'm lost.

I have a simple question, and want to make sure I have this right.

I want to read the directory of a SD card.

I really have no clue as to how to perform the task. I have looked at fsrw and friends, theSD Trainer, etc.

I can read a file, and write a file. I have figured that out. But when I run the sdrw test, I get nothing on the dir:

Is there a way to list file names one at a time? (like progressing to the next file name with an input?)

Any help?

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer

Lil Brother SMT Assembly Services

Post Edited (James Long) : 4/7/2009 6:41:17 AM GMT

Cluso99

There was an error in the SD_Trainer test - see the recent post (PropCMD). Then try PropCMD. It has a DIR command and shows how this is done.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Mike Green

You can also look at FemtoBasic which is in the Object Exchange. The "files" statement displays the directory. Look around line 850.

localroger

@james -- I wrote PropCMD and I'm currently in the process of rewriting fsrw. The root directory is a list of 32-byte entries which is continguous in sectors on the SD. (You do have to find the root dir, and there is some complexity to that too.) The first 11 bytes of the dir entry are the 8-char name and 3-char extension, each padded to max length with spaces. Byte 12 is the attribute byte, which PropCMD reads to sift out hidden files. The word at offset $1A is the first cluster that belongs to the file in the FAT and the last 4 bytes are the file length in bytes. The root dir nearly always contains 512 directory entries, or 32 sectors for a SD card, but you really should read that from the BIOS parameter block.

Note that most (but not all) SD cards have a partition table and they don't always put the volume in the same place. A few don't have a partition table and the first sector of the SD is the bios parameter block. FSRW checks for the latter case by looking for the "FAT16" string in sector 0 before trying to read it as a master boot record.

Bill Drummond

@james -- I wrote PropCMD and I'm currently in the process of rewriting fsrw.

Any chance you can add File Rename?

localroger

@Bill -- while I was able to hack fsrw to return the whole dir entry instead of just the name, when I tried to hack it to update the dir entry with changes I had all kinds of problems because fsrw doesn't expose any of the functionality you need to manipulate and write the metadata from an outside app. Once I rewrite fsrw I intend to implement rename, attrib, true wildcards, and full subdirectory support.

Bill Drummond

localrodger,
You da man!
OBTW multiple open files too.

Post Edited (Bill Drummond) : 4/7/2009 5:59:15 PM GMT

rokicki

By the way, lest anyone thing that was an oversight, fsrw *intentionally* does not expose that functionality, because doing so
makes it too easy to trash the card. FSRW was intended as a small, simple, but reliable way to read and write SD cards.

I have not added new features primarily due to lack of time, and I am excited to see others take up the torch. With the new
Spin compilers and conditional compilation, it should be possible to build a new fsrw with much more functionality, while not
penalizing those who don't need that additional functionality.

localroger

@rokicki -- yes, there is absolutely a place for drivers like fsrw, and for what it does it works very well. It would also be well suited to other architectures even more limited than the Prop. However I am targeting an app that will absolutely require subdirectory access, at least 4-5 files open at a time, and proper attribute manipulation, and there's really no reason not to have that functionality on the Prop. It doesn't have to be *that* dangerous, and as you say it can always be left out of the build if not needed.

For bonus points, speaking of trashing the SD, would anybody be interested in format/fdisk? It is a real pain to do anything to the MBR, and thus the partition table, in Windows, but quite easy LOL with the SD block driver.

James Long

Wow,

Thanks for all the response to my question/issue.

I know have a few different methods to "borrow" from to get what I need.

I hate to say, but programming is not my strong suit. I am a decent designer, good assembler, but come up short in the programming arena. I pretty good with the Basic Stamp, but never totally gotten my head around the Prop. I figure mainly because i haven't dedicated enough time to actual programming.

I have a project that need to be totally programmed, so the practice is coming.

I'll report back my other problems as they arise. I know I will have more.

James L

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James L
Partner/Designer

Lil Brother SMT Assembly Services

Cluso99

Just a couple of tips which took me a long time to discover.

I am reading a 1MB block to load into my SRAM on my TriBladeProp. I have an 8KB hub buffer. Since my hardware lacks enough pins I share DI/DO on the SD card with the A0/A1 on the SRAM. I had to modify the close routine in sdspiFemto to do this - see the PropCMD thread (OBC was going to update SD_Trainer in OBEX).

Initially I had to open and re-read all 8KB blocks to fine where I was up to to get the next block. So loading took about 7 minutes. I have found that the SD card next sector is available in ioControl[noparse][[/noparse]0] after the read call and so if you initially open the file and read 1 byte, ioControl[noparse][[/noparse]0] will have the next sector in it. So subtract 1 and you have the start sector. Now read using the readSDCard command. I KNOW I have 16KB clusters and the file is CONTIGUOUS. I have not yet found where the cluster size is kept. For anyone interested, this top level code is within the ZiCog code I posted on that thread last night (zicog006_demo_rr050.spin).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

localroger

@Cluso99 -- The cluster size is in the volume boot record. Here is a good resource:

http://home.teleport.com/~brainy/fat16.htm

If you look at the fsrw source you'll see that the mount command starts by loading sector 0 and checking for the "FAT16" sig at offset $36, then if it doesn't find it does some magic and loads a different sector from the long at sector 0 offset $1C6 (the pointer to the start of the volume for the first of four partitions in a MBR partition table) then in THAT sector checks for "FAT16." Once it's happy "FAT16" is there one way or the other we know it's the boot record or sector 0 of the mounted volume. Within the boot record, offset $0D is a byte giving the number of 512 byte sectors in a cluster. There's a lot of other good info in there too, it pretty much describes the whole volume structure.

I realized today that the SPIN command pretty much requires sectors to be contiguous on disk, since it depens on PASM cog code to load the RAM and it can't possibly be aware of the FAT, and if the cluster size is < 64KB that is an extremely dangerous assumption, particularly if you wrote the .bin from another system -- NO dos file system ever guarantees this even though it's considered a good strategy in some CS circles. PropCMD 2.0 will be aware of this and will check for contiguous clusters and abort smartly if things aren't right. I may even have room for a utility to contiguify a file that's been split, but I keep thinking of neat stuff to do and PropCMD 1.0 takes half the hub RAM as it is, so we'll see.

Cluso99

The default cluster size for a 2GB card under vista is 16KB, but I am recommending 32KB and that would solve your problem. I am demanding that the CPM files are contiguous (disk drive emulations), so they must be placed there straight after formatting. Not too much of an imposition.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

mctrivia

just a quick note. you asked about speed and buffering. My camera uses compact flash but similar idea just faster. It has 512MB buffer to hold photos while writing to the card. Even with that big a buffer it is still easy to fill the buffer and then I have to wait. Only takes about 25 pictures (5 seconds of rapid fire shooting)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Need to make your prop design easier or secure? Get a PropMod has crystal, eeprom, and programing header in a 40 pin dip 0.7" pitch module with uSD reader, and RTC options.