Peter Mueller <peter.o.muel...@gmx.de> wrote:
> I have a question regarding the SPI interrupt handling. My
> understanding is that at the same time when a byte gets clocked into
> the receiver another byte gets sent from the sender.
>
True, but it's more like time a *bit* gets clocked into the rcvr, one is sent
from the txmtr.
> If Rx and Tx interrupts are active I should get two interrupt requests
> basically at the same time. Is this correct or do I misunderstand
> something?
>
Nearly: (read on)....
"Garst R. Reese" <re...@isn.net> replied:
> If that is the case, then it seems that you do not need the Tx interrupt
> at all,
> but could simply check the Rx buffer or vice versa, but I would expect
> this might be device specific.
>
I have done this, and I was caught by a subtle timing race. Basically, the
TX interrupt goes off on the leading edge of the last bit to be transmitted
but the RX interrupt would go off on the *trailing* edge of the last bit
received.
What I did once was to use a TX interrupt to reload the TX with its next byte
and read a byte from the RX straight afterwards. With a 5MHz crystal it
worked fine, but when I changed to an 8MHz crystal it all broke because the
byte I read was sometimes the *previous* byte, not the current one.
Basically, the last bit of the new byte usually hadn't arrived yet, so the SPI
port's buffer still contained the previous one.
The solution was to loop in the interrupt routine whilst polling the "RX full"
bit and read the rcvr only when the byte was really there.
The loop only goes around a couple of times of course, but it fixed everything
for me very reliably.
--
Steve Hosgood |
st...@caederus.com | "A good plan today is better
Phone: +44 1792 203707 + ask for Steve | than a perfect plan tomorrow"
Fax: +44 70922 70944 | - Conrad Brean
--------------------------------------------+
http://tallyho.bc.nu/~steve | ( from the film "Wag the Dog" )
