There is generally a difference between randome read/write speeds and continuous read/write speeds; Perhaps this is causing the difference?
Also, looking at your main code, it seems like you are checking the getUpTime() before running some operations, perhaps this is causing a delay in data being written/sent?
It looks like you are using a 64int to hold your time difference, keep in mind that if this rollsover, it will screw up your calculations and give invalid values.
Maybe change your test to run for a fixed amount of time, and see how much data/number of writes you can run in that period, and extrapolate it out to data/second?
Thanks for the suggestion. the getUpTime() is just reading off my global variable counter value in timer.c. You see find it in the interrupt handler for the 1ms timer. It's volatile / non-optimized, so the value should be accurate enough for my calculation.
Yeah, I was using a uint64 for timekeeping and I typecasted all of my values to ensure it's uint64. So I shouldn't get rollover issue, unless I'm mistaken. I think, at most, my result is slightly off since I did a division with 2 integers, but should still be within reasonable accuracy.
I also took your advise and did a data transfer for 20s. This was my result: 4628480 bytes written with 231 kB/sec. Not much different. Sigh. What else am I missing?
Huh, yeah; I guess I should have found that function in the timer pretty easily >.<
Yeah, you're probably fine on the rollover issue, but it was a thought :)
Hmmm, if you're getting the same results with a sequential data transfer, then it shouldn't be the access time varying based on the chip silicon then. One thing of note is that when I open your project in PSoC creator 4.1 it lists the chipset CYBLE-222014-01 as being trimmed from the cypress catalog. This could mean that either they had alot of issues with the chipset, or ran out of the parts for it.
Some thoughts: under sdcard.c the function wait_ready() is waiting with 100 us delay between polling, potentially decreasing this polling time (while keeping the timeout time the same) might increase your data rates by reducing the latency on the sd card ready signaling.
Same with rcvr_datablock(),xmit_datablock(),aend_cmd(), etc. If there are delays in the software, then it could be a delay caused by the software waiting for signaling when it doesn't need to. Basically, the less delay operations or the smaller the delay operations you can have, the more responsive/faster the SD card functions should go (assuming the delays aren't necessary or can be replaced with hardware signaling/polling)
There are about 20~ delay operations for the SD card, mostly for a single millisecond delay; I would try removing those and seeing if that works. They seem to be used for handling multiple devices on the same hardware bus?
Plus, based on your comments of "why?" I would guess that they serve no visible purpose.