I don't think so. You're talking about SD card mode which is strictly proprietary. You have to have a license to use it (and sell any products that use it).
The Solomon LCD driver chip I'm using has an SD card interface and works in 4-bit mode. You read or write blocks at a time. Combining that with the 8-bit data bus to the Prop should make for some lightning fast transfers...
We were talking with lonesock about this, he told me, maybe we couln'd get a good speed due some extra calculus using this 4 bit at a time, that differs what they are doing with sdspi driver.
Anyway I've tried it in a FPGA, and I get impressive 9.6Mbytes/sec reading files in multiblock mode, would be amazing if you get a good performance in pchip !!.
Is really strictly proprietary this mode ? (as Mike said).. I listen some other guys talking about it as possibe partial free code, the sd asosication gives a simplified specification of the driver for free.
I posted a link a while ago in another thread. There was some C code which implements the 4 bit mode. Does anyone remember the thread or the link?
I'm sure that you will get into trouble if you sell products that use the 4 bit mode, but why shouldn't they allow to use 4 bit mode in private projects?
Maybe it's cheap? Somebody could build the driver, and just distribution limit access to it. When a purchase is made, supply a binary, and "reference code". That would resolve both the private project problem (and that should be obvious enough for me not to write it here), and open the door for those commercial, or simply non-private uses. I'm sure there is some base fee, and then a per instance royalty. It might not be difficult, or too expensive.
Maybe take up a collection, fund the initial development, and then have somebody be the point of distribution?
I would be interested in participating in something like this. Really fast SD card has it's merits.
Right now you can have 1 bit output per instruction, and if your cog<->pins relationship and wiring are OK, you can do the same for input. The problem with going to 4-pin data mode is that I can't think of a way to read in 4 bits, shift the current data variable left by 4, then OR in the new data, all in less than 4 PASM instructions. I bet there's a way to do it in 3 instructions, plus some extra setup overhead, but still, 4 bits from 3 instructions is only a 1/3 speedup. *AND* for that to work you'd probably have to fix your SD data pins to always be [0..3].
If we can figure out a 3-instruction method that works for any set of 4 (contiguous) pins, I can work that into a new rev of the FSRW block driver. The real bonus to this method would be that the clock/read timing requirements would drop, so everybody could always use the fast mode...no need to use the safe version by default.
The simplified SD spec _does_ include information about using the 4-bit data mode, so I believe it is OK to implement the basics. (Note: I do not remember off the top of my head if CRC checks are required by the 4-bit mode...if so, that overhead would probably negate the speedup.)
Just thinking...using data I/O pins 0..3 for data, we could use a combination of MOVS and ROR to get 4 bits every 2 instructions (only up to 27 bits or we lose data). Or, if the data comes in a bit reversed order, we would have to use I/O pins 5..8, then use MOVS and ROL. I'd probably read 16 bits twice, then combine the data.
So, for a slightly less than 2x speedup, would people be willing to fix the SD I/O pins?
PJMonty and I were having lunch the other day and chatting about this. We agreed that it seems odd that SD Card Association seems to want to discourage the use of SD cards by anyone except big vendors. Isn't it in their interest to sell more cards by providing the full communications spec to any would-be developer?
It probably makes a lot of sense to figure this out for Prop 2.
Maybe the membership fee is just for the "secure" part of the SD spec...
My feeling is that not too many people would give up 2 more pins of Prop1 when it is plenty fast as is....
jazzed
Posts: 11,803
Comments
The Solomon LCD driver chip I'm using has an SD card interface and works in 4-bit mode. You read or write blocks at a time. Combining that with the 8-bit data bus to the Prop should make for some lightning fast transfers...
Anyway I've tried it in a FPGA, and I get impressive 9.6Mbytes/sec reading files in multiblock mode, would be amazing if you get a good performance in pchip !!.
Is really strictly proprietary this mode ? (as Mike said).. I listen some other guys talking about it as possibe partial free code, the sd asosication gives a simplified specification of the driver for free.
I'm sure that you will get into trouble if you sell products that use the 4 bit mode, but why shouldn't they allow to use 4 bit mode in private projects?
Maybe it's cheap? Somebody could build the driver, and just distribution limit access to it. When a purchase is made, supply a binary, and "reference code". That would resolve both the private project problem (and that should be obvious enough for me not to write it here), and open the door for those commercial, or simply non-private uses. I'm sure there is some base fee, and then a per instance royalty. It might not be difficult, or too expensive.
Maybe take up a collection, fund the initial development, and then have somebody be the point of distribution?
I would be interested in participating in something like this. Really fast SD card has it's merits.
If we can figure out a 3-instruction method that works for any set of 4 (contiguous) pins, I can work that into a new rev of the FSRW block driver. The real bonus to this method would be that the clock/read timing requirements would drop, so everybody could always use the fast mode...no need to use the safe version by default.
The simplified SD spec _does_ include information about using the 4-bit data mode, so I believe it is OK to implement the basics. (Note: I do not remember off the top of my head if CRC checks are required by the 4-bit mode...if so, that overhead would probably negate the speedup.)
Jonathan
So, for a slightly less than 2x speedup, would people be willing to fix the SD I/O pins?
Jonathan
Why not have a design that would use 2 devices?
I guess you couldn't use FAT with the files unless the data was identical.
I have board ready to fab that uses 2 Winbond chips (4 bits each).
Having 2 SD cards wouldn't be much different except for space required.
General membership in the SD Card Association is $2000 per year.
http://www.sdcard.org/developers/faq/
PJMonty and I were having lunch the other day and chatting about this. We agreed that it seems odd that SD Card Association seems to want to discourage the use of SD cards by anyone except big vendors. Isn't it in their interest to sell more cards by providing the full communications spec to any would-be developer?
Maybe the membership fee is just for the "secure" part of the SD spec...
My feeling is that not too many people would give up 2 more pins of Prop1 when it is plenty fast as is....