AVR-Chat

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