Go Down

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

Resvics

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.

MarkT

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 ]

Resvics

Hi.

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!

MarkT

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 ]

Resvics

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!

TomLeMort

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,

Resvics

Hi.

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.

Regards.

Uggima

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.

http://codebender.cc/sketch:186647

mpantoja

Hi!

I am struggling to run an atmega328p at 3.3V 8MHz and at the same time use a HC-06 Bluetooth module at 115200 bauds. The solution seems to be in this thread but I do not know how to implement it. Any help on steps on how to configure the micro at 8.3MHz using the last code provided by Uggima?

Thanks in advance

Robin2

Do you really need to use 115200 baud? At 8MHz there can be a lot of error at that baud rate - have a look at the tables in Section 18.11 of the Atmega 32u4 datasheet.

If you can use a higher baud rate it should work perfectly at 250,000 or 500,000 baud. Otherwise maybe try 38,400 baud.

The formula for calculating baud rates using register values is in the datasheet. It looks as if it is possible to get less error at 115,200 baud with alternative settings, but I have never tried them.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

horace

#10
Jan 28, 2018, 08:54 am Last Edit: Jan 28, 2018, 08:55 am by horace
in situations requiring high baudrates, e.g.  921600 bps for an XPORT PRO, I have used a 7.372800MHZ crystal

Robin2

in situations requiring high baudrates, e.g.  921600 bps for an XPORT PRO, I have used a 7.372800MHZ crystal
That depends on the specific baud rate you need, not high baud rates in general.

At 8Mhz you can get 1,000,000 baud.

...R
Two or three hours spent thinking and reading documentation solves most programming problems.

Go Up