1
\$\begingroup\$

I have an ATmega328P-PU on a breadboard,

The Breadboard

and I am trying to get serial communications working through one of these bad boys:

FTDI breakout front FTDI breakout back

The 328P is loaded with a modified blink sketch that just does a Serial.print() at the end of each iteration.

int led = 13;
int count = 0;

void setup() {
  pinMode(led, OUTPUT); // initialize the digital pin as an output.
  Serial.begin(9600);
}

void loop()
{
  count++;
  for (int i = 0; i < 2; i++)
  {
    digitalWrite(led, HIGH);
    delay(150);            
    digitalWrite(led, LOW); 
    delay(150);          
  }
  delay(350);      

  Serial.print("abcdefghijklmnopqrstuvwxyz");
}

The good news is that I am getting something, but the bad news is that it's all garbled.

Here is an example from Linux command line of the stuff I am getting. I also see similar garbled output through Arduino's serial monitor and minicom as well:

$ (stty 9600 cs8 -parenb -cstopb;od -a )<  /dev/ttyUSB0
0000000 ack ack   `   f   ` ack   x   f ack   x   ~ ack  rs ack  rs can
0000020  rs  rs  rs   `  rs   f  rs   x  rs   ~  rs nul   f ack   x   f
0000040   x ack   ~   f ack   ~   ~ ack   f ack   ~   ~ ack ack   `   f
0000060   ` ack   x   f ack   x   ~ ack  rs ack  rs can  rs  rs  rs   `
0000100  rs   f  rs   x  rs   ~  rs nul   f ack   x   f   x ack   ~   f
0000120 ack   ~   ~ ack   f ack   ~   ~ ack ack   `   f   ` ack   x   f
0000140 ack   x   ~ ack  rs ack  rs can  rs  rs  rs   `  rs   f  rs   x
0000160  rs   ~  rs nul   f ack   x   f   x ack   ~   f ack   ~   ~ ack
0000200   f ack   ~   ~ ack ack   `   f   ` ack   x   f ack   x   ~ ack
0000220  rs ack  rs can  rs  rs  rs   `  rs   f  rs   x  rs   ~  rs nul
0000240   f ack   x   f   x ack   ~   f ack   ~   ~ ack   f ack   ~   ~
0000260 ack ack   `   f   ` ack   x   f ack   x   ~ ack  rs ack  rs can
0000300  rs  rs  rs   `  rs   f  rs   x  rs   ~  rs nul   f ack   x   f
0000320   x ack   ~   f ack   ~   ~ ack   f ack   ~   ~ ack ack   `   f
0000340   ` ack   x   f ack   x   ~ ack  rs ack  rs can  rs  rs  rs   `
0000360  rs   f  rs   x  rs   ~  rs nul   f ack   x   f   x ack   ~   f

I have used using Nick Gammon's Atmega_Board_Programmer sketch to successfully write the bootloader, notably trying a couple of different fuse configurations (with and without the divide-by-8 bit), but the result is always the same: garbled junk. Well actually, when dividing by 8 the blink was super S L O W and obviously not right.

Would appreciate any feedback or ideas on avenues to explore. What settings to tweek? Is the circuit reasonable?

EDIT / UPDATE

Based on MarkU's suggestion, I successfully ran my modified blink sketch on an Arduino Uno. By doing that I also verified that the FT232RL breakout board works as expected. I also noticed that on the Uno the blink sequence seemed to be faster than the same sketch running on my breadboard. Hmmm...

So set up the breadboard again, getting garbled output. Then, thinking of the slower blink as compared with running on the Uno, I changed the baud rate on the Linux side 9600 -> 4800. Hey! It's not garbled anymore!

The sketch thinks it is sending at 9600, so it looks like I am off by a factor of 2 somewhere. Is my crystal 4 MHz instead of 8? I didn't notice any fuse or other settings that would change timing by a factor of 2.

enter image description hereHere's what I think the problem is: I'm compiling with the target board set to "Arduino Uno," which I believe this uses a constant F_CPU = 16000000UL. Then I upload to my breadboard which is running an 8 Mhz oscillator, half the expected value.

\$\endgroup\$
  • \$\begingroup\$ What's the IC on that "bad boy"? Or even better: What is that "bad boy" - Ordernumber? Also, what's the type of quartz you're using? \$\endgroup\$ – Tom L. Apr 1 '15 at 5:08
  • \$\begingroup\$ Breakout board has FTDI 232RL, looks the same as the Folger Technologies linked to by MarkU below. The crystal is Crystals 8.0MHz 18pF Fund. -20C (mouser.com/Search/…) \$\endgroup\$ – Steve Apr 2 '15 at 4:59
2
\$\begingroup\$

The fact that you are getting something indicates to me that there might be something wrong with your expected vs actual clock. Is there a pin on which you can measure the clock? Did you define your crystal/frequency correctly as is required by the serial library you are using?

\$\endgroup\$
  • \$\begingroup\$ Just using the stock Serial.print() calls from the Arduino 1.6.1 library. Did a few Google searches, but I'm not aware of a way to specify frequency with this library. Will get ahold of an oscilloscope and see what's going on on the XTAL1/2 and TX pins. Thanks for taking the time to respond. \$\endgroup\$ – Steve Apr 2 '15 at 5:24
  • \$\begingroup\$ No Problem. Hope you get it sorted. Thanks for the tick, now I can add comments. Yay \$\endgroup\$ – AJBotha Apr 8 '15 at 9:57
1
\$\begingroup\$

That blue board looks like a variant of Sparkfun USB to Serial Breakout https://www.sparkfun.com/products/12731 using the FTDIchip.com FT232RL in 28SSOP package. This particular board appears to be Folger Technologies http://folger-technologies-llc.myshopify.com/products/3-3v-5-5v-ft232rl-ftdi-usb-to-ttl-serial-adapter-module-for-arduino-mini-port?variant=823021539 They don't talk much about the board's specs, but it's probably just about like all the other FT232R USB breakout boards.

FT232R datasheet available from manufacturer: http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232R.pdf

Verify the cmos/ttl TX transmit output from ATmega328 is driving the cmos/ttl RX receive input on the FT232R, and the cmos/ttl TX output from FT232R is driving the cmos/ttl RX input of ATmega328. (The most common mistake with serial UART is connecting TX to TX.)

At 9600 baud (8 bits, no parity, 1 start bit, 1 stop bit), each character takes 10/9600 = 1.042msec to transmit, and 26 characters should take about 27msec. Can you beg/borrow an oscilloscope to look at the TX signal? That's about the only way to figure out what's happening here.

I've never seen a high frequency crystal oscillator ever work on a white solderless breadboard -- there's often significant parasitic capacitance that causes undesired loading effects at higher frequencies. You might want to consider (dare I say it?) trying your firmware on one of the commonly available Arduino boards -- since you already know more about electronics than the target Arduino user, you can load your own custom firmware, you don't have to use their IDE / bootloader / shields / etc. Having a tested/true PCB layout should perform better than a solderless breadboard. Sparkfun sells an Arduino Pro Mini 328 that has a much nicer form factor, that you could actually plug into a breadboard, but that has the crystal oscillator circuit on a PCB layout. https://www.sparkfun.com/products/11114

\$\endgroup\$
  • \$\begingroup\$ Appreciate the reply. I've got RX crossed over to TX (tried it the other way, but then I get nothing). Sounds like a scope is the next order of business. \$\endgroup\$ – Steve Apr 2 '15 at 5:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.