Ryan wrote:
> Thanks for the reply. So it sounds like what I would want to do is
> create a startup loop that checks the RS232 for characters, and when
> it receives them, have it stuff the needed ones into EEPROM. Do I
> need to worry about things like checksums for the data? I really am a
> newbie when it comes to RS232. I don't want the EEPROM getting
> garbage and blowing things up.
Well, it sounds like you only have a few "mode bytes"; if you make sure
that the data is sane before writing it to EEPROM it would help.
Because it's very common to have initial garbage characters on
connection or power-up, you should have a recognizable character
*sequence* that introduces your mode bytes. Ideally you have a handshake
too.
Assuming that you're going to write a BASIC program for the sending end,
it would make sense to have a checksum on the whole packet.
Even the weak 8-bit checksum (as opposed to a 16-bit CRC) is typically
enough, even though it can sometimes miss errors (after all, you have a
1/256 chance of getting the wrong character for the checksum itself).
You can make the whole process stronger by receiving *and* sending
characters to make sure that both ends are in sync.
For instance, look at the following hypothetical example. In it, SOH,
ACK, NAK, STX, ETX are constant byte values; their values are
unimportant, though ANSI X3.4 (often called ASCII) defined values for
them back in the ancient days of teletypes. Also, DC2 introduces the
"hello" message and DC4 introduces the "eeprom" message. (note that the
ANSI DC3 and DC1 codes are sometimes used as XON/XOFF characters for
serial line handshaking; this shouldn't matter to you, since you'll be
turning that interpretation off at the PC end). Note that this
particular protocol has quite a few unnecessary bytes for the purpose of
error detection. For instance, framing the message content in
<STX>..<ETX> bytes lets you make (relatively) sure that you're seeing a
byte sequence that's intended as a message. The <cksum> here can be
something as simple as the modulo-256 sum of the bytes (that is, add
together their values and then use (sum mod 256) as the result. I often
use the inverse or negation of the checksum to make it a little quicker
to detect at the micro end.
PC sends "hello" message till it gets a proper acknowledgement:
PC: <STX><DC2><ETX><cksum>
AVR: garbage, maybe...
PC: <STX><DC2><ETX><cksum>
AVR also got garbage, maybe, so sends a NAK:
AVR: <STX><NAK><ETX><cksum>
PC tries yet again:
PC: <STX><DC2><ETX><cksum>
AVR responds with an ACK:
AVR: <STX><ACK><ETX><cksum>
PC sends bytes for eeprom:
PC: <STX><DC4><b1><b2><b3><ETX><cksum>
AVR acknowledges:
AVR: <STX><ACK><ETX><cksum>
I've designed lots of serial protocols; there are a number of tricks and
ways you can make them better. It's an engineering tradeoff: you have to
balance the cost of bad communications (trashed EEPROMS? warranty
returns? injured/dead humans[1]?) vs. the cost of doing a good job (more
code and development time; slower communications) vs. the probability of
bad comms.
One thing that helps is to monitor the framing error detect bit (FE, bit
4 of UCSRA) and the data overrun bit (DOR, bit 3) in the USART status
register. Parity can also help, but if you use it, you have the added
complication of either dealing with 7 bits of data per character, or
figuring out how to do 9-bit communications on both ends.
Read the datasheet section on the USART.
> Secondly, after everything gets updated, can I reconfigure the PD0 and
> PD1 (rxd and txd) back into outputs? I'm not sure if they can be
> changed on-the-fly in the middle of a program.
Sure. You can initialize them as outputs (in the DDD register), then
turn on the RXEN and TXEN bits in the UCSRB register. This will override
the data direction settings in DDD1 (for TXD) and DDD0 (for RXD). Note
that you can enable the internal pull-up for RXD by setting the PORTD0 bit.
> I'm currently working with bascom for my sanity... Grew up with
> basic, so it's almost like a comfort food. :)
I grew out of BASIC around 1976, though I occasionally have to read it.
Since there never was a standard for it, each version is a different
language.
Good luck!
[1] note: it is a bad idea indeed to use simple async communications in
safety-critical applications because it's so hard to detect hardware
problems until you need to communicate; also, never rely on software
alone in a safety-critical system (always have redundant hardware
monitoring things, or at least a separate, different software system
using redundant sensors)!
--
Ned Konz
ned@bike-nomad.com
http://bike-nomad.com