Interfacing between Arduino & AVR Atmel168 w/ UART

I've got an AVR (atmel168) on a breadboard, spitting out results of an FFT, verified at 38400 baud using my terminal on the PC, both by connecting it through MAX232 RS232 interface and by using FTDI USB straight to the AVR's TX pin PD1. So I know that there is stuff coming out of the TX pin on the chip.

I want to receive this data with an Arduino, and print it to the screen to verify it works. So I have the TX of the AVR going to RX on the Arduino, and then using the template code from the Arduino site;

int incomingByte = 0;      // for incoming serial data

void setup() {
        Serial.println("Init Complete, waiting for data");

void loop() {

      // send data only when you receive data:
      if (Serial.available() > 0) {
            // read the incoming byte:
            incomingByte =;

            // say what you got:
            Serial.print("I received: ");
            Serial.println(incomingByte, DEC);

I've tried running it both at 9600 and 38400, but the problem is I never get any thing appearing on the screen. This means Serial.available() is never greater than 0. I've also got ground tied between the breadboard and Arduino just to make sure. Can anybody point me in the right direction?

Well, that's about as far off-topic as it's possible to get.

You need to connect the AVR and the Arduinos grounds together.

He already said he'd done that.

Could you maybe forget about serial I/O, and just use the Arduino to look for high-low and low-high transitions on the Rx pin? Maybe time them to check they're in the right ballpark? Or blink pin 13's LED (may require lowered bit rate)

Is the ATmega168 computing the FFT?! Pretty impressive.

This is where an oscilloscope comes in REALLY handy. I strongly suggest getting one if you don't already have one. It would take just minutes to verify that the signal is reaching the Rx pin on the Arduino.

It might be a slight (but large enough) baud rate mismatch. How stable is the clock source on the ATmega168? At 38400bps I've seen two AVR's fail to communicate with their USART's using their built-in oscillators, just due to normal variations in frequency. Maybe try 9600 or 4800 to see if it makes a difference.

Thanks for the info - I think the baud rate mismatch might be the culprit. Although it's weird I get absolutely nothing on terminal... save the starting up string I put in there.

I am using the built in 8mhz osc., I even tried it at 7387300 or whatever the number was for the even clock division baud rate calc. I'd like to find an external xtal at that freq. but don't think they make them. Tried it at 16mhz external xtal but my atmega just doesnt do anything at that speed... guess the fft freaks it out at that rate or something, will have to revisit that.

Will give it a go soon. The FFT algorithm is written in assembly by this guy, it's absolutely nuts what he does with the atmega8.

guess the fft freaks it out at that rate or something,

It’s something, processors are not known for, loosing their nerve no matter what code is being put through them. :wink:

OK so I gave it another go, I've just put on some basic UART code on the AVR that prints Test it! x =... taken from Sparkfun tutorial on UART output. It works fine at all bauds - I am using the Arduino serial monitor to display. Also am using the 16mhz external xtal now, as set in my fuses (low: E6 high: DF ext. 01).

I can read the serial from the AVR using my FTDI - I tried at 300 baud, nice and slow. Hooked up to Arduino on the serial monitor - again nothing. I'm pretty sure it's something with the Arduino that's acting funky, I might try and hook up a 2nd breadboarded AVR to see if it works as well.

Now for something interesting, I seem to be getting some data on a software serial port I set up at 9600 baud on digi pin 3, it's not formatted correctly but probably something I can work out. Any theories as to why software serial works but hardware UART isn't?

Can you draw a sketch of EXACTLY what is hooked up to where and through what chips? I'm wondering if you're not driving the Arduino with non-logic-level serial data....

aha I have discovered something interesting.

I got the hardware USART on Arduino working now with hardware USART on the AVR. Funny thing is, I disconnected the FTDI adapter from Sparkfun from the programing port pins and then plugged just the RX1 port on the adapter straight into the TX pin on the Arduino, and now I'm getting data out. Yes a bit ghetto but I know that it is in fact receiving the FFT results.

I'll try and attach an image - that shows how I set it up now. There's no need to connect grounds between devices, although these will be on the same control board with tied grounds anyways. If anybody is keen on the FFT code for atmega168 I can post it as well somehow.

It's something, processors are not known for, loosing their nerve no matter what code is being put through them.


Years ago, I worked on a PC that fit that description: lost it's nerve when things got to be too much. Turns out it had a defective math co-processor!

  • Brian