
SPI with a Blindfold On- speed up by letting go and trusting the machine - luu
http://wp.josh.com/2015/09/29/bare-metal-fast-spi-on-avr/
======
tonyarkles
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.

------
sannee
That's the cost one has to pay for using antiquated slow hardware which does
not even have DMA.

~~~
tonyarkles
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.

