This is great. I can now push the whole sector read code into assembly and hopefully get better performance.
BTW: This CRC code helped speed up the eMMC Spin code a little. But, I'm still seeing a series of single block reads as being much slower than a big multiblock read. Maybe that's just the way it is? I'm not seeing anything in my code that would account for this...
This is great. I can now push the whole sector read code into assembly and hopefully get better performance.
BTW: This CRC code helped speed up the eMMC Spin code a little. But, I'm still seeing a series of single block reads as being much slower than a big multiblock read. Maybe that's just the way it is? I'm not seeing anything in my code that would account for this...
@Rayman
I suggest you look at my SD code I've just released if you want to get it running fast. It works in COG or LUT.
It should drop in to your code easily
For the CRC routine, I believe if you provide the last $00 (extra) byte (which gets replaced by the crc) but instead use $80 I believe you can then run the crc routine completely without the last statement that fiddles the routine to use 7 bits, and then does another fix. Haven't had time to try it yet.
Comments
I tried all sorts of reversals and inversions and just couldn't get crcbit or crcnib to work. Didn't think of shifting the poly
Maybe the code in the earlier posts would have worked too if I had done only 5 bytes instead of 5 and 7/8 bytes...
It's so bizarre now how that 5-7/8 byte code actually works... Those last seven zeros must clean up something not done right earlier...
http://chibios.sourceforge.net/docs3/hal/hal__mmc__spi_8c_source.html
BTW: This CRC code helped speed up the eMMC Spin code a little. But, I'm still seeing a series of single block reads as being much slower than a big multiblock read. Maybe that's just the way it is? I'm not seeing anything in my code that would account for this...
The crcnib will be a huge help there I hope
If not, you could use a table driven approach from LUTRAM perhaps. Should still be quite fast.
@Rayman
I suggest you look at my SD code I've just released if you want to get it running fast. It works in COG or LUT.
It should drop in to your code easily
For the CRC routine, I believe if you provide the last $00 (extra) byte (which gets replaced by the crc) but instead use $80 I believe you can then run the crc routine completely without the last statement that fiddles the routine to use 7 bits, and then does another fix. Haven't had time to try it yet.