> [why txallowed]
Consider this scenario: First write to DR fills the Tx buffer. SPI starts to transmit, the Tx buffer is thus empty, if txallowed is not checked, second write goes to the buffer. Then an interrupt cuts in, lasting longer than it takes to transmit both bytes. The result is, that there is one correctly received byte, and the second - as it finishes receiving before the first one has been read out - overflows and gets lost.
It's an afterthought and it prevents the Tx buffer to be used effectively. Because of the underlying problem (ie. that receiver can't hold 2 bytes at once), the possibility of utilizing the Tx buffer in polled implementation is limited, nevertheless better solutions are possible but would require rethinking how the routine works. Rewriting it in asm would probably help, too. Or, interrupts would need to be disabled, but then there goes universality (and still things like collisions with other busmasters would need to be considered, too).
> That is 134 CPU clocks
> I can't see anything in that code taking more than roughly 1/10 of that
That you can't see it, does not mean it does not exist. Maybe you should look harder.
> and anyway most of it is pipelined behind the UART shifting the bytes in/out.
I don't know what does this mean.
But you should stop using "UART" for the shift register (even USART is not approriate in this case, IMO).
> Looking at the disassembly shows roughly 4-5 assembler instructions for each C line which is nowhere near enough to use up that many CPU clocks.
Show.
For example, this
if ((__HAL_SPI_GET_FLAG(hspi, SPI_FLAG_TXE)) && (hspi->TxXferCount > 0U) && (txallowed == 1U))
is likely to amount to 3 C lines, so maybe a dozen of instructions. And they don't execute in one CPU clock each. For example one of the first of those instructions reads from the SPI status register. That means, that the read request has to traverse the AHB-to-APB bridge and the data traverse the same bridge in the opposite direction. This is likely to last one to three APB cycles plus some AHB cycles, and given this is the "slow" APB at 1/4 of AHB, it means maybe a dozen of system cycles. And still the given flag has to be separated (maybe masked) and a conditional jump has to be performed.
I took your function and got it running on an 'F429 Disco at 180MHz system clock. And inserted the pin toggling (used the green LED on the Disco):
while ((hspi->TxXferCount > 0U) || (hspi->RxXferCount > 0U))
{
PIN_SET(GREEN_LED);
/* Check TXE flag */
if ((__HAL_SPI_GET_FLAG(hspi, SPI_FLAG_TXE)) && (hspi->TxXferCount > 0U) && (txallowed == 1U))
{
*(__IO uint8_t *)&hspi->Instance->DR = (*hspi->pTxBuffPtr);
hspi->pTxBuffPtr++;
hspi->TxXferCount--;
/* Next Data is a reception (Rx). Tx not allowed */
txallowed = 0U;
}
PIN_CLR(GREEN_LED);
/* Wait until RXNE flag is reset */
if ((__HAL_SPI_GET_FLAG(hspi, SPI_FLAG_RXNE)) && (hspi->RxXferCount > 0U))
{
(*(uint8_t *)hspi->pRxBuffPtr) = hspi->Instance->DR;
hspi->pRxBuffPtr++;
hspi->RxXferCount--;
/* Next Data is a Transmission (Tx). Tx is allowed */
txallowed = 1U;
}
}
The compiler decided to do the green LED GPIO_BSRR writes from registers, so those are truly single-cycle and don't impact the total timing too much.
Following is disasm of the portion where RXNE is tested and SPI->DR written, that together with the test at the beginning of loop lasts cca 300ns/55cyc, it's around 25 instructions. Given there are two reads from the slow APB bus included (amounting to perhaps two dozens of cycles), I think this is entirely justified (btw. all memory reads/writes go from/to the CCM, so they *are* single-cycle):
PIN_CLR(GREEN_LED);
8000342: 6184 str r4, [r0, #24] // write to GPIO_BSRR for LED to go down
/* Wait until RXNE flag is reset */
if ((__HAL_SPI_GET_FLAG(hspi, SPI_FLAG_RXNE)) && (hspi->RxXferCount > 0U))
8000344: 689f ldr r7, [r3, #8] // read from SPI_SR
8000346: 07ff lsls r7, r7, #31 // check bit 0
8000348: d50f bpl.n 800036a <main+0x132> // jump to beginning of loop, if not set
800034a: f8b2 8012 ldrh.w r8, [r2, #18] // read RxXferCount
800034e: fa1f f788 uxth.w r7, r8 // extend to word (RxXferCount is uint16_t)
8000352: b157 cbz r7, 800036a <main+0x132> // compare-to-zero-and-branch
(*(uint8_t *)hspi->pRxBuffPtr) = hspi->Instance->DR;
8000354: 68ce ldr r6, [r1, #12] // read pRxBuffPtr
8000356: 68db ldr r3, [r3, #12] // read SPI->DR
8000358: 7033 strb r3, [r6, #0] // write to *pRxBuffPtr
hspi->RxXferCount--;
800035a: 8a4e ldrh r6, [r1, #18] // read RxXferCount
hspi->pRxBuffPtr++;
800035c: 68cb ldr r3, [r1, #12] // read pRxBuffPtr (yeah gcc is not the brightest compiler out there)
hspi->RxXferCount--;
800035e: 3e01 subs r6, #1 // decrement RxXferCount -- the reorder is here probably in hope that processor can perform math on r6 while the previous read of r3 gets finalized, but Cortex-M4 is not superscalar
8000360: b2b6 uxth r6, r6 // and extend to word (again this might be optimized out by compiler)
hspi->pRxBuffPtr++;
8000362: 3301 adds r3, #1 // increment pRxBuffPtr
hspi->RxXferCount--;
8000364: 824e strh r6, [r1, #18] // store RxXferCount
hspi->pRxBuffPtr++;
8000366: 60cb str r3, [r1, #12] // store pRxBuffPtr
txallowed = 1U;
8000368: 2601 movs r6, #1 // set txallowed (it's kept in register)
while ((hspi->TxXferCount > 0U) || (hspi->RxXferCount > 0U))
800036a: 8953 ldrh r3, [r2, #10] // and this is the beginning of loop (compiler physically placed it at the end)
800036c: b29b uxth r3, r3
800036e: b913 cbnz r3, 8000376 <main+0x13e>
8000370: 8a4b ldrh r3, [r1, #18]
8000372: b29b uxth r3, r3
8000374: b1bb cbz r3, 80003a6 <main+0x16e> // jump out of the loop if both counts are zero
if ((__HAL_SPI_GET_FLAG(hspi, SPI_FLAG_TXE)) && (hspi->TxXferCount > 0U) && (txallowed == 1U))
8000376: 6813 ldr r3, [r2, #0] // this prepares hspi->Instance into r3
PIN_SET(GREEN_LED);
8000378: 6185 str r5, [r0, #24] // and here we set LED up again> And it would not surprise me if nobody had discovered this before, because the result works and if stuff works, nobody will be checking it with a scope
Well, nobody who expects code to perform, uses polling. Even more, this is Cube, i.e. a vehicle to sell chips to managers, certainly not a path towards producing good code. That path is long, arduous and expensive, so somebody has to walk it, spend the time and pay the price.
JW
