Atmega8/168 serial connections

Dear friends,

I tried to connect both an Atmega8 and an Atmega168 uC to the serial port of my computer and I have the same results: just squares. Let me detail the problem:

I used a simple Arduino sketch: Serial.begin(9600) in setup() and Serial.print (sensorValue); delay (1000) in loop(). I did not used an external crystal, just the internal of both uCs. I used the schematic provided by sparkfun, found here Beginning Embedded Electronics - 4 - SparkFun Electronics, but connected a capacitor from 2 to ground and one from 6 to ground, in the 232 IC. I made the connections correctly, checked and double checked them. I used 3x1,5 batteries to power the chips.

I tried both hyperterminal (where I did not receive anything), and the serial monitor of the Arduino IDE, where I receive only squares, at a second (see the delay) interval. I also tried Teraterm and I had the same results.

I have Windows XP and I do not know other programming languages for the AVRs, except Arduino IDE and Processing.

What am I missing? Can any of you who tried this post some schematic with an AVR and the MAX232? Is it the code (which, as you guessed, works perfectly for an Arduino board) ?

Thank you very much for your patience.

What sketch?

Possibly the divide-by-8 fuse is set. Try uploading the Blink sketch (set to blink every second) and see if the LED does in fact blink every second.

It doesn't. Actually, I think delay(1000) is aproximately 8 seconds, if I correctly measured with the oscilloscope. Can this influence the serial transmission?

What about the schematics, was it ok?

Thank you again.

Can this influence the serial transmission?

Certainly it would. Everything would be 8 times too slow. Unless you particularly want it to run slowly use avrdude to change the fuse setting.

First read the setting and report what it is.

Just to confirm, connect at 1200 baud in your terminal. Since that is 8 times slower than 9600 you should see some output.

I set the baud to 1200 in terminal and:

  1. Hyperterminal gave me "f"s every second, instead of the temperature (that was my sketch about);
  2. serial monitor in Arduino IDE returned random characters (not squars this time, but random ASCII) every second.

So I guess it is not the clock?

Try 600 baud.

Dear Sir,

I tried 600 baud in TeraTerm (Arduino Serial Monitor and HyperTerminal do not allow this baud rate) and I succeeded, it works. I also tried it with a sketch in Processing which listens to the serial port at a given baud rate and it also works.

What is the solution to use the actual baud rate I set in the sketch (9600)? For my present projects, even 600 is ok, but I am interested for the future. I am a little afraid to go by myself in the fusebits section, as I think I permanently damaged an Atmega168 by doing that.

Thank you again!

claudiu_mirescu:
I set the baud to 1200 in terminal and:

  1. Hyperterminal gave me "f"s every second, instead of the temperature (that was my sketch about);
  2. serial monitor in Arduino IDE returned random characters (not squars this time, but random ASCII) every second.

So I guess it is not the clock?

If your 1 second delays is 8 seconds then it's the clock, no doubt. And the divide by 8 fuse is set by default so you have to change it.
Just to be sure, you have selected the "Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega168" board when programming the atmega 168 right?

If it works at 600 baud (which is 1/16th of 9600) then clearly two things are true:

  • Your processor is running at 8 MHz (not 16 MHz)
  • The "divide clock by 8" fuse is set

This is actually the default way the chips are shipped so this is no big surprise.

I suggest you fix the fuse. See here:

http://www.engbedded.com/fusecalc

You can find the correct setting for the LOW fuse there.

However if you want to play it safe, just tell the sketch to use a faster baud rate. For example, if you double the rate in your sketch, you double rate in the serial monitor. Also be aware that timings (from delay, millis etc.) will be 16 times as slow. You could compensate for that.

Settings the fuses can be done in AVR Studio (with a GUI) so the change of you doing anything wrong is more or less non existing.