The SPI on the ADuC7xxx is designed for 8-bit transfers only, but a connected peripheral part needs a 16-bit transfer. How can this be assured. A FIQ exception does intercept the continuous transfer.
There are two possible solutions if in the system a delay of the FIQ can be accepted.
1.) implementation of the continuous 2 byte transfer to be handled in a FIQ exception handler
2.) disable the FIQ source (clear related bit in FIQCLR) during the transfer of the bytes into the SPITX MMR
The second solution causes usually a smaller delay to the FIQ exception handling if immediately after the second write to SPITX the FIQ source is enabled again (set related bit in FIQEN).
The newer parts as ADuC706x, ADuC7023, ADuC7124 & ADuC7126, have a 4-byte-FiFo for SPIRX & SPITX, so in this case the code can look like below:
FIQCLR = bit(s) to disable FIQ-source(s);
SPITX = 1st byte;
SPITX = 2nd byte;
FIQEN = bit(s) to enable again FIQ-source(s);
This can be extended to any number of bytes, but after the 4th byte the SPITX-FiFo-status need to be checked and causes additional delay related to the used SPI clock-speed. But for up to 4 Bytes (32 bit) this is the best way in my opinion.
For the other parts (ADuC702x, ADuC7019, ADuC7128 & ADuC7129) this is only possible if for each byte the SPITX buffer is checked to be transferred already to the SPITX-shift-logic - bit 0 in SPISTA MMR. For a 16-bit transfer (2-byte) this causes related to the used SPI clock-speed not much more delay to the FIQ handling.
And what is the maximum bit rate for the Aduc706x SPI raw transfer can be achieved? Thanks.
As can be calculated related to the formula in the datasheet on page 96, about 5.12Mbps. But depends on how you implement it in your SW.
Sorry, I talk about throughput or bandwidth. I get an SPI axample and set CD to 0 (to set 5.12 mbps SPI clock rate). Then I set continuous transfer and 4 bytes fifo length in SPICON.
SPICON = BIT0 + BIT1 // Enable SPI + Enable SPI Master
+ BIT6 // Clk pulses high at start of each bit + Initiate transfer on write to Tx FIFO
BIT11 +BIT14 +BIT15; //Continuous transfer mode + Enable IRQ on 4 byte transfer
SPIDIV = 0;
// Begin Master Transmit sequence
ucTxCount = 0;
IRQCLR = BIT12;
SPITX = szTxData[ucTxCount++];
SPITX = szTxData[ucTxCount++]; // Load Tx buffer
IRQEN = BIT12;
And as a result I see that actual clock rate is 5.12 mbps, but there are delays between transferred bytes about 2-3 microseconds, and moreover a large delay (about 5 us ) between pockets of 4 bytes (maybe interrupt latency) ....
So the overall throughput decreased significantly. Is this behavioral normal or some method for increasing SPI throughput exists?
See this post where you can get some assembly code for maximising the SPI baud rate.
The reson you see the delays between the bytes is because the core doesn't run very fast and the C code isn't very efficient at loading bytes into the registers, so the SPI hardware waits for new data and hence you get the delays.
I also see the reason in big spi status flag latency.
while ((SPISTA & BIT5) == 0);
It takes mcu 5-7 usec (aduc7061 10.24 MHZ) to set corresponding interrupt flag. So SPI with 4 bytes FIFO (and ping pong mechanism for loading FIFO) cannot run faster than ((4bytes/2)*8bit)/7us = roughly 2 Mbps.
Retrieving data ...