|
Implementation
Interruptions
Interruptions are
mapped on memory. What we do is to put our
function handler address in the memory address
corresponding to the interruption, so when it occurs,
our function will be called to handle it. The code is
below:
#define
Int_Handler(RCX_Vector_Addr) ( *( void (**)(void) ) (RCX_Vector_Addr)
)
#define ERI_Interrupt Int_Handler(0xfdb4) /* Receive
Error */
#define RXI_Interrupt Int_Handler(0xfdb6) /* Receive
End */
#define TXI_Interrupt Int_Handler(0xfdb8) /* TDR Empty
*/
#define TEI_Interrupt Int_Handler(0xfdba) /* TSR Empty
*/
Communication
There are several ways to send/receive
data. In the RCX we have identified interruption based
and polling.
Polling means that once in a while
something has to be checked to know if there is
something new.
Interruptions occur when some event
happens. The CPU stops doing what it is doing to
handle the interruption.
Both have advantages and disadvantages,
we will not discuss it here.
Receiving
In our tests, receive using
interruptions worked fine, and we think it's better
than polling because the device is able to receive
data at any time, not only when the function is
running (also called busy receive).
In our implementation, data is
received using interruptions and stored in a buffer.
When the function receive is called, it gets the data
stored in the buffer.
Sending
To send data, we will use polling.
Interruption based send is a little more complicated
than receive because the function has to wait some
time for the data to be completely sent. It can be
done by busy waiting (like while (sending);) or
by a time interruption (time to send can be estimated).
Both things would just make things more complex, so we
chose to use busy send.
Other features
Error detection
When an error occurs we set some bits
in a variable. It detects parity, frame and overrun
errors.
Configuration
We set the communication to be
assynchronous, with no parity, using 2400bps baud
rate, with 8 bit data and one stop bit. The internal
clock source is 16MHz
|