AVR Freaks

You are supposed to wait when the data register is full..... so when it goes empty, you can stuff in another char. Are you waiting while its empty?

Your processor crystal/oscillator may be off.

For example, your crystal may not be designed to work with the caps you actually have.

You may have more capacitance than you expect on one or more pins due to wiring, protoboard, etc. By the way, protoboards have a LOT of capacitance at each socket pin.

Most processor crystals are spec'd somewhere in the range of 50-100ppm (with the expected load capacitance). 100ppm is one part in 1E-4 or 0.01%, so that should not be an issue, again with expected load capacitance.

Excess capacitance should result in the oscillator being LOW in frequency. This would manefest itself in requiring a smaller divide number for correct operation.

Jim

But your speed may still be off!

The internal oscillator is nominal!

Did you check what speed the oscillator is ACTUALLY running at?

Are you aware that even with the OSCCAL byte loaded the internal oscillator will vary with temperature and supply voltage?

Lee

Hello every body,
I went through the first query and was agast to see a huge number being passed to the _delay_loop_2 function. A little bit of reading of the function proto type clearly shows that it can take only an unsigned int, meaning the value must not exceed 65535 (0xffff). If a larger value is passed the actual number that will be loaded will be less 65535. As an eaxmple if you pass 65538, the actual number loaded will be 2! and hence your delay will not be as expected.

Now here is the sample code for serial communication which should work.
I am using an Atmega128 and serial port 0

code for initialisation of the port

[/code]
void usart0_init (void)
{
UBRR0H = 00;
UBRR0L = 23; // this is as per page 180 .pdf file of atmega128. I am using a 6.39 Mhz crystal. You may change this to suit your crystal/clock

UCSR0B = 0x18; // enable receive and transmit
UCSR0C = 0x06; // no parity and that stuff
}

to send a NULL terminated string

void usart0_transmit (unsigned char *cptr)
{
while (*cptr)
{
UDR0 = *cptr++;
while (!(UCSR0A & 0x40)); // wait here for transmit complete signal
UCSR0A = 0x40; // clear the bit for next char
}
}

This will go at full speed (9600) till the end of the string.

}[code]

Well I hope this helps.
Regards

Hi Henk,

I had a quick question. What happens if you change the order of the bytes you are sending - i.e. start with EE, then DD, to AA.

The timing should restart for each byte that is sent out. You shouldn't see cumulative errors over byte sequences. The errors should only accumulate over the bits of a single byte. That's true for every transmitter and receiver I've ever seen. Each byte stands alone.

I'm curious how you have the actual electrical connections made. Are you driving real RS-232 through a driver chip/circuit or are you driving something directly.

Reason I ask is I'm wondering if there are hardware issues of some kind afoot here. Once you start sending, maybe something starts heating up, or a cap drains down, etc.

Just some thoughts...