The schematic is as per the diagrams in fsrw, only difference is the prop pins used:
do := 12 (MISO)
di := 13 (MOSI)
clk := 14
cs := 15
10K pullups on above to +3.3k, in-line 2k2 current limiting resistor on MISO to prop pin.
I'm quite puzzled...
I adjusted the pins in every spi*.spin file.
Thanks,
Bill
lonesock said...
spispin, spiasm, spiqasm remain unchanged from the FSRW 1.6 release. The new "safe_spi.spin" default block driver for the 2.6 release does in fact have a different initialization sequence from the old ones, but it actually conforms better to the standard while supporting MMC/SD/SDHC cards. It's definitely possible that the issue is there, however I have tested it on ~6 SanDisk cards, most 2GB, but ranging up to 4GB SDHC. Others have tried even larger cards.
Is there any chance you could post a zip of your schematic and source code? If you do not wish to post them on the forum you can email them to me at this username at gmail.com.
The return code of -41 is a mystery...the only places an unspecified code can come back are:
* the send_SPI_command_fast does not get a valid response from the SD card (in the block layer)
* pflushbuf fails (in FSRW, not sure why this would fail here, though)
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Post Edited (Bill Henning) : 12/31/2009 6:54:08 AM GMT
Different error message this time: -1 ... "card not reset"
Cluso99 said...
Bill, try shorting your 2k2 series resistors - they are way toooo high!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
I have duplicated my circuit on my PDB, and it works there with the same cards... so obviously I must have something wrong on my PCB, which is weird as it buzzed out OK.
Now I can compare the PDB wired circuit to the new PCB...
Thanks guys.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Problem turned out to be /CS not making proper contact with the card.... sheesh, a simple mechanical problem!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Thanks... no, the SD interface gets 4 pins of its own!
Cluso99 said...
Glad you solved your problem Bill
Are you sharing the SD pins with other uses?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95 Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
How does one figure out the amount of free space on an SD card using fsrw?
I'm currently looping over all the files on the disk and adding up their individual volumes then subtracting that from card size. This is kind of slow when there are a lot of files. I've been looking through the SD specs I can find online to see if there's a register in the FAT that reflects the amount of used space but haven't found it or don't recognize it. Anyone know for sure that it's there or NOT there?
Yeah, theres no free space register for FAT16. Nor is the free space register in FAT32 always valid. You'll need more intelligent code to do this faster.
1. Do it as you are doing (takes time proportional to the number of files, and ignores subdirectories).
Also not very accurate unless you are careful to take into account the block size, etc.
2. Scan the FAT itself. This is in some sense the best way, but will require some amount of time to
do. FSRW does have routines that support this, but it will be faster to add a specialized routine.
The amount of time required is linear in the size of the FAT, which could be quite large. On a FAT16
card the FAT is at most 131K, but on a FAT32 volume it can be huge.
3. Modify the driver to do a scan at mount time (slowing mount time down a lot) and then keep track
of all block allocations/deallocations. I don't like the scan at mount time so fsrw doesn't do this.
4. Figure out why you need to know free space. Can you give us a better idea of what you're trying to
do? For instance, answering the question "can I write 1M more to this card" is *much* faster than
"how much space is on the card". Also, 2GB cards are very cheap these days, and most applications
will never even come close to filling a 2GB card.
So what are you trying to do, exactly?
I can write a "freespace" routine pretty easily but it will take a fair fraction of a second to run, most likely,
on a typical 2GB FAT16 card.
pgbpsu said...
How does one figure out the amount of free space on an SD card using fsrw?
I'm currently looping over all the files on the disk and adding up their individual volumes then subtracting that from card size. This is kind of slow when there are a lot of files. I've been looking through the SD specs I can find online to see if there's a register in the FAT that reflects the amount of used space but haven't found it or don't recognize it. Anyone know for sure that it's there or NOT there?
Thanks for your comments. I'm trying to avoid the consequence of attempting to write to a full disk. My past experience has been that trying to write more than 512 files to an SD card corrupted it and make it difficult to get my data back. Watching the number of files on the disk is not a big deal. When my system first boots, I scan the SD to figure out how many files there are, what size the card is, and the amount of used space. From there it moves into and acquisition loop that grabs 4 32 bit samples every 800uS shoves them into a circular buffer which is monitored and dumped by another cog. I create a new file every 6 hours. On disk there are data files and meta data files. So they come in pairs. I want to be sure that I can tell my system to stop acq before the disk fills (16GB will fill in about 10 days). I think the only thing I can do in the amount of time I have (which is very little) is to keep subtracting the number of bytes I've written to the disk from the free space I calculate at the beginning. When I get within 5% of full, I'll probably shut it down.
I hope my book keeping will be accurate enough for that...
I think what you propose is probably the most logical way to proceed. Give it enough breathing space (10%?) and you should be fine.
In general, you can't write more than 512 files to the root directory (and fsrw only supports the root directory right now). On the other
hand, attempting to write more than 512 files should absolutely *not* corrupt any cards. As a matter of fact, to my knowledge, there's
no way to use fsrw to corrupt a card, so if you have a use case that can corrupt a card, please attempt to replicate it and let me know.
I would simply write your code to expect an empty card each time, and complain if it's not empty. Why make life more complicated
than it needs to be?
You're writing 20K/sec, which is 1.7GB a day; whew! That's a lot of data. If it's really that constant, things are even simpler; just make
sure to change cards every 7 days or some such.
Attempting to write to a full disk should not be an issue at all. The fsrw routines should all simply return error codes; there should be
no possibility of damaging a card or corrupting the filesystem if you ignore the error codes/aborts.
Thanks for commenting. I've managed to corrupt cards, but that was a long time ago and I'm not willing to point the finger at FSRW. More than likely I was giving them bad file names and causing my own damage. I think counting the files and free space at start and then counting down for both items will help me sleep at night. Plus we have radios connected to these systems so it's useful to send that kind of info back to the base station so we can monitor the acquisition. Besides, I can't trust the guys using these systems to always start with an empty card so counting down is my only real option. And it's an acceptable one.
These units are 4 channel seismic dataloggers being deployed to Norway for temporary installation on a glacier. During the deployment the local power company is going to pump enough water under the base of the ice to lift it up. We want to record the seismic signal (and GPS using other instruments). Ten days ought to do it.
Okay. If you say the word, I'd be happy to write a legitimate "scan the FAT and return free space" routine for you---if it will help. Note that it will
take a good fraction of a second to complete, and if you are *concurrently* writing 20K/sec to the card, you might run out of buffer space and
lose samples. (So if you can turn off sampling while the free space check is going on, that would be optimal).
Once you have that, keeping track of free space is pretty easy; each file of size n bytes takes clustersize*ceil(n/clustersize) bytes of physical storage.
That's a kind offer, but as you speculated, I don't have the buffer space to survive. I've set aside .5 sec in a circular buffer. But I've got to open and close the seismic data file and occasionally open the metadata file in this .5sec. I can't say I have it stable as yet, but there are a number of other things going on so trying to worry about the free space routine returning in time isn't high on my list right now. I'll simply keep track of what I've written to the disk and subtract that from the free space I saw at the beginning. That should get me in the ballpark.
Thanks again for the offer. Writing all these routines has been more than I could ever have asked for.
Comments
The schematic is as per the diagrams in fsrw, only difference is the prop pins used:
do := 12 (MISO)
di := 13 (MOSI)
clk := 14
cs := 15
10K pullups on above to +3.3k, in-line 2k2 current limiting resistor on MISO to prop pin.
I'm quite puzzled...
I adjusted the pins in every spi*.spin file.
Thanks,
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Post Edited (Bill Henning) : 12/31/2009 6:54:08 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Different error message this time: -1 ... "card not reset"
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
I have duplicated my circuit on my PDB, and it works there with the same cards... so obviously I must have something wrong on my PCB, which is weird as it buzzed out OK.
Now I can compare the PDB wired circuit to the new PCB...
Thanks guys.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Problem turned out to be /CS not making proper contact with the card.... sheesh, a simple mechanical problem!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Are you sharing the SD pins with other uses?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheusdual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory IO board kit $89.95, both kits $189.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
I'm currently looping over all the files on the disk and adding up their individual volumes then subtracting that from card size. This is kind of slow when there are a lot of files. I've been looking through the SD specs I can find online to see if there's a register in the FAT that reflects the amount of used space but haven't found it or don't recognize it. Anyone know for sure that it's there or NOT there?
Thanks,
Peter
Check out http://forums.parallax.com/forums/default.aspx?f=25&m=430553. And clik the link in that post.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
1. Do it as you are doing (takes time proportional to the number of files, and ignores subdirectories).
Also not very accurate unless you are careful to take into account the block size, etc.
2. Scan the FAT itself. This is in some sense the best way, but will require some amount of time to
do. FSRW does have routines that support this, but it will be faster to add a specialized routine.
The amount of time required is linear in the size of the FAT, which could be quite large. On a FAT16
card the FAT is at most 131K, but on a FAT32 volume it can be huge.
3. Modify the driver to do a scan at mount time (slowing mount time down a lot) and then keep track
of all block allocations/deallocations. I don't like the scan at mount time so fsrw doesn't do this.
4. Figure out why you need to know free space. Can you give us a better idea of what you're trying to
do? For instance, answering the question "can I write 1M more to this card" is *much* faster than
"how much space is on the card". Also, 2GB cards are very cheap these days, and most applications
will never even come close to filling a 2GB card.
So what are you trying to do, exactly?
I can write a "freespace" routine pretty easily but it will take a fair fraction of a second to run, most likely,
on a typical 2GB FAT16 card.
Thanks for your comments. I'm trying to avoid the consequence of attempting to write to a full disk. My past experience has been that trying to write more than 512 files to an SD card corrupted it and make it difficult to get my data back. Watching the number of files on the disk is not a big deal. When my system first boots, I scan the SD to figure out how many files there are, what size the card is, and the amount of used space. From there it moves into and acquisition loop that grabs 4 32 bit samples every 800uS shoves them into a circular buffer which is monitored and dumped by another cog. I create a new file every 6 hours. On disk there are data files and meta data files. So they come in pairs. I want to be sure that I can tell my system to stop acq before the disk fills (16GB will fill in about 10 days). I think the only thing I can do in the amount of time I have (which is very little) is to keep subtracting the number of bytes I've written to the disk from the free space I calculate at the beginning. When I get within 5% of full, I'll probably shut it down.
I hope my book keeping will be accurate enough for that...
Regards,
Peter
In general, you can't write more than 512 files to the root directory (and fsrw only supports the root directory right now). On the other
hand, attempting to write more than 512 files should absolutely *not* corrupt any cards. As a matter of fact, to my knowledge, there's
no way to use fsrw to corrupt a card, so if you have a use case that can corrupt a card, please attempt to replicate it and let me know.
I would simply write your code to expect an empty card each time, and complain if it's not empty. Why make life more complicated
than it needs to be?
You're writing 20K/sec, which is 1.7GB a day; whew! That's a lot of data. If it's really that constant, things are even simpler; just make
sure to change cards every 7 days or some such.
Attempting to write to a full disk should not be an issue at all. The fsrw routines should all simply return error codes; there should be
no possibility of damaging a card or corrupting the filesystem if you ignore the error codes/aborts.
Thanks for commenting. I've managed to corrupt cards, but that was a long time ago and I'm not willing to point the finger at FSRW. More than likely I was giving them bad file names and causing my own damage. I think counting the files and free space at start and then counting down for both items will help me sleep at night. Plus we have radios connected to these systems so it's useful to send that kind of info back to the base station so we can monitor the acquisition. Besides, I can't trust the guys using these systems to always start with an empty card so counting down is my only real option. And it's an acceptable one.
These units are 4 channel seismic dataloggers being deployed to Norway for temporary installation on a glacier. During the deployment the local power company is going to pump enough water under the base of the ice to lift it up. We want to record the seismic signal (and GPS using other instruments). Ten days ought to do it.
I'm sure everything will go according to plan.
p
take a good fraction of a second to complete, and if you are *concurrently* writing 20K/sec to the card, you might run out of buffer space and
lose samples. (So if you can turn off sampling while the free space check is going on, that would be optimal).
Once you have that, keeping track of free space is pretty easy; each file of size n bytes takes clustersize*ceil(n/clustersize) bytes of physical storage.
That's a kind offer, but as you speculated, I don't have the buffer space to survive. I've set aside .5 sec in a circular buffer. But I've got to open and close the seismic data file and occasionally open the metadata file in this .5sec. I can't say I have it stable as yet, but there are a number of other things going on so trying to worry about the free space routine returning in time isn't high on my list right now. I'll simply keep track of what I've written to the disk and subtract that from the free space I saw at the beginning. That should get me in the ballpark.
Thanks again for the offer. Writing all these routines has been more than I could ever have asked for.
Many thanks,
Peter