I notice your code has a boolean for read/write rather than a separate read and write routine at the block layer.
Any chance I can convince you to break it out into two routines (perhaps that call a single master routine)?
I'd like your block layer and our block layers to be exactly the same API.
At the moment that API is
pub start(basepin)
pub readblock(n, b)
pub writeblock(n, b)
Here, "n" is the block number and "b" is the buffer to store data in.
We may extend this API, but it would be most excellent if we could come to agreement so
other people can just plug and go rather than have to manipulate the code.
Can I ask that you also allow the pins on the SD card to be variable i.e. not contiguous ?
Neither my TriBlade nor the upcoming RamBlade use contiguous pins for maximum sram speed.
Also posted a fix·for the sdspiFemto to tristate the D0 pin after use (as I share it with the sram).
I also use a routine to return the SD address (cannot recall at the moment how I did this), basically so I can use this later to do a read directly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
mynet43 said...
...
Unfortunately, when I ran it, it returns with an abort code of -20. (With either a 1GB or 8GB SD/SDHC)
if (brlong(@buf+$36) <> constant("F" + ("A" << 8) + ("T" << 16) + ("1" << 24)) or buf[noparse][[/noparse]$3a] <> "6")
abort(-20) ' not a fat16 volume
Do I need to make some change to this line of code, or is something else wrong?
...
I've attached the two files I'm using to test this. Let me know what you recommend.
I'm happy to keep helping you test this.
Jim
Hi, Jim.
Thanks for testing! (Sorry I missed your post earlier). OK, some observations:
- you were using fsrw version 1.5, we've been developing based on 1.6...I don't think that is the issue, but I'd ask you to upgrade anyway, to remove that as a possible issue
- the edits you made to fsrw are all very sensible, no issues there
- the version of the mmscdhc_spi.spin file you grabbed uses the absolute fastest SPI routines available. This works great for me on a custom board at 100MHz with a uSD slot and super short traces. However, I've had problems with the 1-instruction-per-bit-reads on a regular protoboard with a 9" ribbon cable connecting a hacked-together MMC/SD slot at 80MHz. So, I'm attaching to this post a modified version of the mmcsdhc_spi file that uses 2 instructions per bit for the reads, and 1-per for the writes. It may be that this version works on your setup. For the final released version, we plan to have conditional compilation working, you can just pick what works for you and go.
Thanks again!
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Cluso99 said...
Can I ask that you also allow the pins on the SD card to be variable i.e. not contiguous ?
Neither my TriBlade nor the upcoming RamBlade use contiguous pins for maximum sram speed.
Also posted a fix for the sdspiFemto to tristate the D0 pin after use (as I share it with the sram).
I also use a routine to return the SD address (cannot recall at the moment how I did this), basically so I can use this later to do a read directly.
Non-contiguous pins are already working in the new block layer! (start_explicit(...), and start(...) is just a wrapper for compatibility). As of right now you will have to modify fsrw to pass in the needed info, but by release time all that will be taken care of for you.
As to tri-stating the DO pin (that's DataOut from the card, DataIn to the propeller, right?) that's a bit tougher as I was planning on adding write-behind functionality so finishing the SD/fsrw command would not necessarily mean the block layer was really done with the pins. We could offer a "flush" command, which would pause until all MMC/SD traffic was done, tristate the pin and return, but obviously I have not thought through the ramifications of that strategy. I'm also using multiblock modes exclusively in the latest block layer, so that does complicate things a bit. (The speed gains are huge, though, especially for SDHC where single block writes seem to be turtle slow! On my 100MHz system, I'm getting raw contiguous reads & writes at ~1.6MB/s using the multiblock approach!)
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Eh, I can make multiple read and write functions, I'll just pass them through the master read and write function I have.
You may wish to take my approach, if you look I only have about 6 lines of spin code needed for block read and write. The way its setup current works very fast and is easy to decode in asm.
I also made mine auto initialize so that its very easy to get back to reading and writing blocks.
My api is essentially:
PUB Start - Starts the block layer driver which handles everything including the CSD for information about card size and speed. It also auto mounts the card.
PUB readWrite(blockNumber, readWrite) - Makes the driver read or write a block from a buffer in the memory. It may be better however if a add an address feature to this command so that it can read in multiple blocks at once for more than one file. But lets get one file working really fast first.
Kye said...
...
PUB Start - Starts the block layer driver which handles everything including the CSD for information about card size and speed. It also auto mounts the card.
...
Multiblock mode is cool. How are you sopossed to use it however without more buffer memory? My aim is to make my file system small and light... Hmm
Nice. I want to extend my code to also query the card's size, so I may take a peek at your code. Note that according to the SD simplified Spec, the card speed is only defined when you are using SD mode. For SPI mode you just get a fixed maximum clock speed (25MHz for SD, 20MHz for MMC (after initialization)).
I'm using Multiblock mode one block at a time...you can just leave the card in whatever state you need, give it 8 clocks to complete an operation, and then shut down the CLK line between writes or reads. The trick is to manage the state. My code checks if the direction (read vs. write) is different, or if the address is not the next consecutive block...if either is true then I exit the last mode, and enter the new mode using the new address. Then I can just read or write single blocks as needed (the block tokens are slightly different, of course).
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Here is an interesting concept on avoiding MS patents with regard to long filenames. It's not incredibly difficult to implement relative to full LFN support. I can't find any references to patents over FAT32 specifically, all information I can find seems to point to the VFAT variants (LFN and other additions) rather than the size of the FAT or FS structure.
Interesting to see the workaround in the patch to stop XP bluescreening. Sounds like a nice little vulnerability there (as if we needed to find another way to bluescreen XP anyway)
Just a point of interest.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!
BradC: That's the same Linux kernel patch from Andrew Tridgell and the Samba team that I started this thread with.
Interesting link for the legal/technical reasoning though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
BradC: That's the same Linux kernel patch from Andrew Tridgell and the Samba team that I started this thread with.
Interesting link for the legal/technical reasoning though.
Oops.. <blush> yeah, sorry about that. It's taken me over a week to catch up on my lkml mail as I've been a bit snowed under. I should have read the original linked article rather than shooting from the hip.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!
Just musing, I don't expect any definitive answer here, there is one thing I have never understood about patents on software.
You see if someone has a patent, on anything, there is nothing in that disallowing me from describing how that patent works to anyone else. In fact half the idea of patents is that the idea can be made public knowledge whilst at the same time giving protection over use of that idea to the holder for a while.
That, to me, means that if someone has a patent on some software idea then I can describe it to anyone else. As it is a software idea I may choose to describe the idea in a programming language, C for example. So as a software author I should never have any problems with patents. It's only a description.
Now if you take my description, in C, and choose to compile it into a program that runs on a machine, then you have a working device and using (or selling) that for commercial gain could/would be a patent violation.
Conclusion, posting a version of Bill's patented FAT file system in OBEX is no violation of any patent, in fact it is only doing what patent law was intending to be done, allowing the idea to be known.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
And here's the code for getting the number of bytes and sectors on the card. Yeah it sucks, but it seems like the people you invented the spec for the SD card never though much about acutally writing the code to read the values from it.
They had a value across 3 different bytes... WTF!
...
Now, as for long file name support. I do not plan to add it and I will not add it. You can if you want. Its actually as said, not so hard.
But, LFN support is ALOT of extra code and buffer space for file names. It really will add a massive overhead to file searching and stuff which already takes a while.
Comments
Any chance I can convince you to break it out into two routines (perhaps that call a single master routine)?
I'd like your block layer and our block layers to be exactly the same API.
At the moment that API is
Here, "n" is the block number and "b" is the buffer to store data in.
We may extend this API, but it would be most excellent if we could come to agreement so
other people can just plug and go rather than have to manipulate the code.
Neither my TriBlade nor the upcoming RamBlade use contiguous pins for maximum sram speed.
Also posted a fix·for the sdspiFemto to tristate the D0 pin after use (as I share it with the sram).
I also use a routine to return the SD address (cannot recall at the moment how I did this), basically so I can use this later to do a read directly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· 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) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 7/4/2009 10:53:35 PM GMT
Thanks for testing! (Sorry I missed your post earlier). OK, some observations:
- you were using fsrw version 1.5, we've been developing based on 1.6...I don't think that is the issue, but I'd ask you to upgrade anyway, to remove that as a possible issue
- the edits you made to fsrw are all very sensible, no issues there
- the version of the mmscdhc_spi.spin file you grabbed uses the absolute fastest SPI routines available. This works great for me on a custom board at 100MHz with a uSD slot and super short traces. However, I've had problems with the 1-instruction-per-bit-reads on a regular protoboard with a 9" ribbon cable connecting a hacked-together MMC/SD slot at 80MHz. So, I'm attaching to this post a modified version of the mmcsdhc_spi file that uses 2 instructions per bit for the reads, and 1-per for the writes. It may be that this version works on your setup. For the final released version, we plan to have conditional compilation working, you can just pick what works for you and go.
Thanks again!
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
As to tri-stating the DO pin (that's DataOut from the card, DataIn to the propeller, right?) that's a bit tougher as I was planning on adding write-behind functionality so finishing the SD/fsrw command would not necessarily mean the block layer was really done with the pins. We could offer a "flush" command, which would pause until all MMC/SD traffic was done, tristate the pin and return, but obviously I have not thought through the ramifications of that strategy. I'm also using multiblock modes exclusively in the latest block layer, so that does complicate things a bit. (The speed gains are huge, though, especially for SDHC where single block writes seem to be turtle slow! On my 100MHz system, I'm getting raw contiguous reads & writes at ~1.6MB/s using the multiblock approach!)
thanks,
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Thanks for the update. I've downloaded the slower mmcsdhc you attached.
I'll download the latest fsrw and make the same mods to it.
I have a custom board (80 MHz) with short traces to the uSD socket.
If I can get it working, I'll try the faster mmcsdhc and let you know how it goes.
Thanks again for the help.
Jim
You may wish to take my approach, if you look I only have about 6 lines of spin code needed for block read and write. The way its setup current works very fast and is easy to decode in asm.
I also made mine auto initialize so that its very easy to get back to reading and writing blocks.
My api is essentially:
PUB Start - Starts the block layer driver which handles everything including the CSD for information about card size and speed. It also auto mounts the card.
PUB readWrite(blockNumber, readWrite) - Makes the driver read or write a block from a buffer in the memory. It may be better however if a add an address feature to this command so that it can read in multiple blocks at once for more than one file. But lets get one file working really fast first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 7/5/2009 9:19:53 PM GMT
<scratch chin> Hmmm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 7/5/2009 9:19:05 PM GMT
I'm using Multiblock mode one block at a time...you can just leave the card in whatever state you need, give it 8 clocks to complete an operation, and then shut down the CLK line between writes or reads. The trick is to manage the state. My code checks if the direction (read vs. write) is different, or if the address is not the next consecutive block...if either is true then I exit the last mode, and enter the new mode using the new address. Then I can just read or write single blocks as needed (the block tokens are slightly different, of course).
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
Here is an interesting concept on avoiding MS patents with regard to long filenames. It's not incredibly difficult to implement relative to full LFN support. I can't find any references to patents over FAT32 specifically, all information I can find seems to point to the VFAT variants (LFN and other additions) rather than the size of the FAT or FS structure.
Interesting to see the workaround in the patch to stop XP bluescreening. Sounds like a nice little vulnerability there (as if we needed to find another way to bluescreen XP anyway)
Just a point of interest.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!
Post Edited (BradC) : 7/5/2009 1:16:50 PM GMT
Interesting link for the legal/technical reasoning though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Oops.. <blush> yeah, sorry about that. It's taken me over a week to catch up on my lkml mail as I've been a bit snowed under. I should have read the original linked article rather than shooting from the hip.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Missed it by ->" "<- that much!
You see if someone has a patent, on anything, there is nothing in that disallowing me from describing how that patent works to anyone else. In fact half the idea of patents is that the idea can be made public knowledge whilst at the same time giving protection over use of that idea to the holder for a while.
That, to me, means that if someone has a patent on some software idea then I can describe it to anyone else. As it is a software idea I may choose to describe the idea in a programming language, C for example. So as a software author I should never have any problems with patents. It's only a description.
Now if you take my description, in C, and choose to compile it into a program that runs on a machine, then you have a working device and using (or selling) that for commercial gain could/would be a patent violation.
Conclusion, posting a version of Bill's patented FAT file system in OBEX is no violation of any patent, in fact it is only doing what patent law was intending to be done, allowing the idea to be known.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Okay, for card size and such, first read in the CSD register:
ifnot(command(constant($40 | 9), 0)) if(responce($FF) == $FE) repeat result from 0 to 15 CSD[noparse][[/noparse]result] := readAByte readAByte readAByteThat little bit of code should get you going. Send off command 9 and check for a responce of $FE. Then read in 16 bytes and read in the crc.
And here's the code for getting the number of bytes and sectors on the card. Yeah it sucks, but it seems like the people you invented the spec for the SD card never though much about acutally writing the code to read the values from it.
They had a value across 3 different bytes... WTF!
...
Now, as for long file name support. I do not plan to add it and I will not add it. You can if you want. Its actually as said, not so hard.
But, LFN support is ALOT of extra code and buffer space for file names. It really will add a massive overhead to file searching and stuff which already takes a while.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 7/5/2009 9:21:08 PM GMT