This reminds me of an unfortunate bug I was debugging the other day that had the same solution but a different problem on different hardware.
Here's the setup: I have a weird SPI device that has two different CS lines: one for accessing the control registers, and one for accessing the data buffer. Because of this, I have to handle CS manually and can't just let the SPI peripheral handle it. Fair enough, not a big deal. So I pull CS low, stick some data into the output register, and wait for TX_BUSY to go to 0 (i.e. done transmitting). Unfortunately, TX_BUSY goes low after the rising edge of the last bit, but before the falling edge of the clock back to idle. Despite the device saying that it's active on the rising edge of the clock, it totally disregards input data if CS goes back to idle before the last falling edge of the clock.
Solved by adding some nop cycles. Easy to count how many are necessary because the peripheral and CPU are deterministic as described in the article, but damn what a debugging nightmare.
DMA is nice, no doubt, but it's not the ultimate solution to every problem. Have a look at my problem above... DMA wouldn't have helped. In fact, I'd probably have ended up starting with a DMA implementation, reverted back to a non-DMA implementation while debugging, and then would have stuck a bunch of nops into the DMA interrupt to make sure that I waited enough cycles before de-asserting CS.
Here's the setup: I have a weird SPI device that has two different CS lines: one for accessing the control registers, and one for accessing the data buffer. Because of this, I have to handle CS manually and can't just let the SPI peripheral handle it. Fair enough, not a big deal. So I pull CS low, stick some data into the output register, and wait for TX_BUSY to go to 0 (i.e. done transmitting). Unfortunately, TX_BUSY goes low after the rising edge of the last bit, but before the falling edge of the clock back to idle. Despite the device saying that it's active on the rising edge of the clock, it totally disregards input data if CS goes back to idle before the last falling edge of the clock.
Solved by adding some nop cycles. Easy to count how many are necessary because the peripheral and CPU are deterministic as described in the article, but damn what a debugging nightmare.