I don’t think it’s a hardware issue on the Panda Tinkerer kit.
I run the same test on 3 separate Tinkerer boards with the same SD card, an they all came back with the 9.6 seconds.
I did some tests with different formating of the SD card and this is my findings;
FAT16 - 16Kb (unit size) - 9.28 sec.
FAT16 - 32Kb - 7.2 sec.
FAT16 - 64Kb - 7.0 sec.
FAT32 - 4096 byte - 51.40 sec.
FAT32 - 8192 byte - 28.86 sec.
I was not able to format the SD card under FAT32 for higher cluster size.
So it seems to have more to do with formating of the SD card than anything else. That leaves me with my SD read problem…
[url]http://www.tinyclr.com/forum/2/1775/[/url]
There is something strange going on here. :
Really good to know. It will be great to see what the guys come up with to optimize FAT 32 and see what the bottle neck is.
So, larger allocation units = better performance on FAT16
FAT32 uses small allocation units.
Maybe allocation unit is the primary gating factor.
OK, Here are some more results. peddy and I did some tests this morning.
By formatting the card with 32K allocation units, the test runs in about 13 seconds. It does not seem to matter whether it is fat16 or fat32. Let’s say we get about 70KB/Sec with this test.
However, running the same test on a PIC32 using an SPI interface also takes about 13 seconds on the same card. So the issue now is, how do we get the speed benefit of a 4 bit interface? So far, the Fez code is no faster than SPI. What can we be doing wrong? We are certainly not seeing 200K or better.
I am certain we will get this solved. I hope it will be soon. You guys are great.
Stay tuned guys…we should have some good news. I can’t say more
Please see:
http://www.tinyclr.com/forum/1/1858/
Firmware is in Beta page.
Note that this is not a full SDK just a new USBizi firmware. So you need the full non-beta SDK first and then download the beta firmware.