Modifying Arduino Nano V3.0 crystal speed

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have an Arduino Nano V3.0 and it is annoying that it uses a 16MHz resonator (Murata CSTCE16M0V53-R0). I would prefer one that allows all the magic serial baud rates. So, I would like to use a 14.7 or 18.4MHz resonator. Which resonator at these freq's would be a good match?

I found AVX PBRC14.74MR50X000 and PRQC18.43SR5010X000 but the sample schematics show an extra 1M resistor across the CLK pins which the Murata does not show in a similar schematic, and the Nano does not have such a parallel resistor.

Before I order the parts and make the change, I'd like to have some input on this issue.

-Tony

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I would prefer one that allows all the magic serial baud rates.

These are the common baud rates for 16MHz (taken from mega16 datasheet):

                     U2X = 0                       U2X = 1 

  Baud Rate (bps)   UBRR        Error               UBRR          Error 

   2400              416       -0.1%                  832         0.0% 

   4800              207        0.2%                  416        -0.1% 

   9600              103        0.2%                  207         0.2% 

  14.4k               68        0.6%                  138        -0.1% 

  19.2k               51        0.2%                  103         0.2% 

  28.8k               34       -0.8%                  68          0.6% 

  38.4k               25        0.2%                  51          0.2% 

  57.6k               16        2.1%                  34         -0.8% 

  76.8k               12        0.2%                  25          0.2% 

  115.2k               8       -3.5%                  16          2.1% 

Sure 57.6 and 115.2 will benefit from U2X and even then 115.2 is just "borderline". But they are all "do able" aren't they?

=============================================================================

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I would prefer one that allows all the magic serial baud rates

If you want throughput then you need a synchronous interface (SPI goes to 8Mbps) or a built-in USB (256kB/s for U4 series is possible).
And if you really, really, really want it rs232 style then you already have FTDI chip underneath that board. It can be configured with any baudrate, not necessarily "magic" one.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I used 38400 for a while till I realized that 115200 works fine with the 16MHz xtal on the uno with 2x.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will try the double speed on the cpu and see if that works OK. I would love to get 115K and 230K baud, which I have done successfully with CPUs clocked with a 14.7MHz xtal.

As it is right now, I can do 19.2K reliably. Then the next successful speed is 57.6K, but it appears not to be reliable. I am not sure why I had bad luck with the other speeds below 57.6K and I need to re-try them. Faster speeds than 57.6K do not synch up with the PC. The software on the PC only has the "standard" speed options. I thought that it would be reasonably easy to replace the resonator with a different speed, as long as I use a compatible type.

In the future, I will be writing the S/W for the PC and I can specify some oddball speeds that will match the actual bit rate coming from the Nano. So, I will be able to get something in the vicinity of 115.2K and 230.4K baud in the future.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just look at the BAUD tables in the mega328 data sheet.

You can get 115200 baud with U2X
230k is NOT possible @ 16MHz.

If you really want 230k, choose 18.432MHz and 5V.
If you are running at 3.3V, choose 11.059MHz.

Remember to tell your Arduino IDE that F_CPU is changed. Otherwise all the timing will be up the creek.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Spamiam wrote:
I have an Arduino Nano V3.0 and it is annoying that it uses a 16MHz resonator (Murata CSTCE16M0V53-R0). I would prefer one that allows all the magic serial baud rates. So, I would like to use a 14.7 or 18.4MHz resonator. Which resonator at these freq's would be a good match?

Either one if it fits in place of the old one. I think Mega328 can go up to 20MHz when supply is 5V.

Spamiam wrote:

I found AVX PBRC14.74MR50X000 and PRQC18.43SR5010X000 but the sample schematics show an extra 1M resistor across the CLK pins which the Murata does not show in a similar schematic, and the Nano does not have such a parallel resistor.

Yes because there is no internal bias resistor in regular inverters so it needs external bias resistor. AVRs have internal biasing so it does not need external bias resistor.

Spamiam wrote:

Before I order the parts and make the change, I'd like to have some input on this issue.

Ceramic resonators are accurate to approximately 0.5%.
At 16MHz, 115200 is virtually impossible, U2X or not. It will work if the crystal runs slow enough, but does not leave much margin and because of resonator manufacturing tolerances, it may or may not work depending on your resonator.

The reason for staying below 2% accuracy in UART baud rates is that you can have one device with 2% error and it will talk to another device with 2% error, as there is no guarantee that your serial ports have 0% error in their baud rates. In practice people stay below 1% as more errors may accumulate from RS232/RS485/etc tranceiver chips and such which is not the case here. FTDI docs say below 3% should be OK although I am a bit sceptical. Anyway, requesting 115200 from FTDI232R chip results into 3000000/26 or 115385 so even that is +0.16% fast.

57600 should almost always work when using U2X, but without U2X it again depends on your ceramic resonator's actual frequency. With 0.5% resonator the worst case error is 1.3% which is a lot.

38400 is the highest "standard" baud rate that will always work, U2X or not. Tolerance is below 0.7% when using 0.5% resonator.

Another way is to remap the FTDI baud rates. You can remap the FTDI baud rates so that some baud rate you are not going to use in the software like 2400bps is something that is achievable with 16MHz crystal, like 1Mbps.

So personally, I'd try these before bothering to change the resonator. If remapping to 1Mbps does not work, why is 38400 bps not enough?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
I used 38400 for a while till I realized that 115200 works fine with the 16MHz xtal on the uno with 2x.
I routinely use 115200 on an UNO with few errors. With 2X, theoretical error is 2.12%. I generally use it for fast serial console updating, usually for debugging... so the odd error is OK. I generally include a CTRL-L refresh feature to clear up the display when I get garbage.

I have had similar success with 230400, even though the theoretical error at 2X is 3.68 %.

I've even managed 460800, at a theoretical error of 8.5%! Yet I find it only slightly less reliable than 115200.

Mind you the UNO uses a ceramic resonator that has +/0 0.3% tolerance, but that shouldn't be enough to offset the error at 460800.

I use auto-baud code I've written to measure serial console baud with a single keypress (below ASCII 0x80), and the results may explain my unusual success.

- With a configured console baud of 115200, auto-baud reports 118129 baud. With UBRR0 configured for 117647 baud (closest possible to 115200 @ 16 MHz), that's an error of only 0.4%
- With a console baud of 230400, auto-baud reports 221879 baud. With UBRR0 set for 222222 baud, that's an error of 0.15%.
- With a console baud of 460800, auto-baud reports 507042 baud. With UBRR0 set for 500000 baud, that's an error of 1.4%.

I'm running Ubuntu, and the serial console interface only recognizes standard baud rates. Any other rate results in the default baud of 9600.

I can only speculate, but I'd guess the firmware in the 16U2 on the UNO is responsible. I've not looked at the code to find out, but it makes sense that the 16U2 running at 16 MHz using a 20ppm crystal could only achieve the same true baud rates that the 328P can with a 16MHz 3000ppm resonator, +/- 0.3%. The 1.4% error at 460800 reported by my auto-baud code results from latency and other inaccuracies in the code.

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Of course you can't do reliable UART communication with 8.5% error. But on a UNO your AVR is talking to another AVR (mega8/16u2). If 8.5% error works then the u2's USART is probably configured for 8.5% error too. If both devices have a 8.5% error (with the same sign) then the effective error is 0%. That usually works fine (they don't use exact the baud rate you intended but they use the same baudrate).

The communication between the U2 and the PC is USB. No USART baud rate is involved in that. The driver on the PC can then talk to your terminal program with a 0% error virtual baud rate.

IIRC the USART on the UNO's U2 is always configured with the U2X bit set.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am not using the arduino bootloader in order to make it conveniently compatible with mt programming environment. (ZBasic). Despite the U2 bit apparently being set, it fails downloads at its standard 115k baud. Not sure why. I reprogrammed the bootloader to use 38.4k and it downloads fine. After that the software I download can run at 115.2k, at least for short burst lengths.

So, I think I may be good to go for now while using the original 16MHz click speed on the Nano.

I will check on the FT232RL to see what it's natural 0% error baud rates may be and see which speeds will work with the 16MHz AVR

-Tony

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Spamiam wrote:
I am not using the arduino bootloader in order to make it conveniently compatible with mt programming environment. (ZBasic).
That wouldn't help you anyway. As mentioned, the reason the UNO is able to achieve those speeds is because the USB interface provided by ATmega16U2 is also clocked at 16 MHz. With an FTDI, it's a different ballgame.
Quote:
Despite the U2 bit apparently being set, it fails downloads at its standard 115k baud. Not sure why. I reprogrammed the bootloader to use 38.4k and it downloads fine. After that the software I download can run at 115.2k, at least for short burst lengths.
Try configuring both your software on the Nano and the serial console software on the PC to use 2 stop bits. This could greatly reduce errors. You could do the same with the bootloader and whichever downloader you're using.

JJ

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes the FTDI's have a fractional baudrate generator so they can come pretty close to any baudrate you (via the the driver on the PC) tell it to use if it's not to high. It can use baudrates from a few hundred baud up to 3 Mbaud (FT232R).

The possible baudrates are

Baud Rate = 3000000 / (n + x)

where n is an unsigned 16 bit integer and x is one of 0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, or 0.875 (with a few restrictions).

You could for example ask it to use 111111 baud which works well with an AVR at 16MHz. But that may not work if you use a terminal program that only want to use standard baudrates.

A baudrate with a large error on the AVR will not work well with the FTDI since it usually can come close to the specified baudrate. In the UNO case it will work if it's mega8u2 uses the same configuration (with the same error) as on the AVR it's talking to.