AVR Freaks

Maxim has appnotes about this, and AVR datasheets have too. For 1 start bit, 8 data bits and stop bits using 16x sampling, you have 10 bits total meaning 160 sample clocks.

Depending on microcontroller/uart/whatever, they may use majority logic features to sample three middlemost bits and use the value it sees at least 2 times, or they might just sample once in the middle.

In the middle is then 8 clocks from start or end of the bit because a bit is 16 clocks wide. So deviation of 8 clocks per 160 clocks would be the absolute theoretical maximum allowed error to sample the starting or trailing edge of stop bit. It 8/160 is 5%. In practice the sampling phases will differ and all kinds of tranceivers and transmission lines cause skew so the maximum error should be anyway around 4%.

That means either end can deviate up to about 2% of the nominal and it should still work. This is what AVR datasheets say as well.

Start bit is exactly 1 bit or it would not work. Stop bit can be as long as forever. The re-sync starts from the leading edge of start bit, and many microcontrollers have some kind of noise detection logic there as well, so the point where resync happens it is not so black and white. Then all bits are clocked in in the middle, the stop bit being the last. Stop bit needs to be sampled high, but in theory, after the receiver has sampled it, another start bit can be transmitted, so 8 clocks early is the maximum.

You don't say if you need the devices only to talk together or with other equipment like PC as well, but you must select a baud rate that has below 2% error, preferably less. If you use 1 start, 8 data, 1 stop, no parity. All this will be different if you use more or less bits.

Sounds to me if those are the frequencies and standard baud rates must be used and 16x sampling, then all you can do is 38400. 57600 might work if 8x sampling were available.

If non-standard baud rates are acceptable and the devices only talk to each other, you could use 76800 very reliably.

Maybe it has nothing to do with the uart. Maybe cpu2 is too busy sometimes to get data out of uart buffer fast enough. I would assume you are checking for overrun and framing errors, though. I don't think you are going to get 'screwed up' data (timing) without a framing error. No buffer overrun or no framing error on cpu2 = cpu1 probably not sending the missing bytes for some reason. You could also try using 2 stop bits for kicks.

A little mind-bender :)

I don't know how you would get a 'baud mismatch' where the rx end didn't end up with framing errors. Since the rx end is not getting errors, the rx must be happy with the rate its seeing. It would be quite odd to have a baud mismatch that mattered without also seeing a framing error (at least with multiple bytes incoming, anyway).

On the original question-
I suppose it depends on when the rx starts checking for a start bit on back-to-back bytes- either at the end of the stop bit, or when it 'checked' the stop bit 'halfway' into the stop bit. If it needs to clock through the whole stop bit (8/16 baud clocks) before it starts checking for the next start bit, then baud rate errors would accumulate on back-to-back bytes (if tx faster than rx). Now, if you use 2 stop bits on the tx, I think the rx ignores the second stop bit (there is really nothing to see) and will then have some time to re-sync up to the next start bit, leaving any baud errors contained inside a single byte.

I think.

I fail to see what the problem is.

16MHz AVR can do 115200 baud with U2X bit.
14.756MHz AVR can do any baud rate you like even with its hands tied.

Simply choose your baud rate. Set UBRR correctly for each AVR and away you go.

You will probably benefit from a proper interrupt service routine. There are many good library examples.

There are also many appalling examples (judging by what we see here)

David.

I am still confused. All the 8-bit microcontrollers that I have ever come across tend to have F_CPU/16 somewhere in the calculation. Albeit with an extra div4 or div12 to account for cycles per operation.

Yes, I suppose that you can choose some non-standard baud rate that satisfies both F_CPU/16 values. Life is generally simpler if you stick to conventions.

I suspect this problem really comes down to using sensible ISR(RXC), rx_avail() and getchar() functions.

With a 14MHz AVR and a respected compiler, full-speed 115200 baud should work just fine. (unless you have serious ISR() loading from higher priority vectors)

Bear in mind that 115200 baud with U2X is reliable with a hard-wired connection. 57600 baud with 16x sampling would be safer for a 'noisier' link.

David.

Your crystal ball needs a tuneup. :)

My crystal ball has just been serviced, it says 'Arm7'.

Thousands and thousands of bytes coming in, and not a single framing error. Nothing wrong with getting the baud rates matched as close as possible, but in this case 'these aren't the droids you're looking for, move along'.

Obi-Wan spoke the words, I just quoted them. (Also remember, that those WERE the droids they were looking for.)