Thanks to Mike Cook I was able to remedy the problem he was having with a specific card. So I am releasing
fsrw-and-friends 1.3 at http://tomas.rokicki.com/fat16work/ for everyone. With the new sdspiqasm driver, it
is somewhat faster, but nothing dramatic; with a pretty ordinary card I was able to get 428K bytes/second
reads and 304K bytes/second writes. Cheaper cards tend to be somewhat slower on writes (perhaps 150K
bytes/second is about the slowest I've seen). I think a high-quality card will be faster. But this is still pretty
quick. For comparison, my in-spin routines read at about 3.3K bytes/second and wrote at 2.8K bytes/second.
If someone *really* needs something faster, let me know. I have yet another version that has attained
491K bytes/second reading (again, this is through the file system, not just raw block I/O) and can probably
push it higher than this, but in order to do this I had to make it somewhat bigger.
Unless I hear about bugs or problems, I'm probably going to let this stuff stay as it is for a while so I can work
on other things. If you have additional features you need for a particular project, please let me know what
they are and how important they are. There's a lot that can be done, and fairly easily too, such as
subdirectory support, renaming, more than one file open at a time, etc., but I think the functionality we
currently have is pretty good, especially for the code size. With the new functionality I need to figure out
how to support multiple versions at the same time (because I don't want to bloat the base code just to add
some features not everyone needs).
Hi,
First I must say rokicki·has done a great job with the SD-Card code and it's very helpfull for me to have you all writing in this forum. I hope I will have som to contribute with in the future, as for now I'm a newbie to the prop chip.
Got some old SD cards which are not the secure ones, i.e they don't have the sam number of pins.
Now my question, is it possible to use or are there any changes needed in rokicki code.
Would be nice to use these old cards.
I have tried them with no luck, the newer card (secure ones) work OK with rokicki code.
Anyone how have a fix would be apreciated.
Hope my spelling· isn't to bad.
Regards Goran (Sweden)
The older cards are called MMC cards and they're different from SD cards and require a somewhat different driver. It's possible to make a driver that will handle both, but it would be significantly bigger.
Has anybody tried this with a MicroSD card?
I jumped the gun and baught one whith hopes to put together a tiny propeller-in-my-pocket system or a propeller pilot.
For those of you looking for a cheap option for a SD connector Up All Night Robotics has instructions on how to make one from a PC floppy drive edge connector.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I stand on the shoulders of giants
Funny you should mention that paul, I just made one this weekend. Paperclip and a coathanger... I'm gonna try the SD demo after I send this to see if I wired it up correctly! Wish me luck...
Didn't work... I had to rearrange the pin assignments in the routines to match that of my board (I unwittingly use the SPI pin order of CLK,Din,Dout,CS0,CS1,CS2... starting at "basepin" of which my basepin is 8). Not fully convinced about my hardware yet. Gotta sleep now, will debug tomorrow...
Try as I might (and I have searched), I can't find what values are recommended for the pullup resistors connecting the SD card, and what lines they are recommended to be connected to.· I might be able to figure this out with more research; however, there appear to be some folks with cards already hooked up, and pullup resistors are included in the circuit.· I just can't tell what the values are, and where they are connected.· Can someone give me a tip?
There is magic (read: *stupid*) code in there that assumes the pins are in a specific order (specifically, the
initialization of the dira register). (This is sdspi.spin, which is what I recommend you start with; make the
change in fsrw.spin). The bad code is:
outa := -1
dira[noparse][[/noparse]clk..cs] := 7
The first statement sets all four pins high (but it also clobbers any *other* pins that particular spin program
may happen to have set for output, which is bad). Then, the dira[noparse][[/noparse]...] command assumes clk..cs are the
three pins that need to be set to output, which may not be the case. (For instance, if clk=0 and cs=31,
you've just raised every pin on the chip.)
I'll fix these, and make some other minor improvements, tonight. Once I've done that it will be much easier
to change pin assignments.
On the pullup resistors: the SanDisk reference says between 10K and 100K; pull up every line that is
conceivably undriven (see the circuit diagram at the top of sdspiqasm.spin); there should be six lines
pulled up. I used 20K.
BTW I pulled up Clk even though many references don't have it pulled up. I did this because if the
Prop hasn't started using the card yet, that pin is still floating. I hate floating inputs; I'm always afraid
they'll pick up random noise and cause all sorts of random mucky muck inside the CMOS circuits.
If anyone has any troubles making the routines work, *please* let me know.
I'd be leery of the paper-clip hack; I'm not sure what sort of contact a paper clip is going to make.
I don't know if that metal will have surface oxides that don't conduct that well, or if the springiness
will provide sufficient contact pressure, or that the paper clips may actually provide too much pressure
and break something inside the card. Frankly, the SparkFun breakout board will save you a *ton*
of headaches.
aaahhh, rokiki, I missed that part of the code that defines the pins. I'll modify that tonight. Seems to be logical, now, why it didn't work. I DID play with the other pin assignment operators in the same sdspi.mount routine, but missed that...
I agree, too, that coathangers and paperclips are not the right way of getting this done, but I needed to do a quick setup that would help prove to me that I should change over to SD from eeprom for logging. I did check to make sure I was getting contact to all pins before I hit them with your code. Like I said, I'm not fully convinced about my hardware, but after your suggestion for pin assignments, I feel confident that my SD demo(lition) board will work.
-Parsko
PS- Being in Holland, I still don't like ordering stuff if it doesn't come from Holland. Duties, shipping, money exchange, WAIT, etc... contribute to the frustration of buying stuff. So, I try to do as much as I can with what I got.
PPS- I also thought that my card may not be formatted to FAT16, since it's a cannon camera SD card. My windows XP refuses to format it. So, I'm not fully convinced there either.
Hmm, if Windows XP "refuses" to format it, that's just really odd. I've not had any problems formatting any SD card using XP Pro.
What happens when you try? Do you get an error message? You are using Control Panel->Admin Tools->Computer Management->
Disk Management, and then right-click on the drive to attempt a format? Or are you trying some other method?
If you do use Disk Management, make sure to specify a cluster size that will give you between 8,192 and 65,536 clusters.
Generally a 32K cluster size will do this (and 32K is also the most efficient cluster size, time-wise).
Thanks for the input!!! The card is 16Mb (one of the freebies given with a camera). That explains why...
I even think I tried sticking it in the camera and formatting it. Any thoughts how to format it?
I didn't do anything last night... (My lady and I are being evicted due to the sale of our home by our landlord. She's almost 8 months pregnant. We're stressed, and that gets in the way of my thought processes sometimes.)
You are more clever than I with your abort codes. I get error code (-20), which, after digging through well documented code, means I haven't FAT16. On top of that, it's 16MB (XP won't format!?!). How frustrating is that. Too bad there isn't a 24hour Walmart in Holland...
Before I was able to get that info, I couldn't initialize the code according to your pinouts, and was getting a code of (-41), which I gather is the can't initialize. I'll attach my code, check out sdspi.start routine for my changes.
Anyway, I need another Card. I'll post if my setup was capable after that. Time for bed...
Or a Linux live evaluation CD would prolly be enough. (say like a Knoppix CD)
It's good to have one arround anyway in case XP decides to die, stranding your data on the HD.
later,
marty
P.S. a Live evaluation CD for linux is a complete·bootable linux·system on a CD.· It doesn't have to touch the hard-drive at all!
You may want to check your site. I just downloaded version 1.3 to check if I had the latest, and it states that it is still version 1.0 in the README file. I opened the FSRW I had on my machine prior, and it stated 1.0 too. The latest FSRW is 1.0 too. The code I posted and your code are still different regarding the specific parts in the sdspi.start routine where I set the pins up to work with my (bad) SD card I have at home.
It's 8:22am, and I am only on my 2nd cup of free instant cappuccino from the machine, so I could still be a bit dull...
Nice thing is that Media Markt is open until 9pm. One of a very few stores open past 6pm in Holland. So, I'll better know more later.
Toodles,
-Parsko
PS- While going to sleep, I dreamed about my scheme. I plan on logging 100kB/sec. That'll give ~2.75hours of data on a 1GB card! Forget eeproms!!!!! The equivalent board space would make my brothers race car a rolling eeprom transporter! (bad analogy, refer to "only on my 2nd cup of capuccino" line)
Yup, you're correct. Somehow, when I try to extract the zip file, it ain't writing to the directory...
I got it now.
But, my suggestion still stands on how I made the code work for my pin layout. Even your v1.3 wouldn't work cause I use:
CLK,di,do,cs(0),cs(1),...
You use:
do,CLK,di,cs
Otherwise, your 1.3 would likely help.
Back to more solid modeling...
-Parsko
PS- you electrical guys don't know how to make volume files!!!!! grumble grumble
Yep, 1.4 will have that fixed (at least, make it easier to pick an arbitrary set of four pins rather than require a contiguous group
in a specific order). I will probably do this work on Sunday.
Not sure I get the "volume files"; maybe you can expand on that?
When creating a product that contains mechanical components(chunks of metal, for instance) and electrical components (PC boards, for instance) that are housed in tight quarters, one must generate volume claims, so everything fits. My experience is that this is the first thing done, and agreed upon in a project, before actual detail design work can begin.
For some reason, my experience dictates that electrical guys are lousy at generated said volumes, whilst mechanical guys are better (duh). I'm a mechanical guy, attempting to do something clever so the both the electrical guys and mechanical guys will be happy with the volume they have to work within. More specifically, I'm doing the mechanical design (aka volume claim) of a PCB assembly that the electrical guys will take and populate with the components. It's critical how the PCB interfaces with my mechanical stuff.
I bought a Sandisk 512MB for 18euros. I bought the exact same thing for my digital camera for $75 16months ago! Anyway. I wrestled with trying to format it with windows XP, but it wouldn't. I tried your version 1.3 but couldn't get it to work. About 10 minutes ago, in a a last ditch attempt, I used my code from last night. Viola! Your demo ran. Hardware has been confirmed.
I tried putting it back into my computer 6-in-1 reader, and it still wouldn't recognize it, nor format it. I ended up formatting it with my camera. No bother, I can keep doing this in for the time being. Anyone got any ideas (other than a Linux machine) how I may format it with FAT16? Any suggestions how one would be able to read the file?
Okay, new release with the stupid adjacent pin requirement lifted. (You'll still need to rewrite start if you want to do this,
but it's a trivial change.) Also some other minor improvements, and it's a bit smaller to boot.
Comments
fsrw-and-friends 1.3 at http://tomas.rokicki.com/fat16work/ for everyone. With the new sdspiqasm driver, it
is somewhat faster, but nothing dramatic; with a pretty ordinary card I was able to get 428K bytes/second
reads and 304K bytes/second writes. Cheaper cards tend to be somewhat slower on writes (perhaps 150K
bytes/second is about the slowest I've seen). I think a high-quality card will be faster. But this is still pretty
quick. For comparison, my in-spin routines read at about 3.3K bytes/second and wrote at 2.8K bytes/second.
If someone *really* needs something faster, let me know. I have yet another version that has attained
491K bytes/second reading (again, this is through the file system, not just raw block I/O) and can probably
push it higher than this, but in order to do this I had to make it somewhat bigger.
Unless I hear about bugs or problems, I'm probably going to let this stuff stay as it is for a while so I can work
on other things. If you have additional features you need for a particular project, please let me know what
they are and how important they are. There's a lot that can be done, and fairly easily too, such as
subdirectory support, renaming, more than one file open at a time, etc., but I think the functionality we
currently have is pretty good, especially for the code size. With the new functionality I need to figure out
how to support multiple versions at the same time (because I don't want to bloat the base code just to add
some features not everyone needs).
First I must say rokicki·has done a great job with the SD-Card code and it's very helpfull for me to have you all writing in this forum.
Got some old SD cards which are not the secure ones, i.e they don't have the sam number of pins.
Now my question, is it possible to use or are there any changes needed in rokicki
Would be nice to use these old cards.
I have tried them with no luck, the newer card (secure ones) work OK with rokicki
Anyone how have a fix would be apreciated.
Hope my spelling· isn't to bad.
Regards Goran (Sweden)
You are always so helpful.
I got the message, use the old cards for something else since the· rokicki·code works nice with the new card.
Regards, Goran (Sweden)
I jumped the gun and baught one whith hopes to put together a tiny propeller-in-my-pocket system or a propeller pilot.
I have succesfully used 2 Sandisk Micro SD· 512 Mb and they both worked as expected.
Göran (Sweden)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I stand on the shoulders of giants
-Parsko
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?
I've killed a fly with my bare mind.
-Parsko
Thanks in advance,
- Earl
initialization of the dira register). (This is sdspi.spin, which is what I recommend you start with; make the
change in fsrw.spin). The bad code is:
outa := -1
dira[noparse][[/noparse]clk..cs] := 7
The first statement sets all four pins high (but it also clobbers any *other* pins that particular spin program
may happen to have set for output, which is bad). Then, the dira[noparse][[/noparse]...] command assumes clk..cs are the
three pins that need to be set to output, which may not be the case. (For instance, if clk=0 and cs=31,
you've just raised every pin on the chip.)
I'll fix these, and make some other minor improvements, tonight. Once I've done that it will be much easier
to change pin assignments.
-tom
conceivably undriven (see the circuit diagram at the top of sdspiqasm.spin); there should be six lines
pulled up. I used 20K.
BTW I pulled up Clk even though many references don't have it pulled up. I did this because if the
Prop hasn't started using the card yet, that pin is still floating. I hate floating inputs; I'm always afraid
they'll pick up random noise and cause all sorts of random mucky muck inside the CMOS circuits.
If anyone has any troubles making the routines work, *please* let me know.
I'd be leery of the paper-clip hack; I'm not sure what sort of contact a paper clip is going to make.
I don't know if that metal will have surface oxides that don't conduct that well, or if the springiness
will provide sufficient contact pressure, or that the paper clips may actually provide too much pressure
and break something inside the card. Frankly, the SparkFun breakout board will save you a *ton*
of headaches.
Post Edited (rokicki) : 1/30/2007 12:29:28 AM GMT
I agree, too, that coathangers and paperclips are not the right way of getting this done, but I needed to do a quick setup that would help prove to me that I should change over to SD from eeprom for logging. I did check to make sure I was getting contact to all pins before I hit them with your code. Like I said, I'm not fully convinced about my hardware, but after your suggestion for pin assignments, I feel confident that my SD demo(lition) board will work.
-Parsko
PS- Being in Holland, I still don't like ordering stuff if it doesn't come from Holland. Duties, shipping, money exchange, WAIT, etc... contribute to the frustration of buying stuff. So, I try to do as much as I can with what I got.
PPS- I also thought that my card may not be formatted to FAT16, since it's a cannon camera SD card. My windows XP refuses to format it. So, I'm not fully convinced there either.
What happens when you try? Do you get an error message? You are using Control Panel->Admin Tools->Computer Management->
Disk Management, and then right-click on the drive to attempt a format? Or are you trying some other method?
If you do use Disk Management, make sure to specify a cluster size that will give you between 8,192 and 65,536 clusters.
Generally a 32K cluster size will do this (and 32K is also the most efficient cluster size, time-wise).
Thanks for the input!!! The card is 16Mb (one of the freebies given with a camera). That explains why...
I even think I tried sticking it in the camera and formatting it. Any thoughts how to format it?
I didn't do anything last night... (My lady and I are being evicted due to the sale of our home by our landlord. She's almost 8 months pregnant. We're stressed, and that gets in the way of my thought processes sometimes.)
I should have more time tonight.
-Parsko
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
You are more clever than I with your abort codes. I get error code (-20), which, after digging through well documented code, means I haven't FAT16. On top of that, it's 16MB (XP won't format!?!). How frustrating is that. Too bad there isn't a 24hour Walmart in Holland...
Before I was able to get that info, I couldn't initialize the code according to your pinouts, and was getting a code of (-41), which I gather is the can't initialize. I'll attach my code, check out sdspi.start routine for my changes.
Anyway, I need another Card. I'll post if my setup was capable after that. Time for bed...
-Parsko
It's good to have one arround anyway in case XP decides to die, stranding your data on the HD.
later,
marty
P.S. a Live evaluation CD for linux is a complete·bootable linux·system on a CD.· It doesn't have to touch the hard-drive at all!
Post Edited (Lawson) : 2/2/2007 2:36:01 AM GMT
http://tomas.rokicki.com/fat16work/
Then, change the "sdspiqasm" in fsrw to "sdspi" so you use the slow, Spin routines.
Then, update the pins and initialization code so it only touches the pins you care about.
This may make it work. You are using fsrw 1.0, which doesn't understand as many
different card formats as fsrw 1.3 (currently on the site).
You are welcome to email me directly (my email address is on that site) if you want
to work on this more directly.
I'll also add a test routine that catches the abort errors and prints out more verbose
description of what the possible problem is.
You are helping me a lot, and by working this out together we'll make it much easier
for the next guy.
-tom
You may want to check your site. I just downloaded version 1.3 to check if I had the latest, and it states that it is still version 1.0 in the README file. I opened the FSRW I had on my machine prior, and it stated 1.0 too. The latest FSRW is 1.0 too. The code I posted and your code are still different regarding the specific parts in the sdspi.start routine where I set the pins up to work with my (bad) SD card I have at home.
It's 8:22am, and I am only on my 2nd cup of free instant cappuccino from the machine, so I could still be a bit dull...
Nice thing is that Media Markt is open until 9pm. One of a very few stores open past 6pm in Holland. So, I'll better know more later.
Toodles,
-Parsko
PS- While going to sleep, I dreamed about my scheme. I plan on logging 100kB/sec. That'll give ~2.75hours of data on a 1GB card! Forget eeproms!!!!! The equivalent board space would make my brothers race car a rolling eeprom transporter! (bad analogy, refer to "only on my 2nd cup of capuccino" line)
http://tomas.rokicki.com/fat16work/
and download the zip there? The zip URL is
http://tomas.rokicki.com/fat16work/fsrw-and-friends-1.3.zip
I've checked and double-checked and it's 1.3 everywhere (README and fsrw.spin).
I can't imagine how you're picking up 1.0 still if you've downloaded that zip.
Anyone else care to check and see if they get 1.3 or 1.0 when they download from my site?
Yup, you're correct. Somehow, when I try to extract the zip file, it ain't writing to the directory...
I got it now.
But, my suggestion still stands on how I made the code work for my pin layout. Even your v1.3 wouldn't work cause I use:
CLK,di,do,cs(0),cs(1),...
You use:
do,CLK,di,cs
Otherwise, your 1.3 would likely help.
Back to more solid modeling...
-Parsko
PS- you electrical guys don't know how to make volume files!!!!! grumble grumble
in a specific order). I will probably do this work on Sunday.
Not sure I get the "volume files"; maybe you can expand on that?
For some reason, my experience dictates that electrical guys are lousy at generated said volumes, whilst mechanical guys are better (duh). I'm a mechanical guy, attempting to do something clever so the both the electrical guys and mechanical guys will be happy with the volume they have to work within. More specifically, I'm doing the mechanical design (aka volume claim) of a PCB assembly that the electrical guys will take and populate with the components. It's critical how the PCB interfaces with my mechanical stuff.
Did that clear it up for ya?
-Parsko
I tried putting it back into my computer 6-in-1 reader, and it still wouldn't recognize it, nor format it. I ended up formatting it with my camera. No bother, I can keep doing this in for the time being. Anyone got any ideas (other than a Linux machine) how I may format it with FAT16? Any suggestions how one would be able to read the file?
Need sleep bad, fading fast........ ......... ...... ..... ... .. .
-Parsko
but it's a trivial change.) Also some other minor improvements, and it's a bit smaller to boot.