|
|
| Author |
Message |
spamiam
Joined: 13 Nov 2005
Posts: 665
|
|
Posted: 16 September 2006, 1:55 AM Post subject: SPI speed for SPICmd() |
 |
|
Back in March there was a discussion of the speed of SPI transmission.
Don Kinzer said | Quote: | | inspected the CS, SCK and MISO lines using a logic analyzer. The timing was 1 byte approximately every 5.4uS (185KB/s). |
He then went on to say that he might be able to optimize further.
I was looking at the MOSI pin during this command
SPICmd(1,100, MemAddress(OArray),0,0)
I had initialized the SPI channel to run at the fastest speed possible, 7Mhz
I got a pretty nice looking speed. 1.1uS for 8 bits, then a delay of 0.8uS before starting the next. This shows an average of 1.9uS per byte or 526K Bytes per second, or an average of 4.2M bits per second. Not too shabby.
1.9uS is a big improvement from what Don reported back then of 5.4 uS per byte. (admittedly, I am measuring id differently from how Don did it). He thought he could get it down to 2 or 3 uS per byte. It looks as if he succeeded.
This means that software SPI access is just about as fast as ANYTHING programmed on an AVR will ever do it, even in Assembler or C. Of course, the programming before and after might not be quite THAT fast.
-Tony |
|
| Back to top |
|
 |
spamiam
Joined: 13 Nov 2005
Posts: 665
|
|
Posted: 18 September 2006, 12:51 PM Post subject: |
|
|
I also did some tuning of the software mediated (bit-banged) SPI interface.
I managed to get a 45% improvement in the time it takes to send each bit.
I found that two calls to PutPin() to flip the clock pin is quite a bit faster than a single call to PulseOut() for the same duration of the clock pulse.
I also found it faster to use FlipBits() to reverse the bit order in the outgoing byte, then do a PutPin of the value of the outgoing byte AND 1 followed by a divide by 2 of the outgoing byte to get the next bit. This is compared with not flipping the bits and ANDing the outgoing byte with &H80 with an if-then-else testing the resulting value for a 1 or 0. This is followed by a multiply by 2 of the outgoing byte to get the next bit shifted to the MSB position
A couple of things were streamlined as well (in-lined some code instead of Calls, optimized variable usage, etc.), and overall I dropped the time by 45%.
I can now get about 5500 bits per second peak speed. there is an extra 1.3 milliseconds between bytes for overhead.
This is still about 1/10th the speed of the hardware SPI at its SLOWEST speed!
-Tony |
|
| Back to top |
|
|
stevech
Joined: 23 Feb 2006
Posts: 657
|
|
Posted: 19 September 2006, 0:44 AM Post subject: |
|
|
curious about app that needs that bit rate...
apologies if it's none of my biz-nez |
|
| Back to top |
|
|
spamiam
Joined: 13 Nov 2005
Posts: 665
|
|
Posted: 19 September 2006, 0:54 AM Post subject: |
|
|
| stevech wrote: | curious about app that needs that bit rate...
apologies if it's none of my biz-nez |
Since I am a need-for-speed type of guy, the fastest bit-banged interface seems rather SLOOOOOOOW, but it works. Also, if you have a device that does not like to have access to other devices interleaved with its own access, then it might be NECESSARY to have the software SPI bus because you can't have sole access to the H/W bus on a ZX.
So far, I have only had luck with S/W SPI when interfacing with a SD/MMC card. I wanted as few variables as possible screwing up my access to the card. I am just about to try debugging my hardware SPI interface as soon as I get back my disposable SD card. I don't want to risk one of my "real" cards on my cobbled-together breadboard wiring.
I will be very interested to see if the MMC card will share the bus. It did not appear to like it when I tried before, but other factors might have interfered. E.G. I was running the SPI bas at top speed (Fc/2). I now see that the stray capacitance of my breadboard might be deforming the waveforms enough to mess up the commumication.
I will now be testing the system at the SLOWEST speed (Fc/128). That might make a difference. Plus I will be using the functioning interface and simply replacing the subroutine that makes the actual SPI access. Of course it can't be quite that simple a change-over, but I am trying hard to make only the absolutely necessary changes.
-Tony |
|
| Back to top |
|
|
|
ZBasic Home
Forum Rules
Memberlist
Usergroups
RSS Feed
Site Search
Links
Download
Digests and Subscriptions
Profile
Log in to check your private messages
Log in
Register