Go Down

Topic: Pro mini 3.3v 8 Mhz 115200 baud issue (Read 8850 times) previous topic - next topic


Hi everybody.

I'm trying to communicate with my arduino pro mini (3.3v 8 mhz version) at 115200 bauds from my PC using a FTDI 3.3v from sparkfun.
Every byte arduino sends is OK, but when receiving, if i send, for example, 4 bytes in a row from the PC, only the first byte is readed ok. The next 3 bytes are readed as "garbage", but always the same "garbage", not random data.

of course, if I try it at 57600 everything is fine, and also if I try 115200 on a 16 Mhz arduino everything is also fine.

Another point. If I change PC serial port configuration to 8n2 (2 stop bits) it works....  it seems like the extra stop bit gives time to the Arduino to correctly proccess the incoming data.

Any know solution to this? If been reading posts for hours without success...

Thnak you in advance.


It sounds as if the nearest clock divider ratio for 115200 baud when generated from 8MHz is out of range - this may be inevitable since the divider ratios get smaller for high baud rates.  You could try non-standard baud rates at the PC end of the connection in case that helps (try increasing and decreasing in about 5% amounts).

Looking at the code in HardwareSerial.cpp suggests that only baudrates that divide 1,000,000 to yield an odd number are accurately represented, so perhaps try 200kbaud at both ends?  For the 16MHz case substitute 2,000,000 - divide by 17 gives 117.6kbaud which is close to 115.2kbaud.
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]



I think you are right. Error  -3.5% @ 8 mhz (111.111 baud) , while it's only 2.1% at 16 mhz (117.247 baud).

At 8 mhz arduino goes slower than PC, so maybe thats why it's late when it tries to read the second consecutive character. I've been peeking register values, and UCSR0A bit 4 (Frame error) is set after the second received byte. That's why with the extra time the second stop bits gives is enough to get In sync again.

I'll try to use the internal 8 mhz RC (as it can be tuned to 8.3 Mhz) for testing purposes, but I thing I'll have to change the resonator to make it work to (for example) 12 Mhz (115.384 baud possible -> 0.15 % error), so the timings are easier to adapt, and I think it will still run at 3.3 v.

Thank you for your answer!


The 'standard' serial baud rates are only a software convention these days, most hardware can support other values if you set the divider directly.  Also the SoftwareSerial library might manage better (or worse!).
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]


Everything OK now.

Changed the resonator to 12 Mhz and everything is working like a charm. (after recompiling the bootloader, of course).

It also worked fine with the internal 8 Mhz clock tuned a little bit up. Definitively was a timing error issue.

Thank you all!


I have the same problem with a Lilypad http://arduino.cc/forum/index.php/topic,57786.0.html

Can you explain me exactly what you did? I don't know how to change the clock.

Thank you,



To change the clock to 12 Mhz you have 3 things to do.

1.- Change the resonator to a 12 mhz one. This is the hardware part, and you need special tools to do it.
2.- Recompile arduino bootloader to make it work @ 12 Mhz (and program the ATmega with this new bootloader)
3.- You have to change the file boards.txt to tell arduino IDE about the new device.

It's not easy, and you need a surface soldering device and a programmer to upload the new bootloader.

There is another way I tested and worked fine, and you only need a MKII programmer. The trick is to use arduino internal 8 Mhz clock, that can be tuned.
You have to change the ATmega fuses to make it work with it's internal clock (using the programmer)  and then change in your program the OSCCAL register to make the clock a little higher than 8 Mhz. The ideal frequency is 8.294400 Mhz (0% error @ 115200).

But, you have to take care of the timing sensitive routines, as with a 8,2944 clock, a delay(1000) will delay 0.964 milliseconds.

I know this is not a detailed tutorial, but I only want you to know the chances you have. If you are going to try any solution I will be glad to help you.



Hi necro i know, but this was the most informative thread on the subject i found easily so thought i'd add to it a bit with a little sketch i wrote to help calibrate the internal oscillator.


Go Up