|
One of the morals I like is "Nothing works, untill
it is tested". Have you managed to send bytes over the serial interface?
Well, let's do a common test, the loopback test. We will send bytes from
our PC to our micro and our micro is expected to send the bytes back.
// Initialize USART 19200 baud
InitUSART(23);
while (forever)
{
// Send back the next ascii
TxByte(RxByte()+1);
}
After the code is down, place your serial cable, open hyperterminal,
whatever COM you are using, 19200 bits per second, 8 data bits, no parity,
1 stop bit and no flow control. Oh my God, my keyboard has gone mad.
Tip for the late hours, if you want to program your board
again and you have a single serial port, you will have to disconnect the
terminal from the serial port and place the cable back into your programmer.
Now, say you had no LEDs on your board and you wanted to
test the state of the button, what would you do? You could keep reading,
in the super loop, the state of the button and send a character to your
PC indicating state. Say "A" for pressed and "B" for
not pressed. The ascii table might be handy. Simple? Please try it. Not
to forget, add a descent delay in the loop, get an appreciation of what
a descent delay should be here. What if you don't put a delay at all?
You would send bytes to your PC too fast. Has your PC crashed yet? hehehehe
your OS is not very clever huh?
One think to point out here is that these routines are not
very intelligent. We have to be carefull when we use them, say for example
that you are running a long delay and at the same time bytes come from
the PC. What will happen? These bytes will be dropped, our micro will
keep looping in the delay and will not handle communication. So, avoid
byte bursts for now, both sides.
In case you are wondering, the best way to handle communication
is with interrupts. Asynchronously with the program flow, bytes may be
sent or received. If you want to get into it look at the AVR app. notes.
We will leave it for now cause we have what we need.
|
