Why we doesn't use Clock Crystals like 18,432?

Forum 2005-2010 (read only) General Bar Sport
1

I think about Uart/Baudrate things....

Most of the Arduino's i know make use of 16Mhz crystals.

In fakt of errorfree transmitting and wider range of ERRORFREE usable Baurates i want to know, if it makes sense to use

14,7456 Mhz instead of 16Mhz and
18,432 Mhz instead of 20Mhz.

Sure, clock is a little bit slower... but:

14,7456 Mhz:
errorfree: 2.400, 4.800, 9.600, 14.400, 19.200, 28.800, 38.400, 57.600, 76.800, 115.200, 230.400 Baud

16 Mhz:
errorfree: 2.400, 250.000, 500.000, 1.000.000 Baud

18,432 Mhz:
errorfree: 2.400, 4.800, 9.600, 14.400, 19.200, 28.800, 38.400, 57.600, 76.800, 115.200, 230.400 Baud

20 Mhz:
errorfree: 2.400, 4.800, 250.000, 500.000 Baud

You see, real errorfree Baudrates are very different on Crystalclocks.

I don't understand that 16Mhz/20Mhz were mainly used...
i know that thats the maximumspeed,
(we mainly doesn't use assemblercoding, so speed seems to be not sooooooo important) but in comparsion with errorfree transmission does it make really sense to use wrong crystals for maximum clockspeed while get transmissionerrors and a much smaller range of errorfree baudrates?

Greetings
ChrisS

2

"errorfree" simply means "exact baud rate match".
A small percentage error is acceptable (lots of people use the "error-prone" rate of 9600 on the 16MHz Arduino without problem), because the receiver is resynchronised every character.
Only if you had really long word lengths would cumulative timing errors become a problem.

Rate mismatches are much less of a problem with crystal-controlled receivers and transmitters at quite high rates, compared to the bad old days of mechanically-timed slow rates from teletypes and telex machines.

3

Rate mismatches are much less of a problem with crystal-controlled receivers and transmitters at quite high rates, compared to the bad old days of mechanically-timed slow rates from teletypes and telex machines.

I agree, baud rate mismatch is sometimes misunderstood and given much more concern then it should. I repaired teletypes in the Air Force in the late 60s and even those old mechanical devices had quite of range for speed mismatch and still receive error free. As stated any character timing is reset on each and every start bit so mid bit sampling error will only accumulate for the length of data bits.

Lefty

4

when people set the prescaler for the baud rate in AVR C, they just round. It's not accurate at all, it could be off by multiple percents but it works fine.

5

In fakt of errorfree transmitting and wider range of ERRORFREE usable Baurates i want to know, if it makes sense to use ...

I think it makes perfect sense to use a crystal that will give you an exact baudrate match - if that is your main priority. Since all mcu timing is derived from the single crystal however, the choice is typically a tradeoff between conflicting requirements, and then the sub-system with the highest tolerance (e.g. USART) is the preferred candidate to compromise.

Examples of conflicting requirements may be:

  • Frequency measurement, tone or pulse generation, PWM base frequency
  • Software timing loops (one-wire, software serial, micros delay)
  • Real-time clock (millis)
  • Cost and availability of desired crystal/resonator
6

sorry, mmh, why there are conflicts?

18432 "Heartbeats" per second.
...so, if i use 18432 in boards.txt i should get the same as of 16 or 20MHZ in result????

Little better precision than 16MHZ little less than 20Mhz....????

I don't understand why it is conflicting to get a slightly higher clock while compiling with right parameters it should be better than 16MHZ.

16000Hz in comparsion to 18432Hz.... i thought 18432 is better for precision. Also better for Uart/Baudrate.

Ok, its badder than 20Mhz... in precision, but the most of Arduinos working ith 16Mhz crystals so it doesn't matter... did you mean that?

Greetings ChrisS

7

As an example there is a project where some clever individuals have implemented a software USB emulator on 8-bit AVR's. This was made possible based on calculating exact execution time for individual mcu assembly instructions and squeezing that into a critical timing loop. A few kHz off and it would not have been possible.

Another project use a similar approach to generate NTSC video timing signals.

The millis timer in Arduino can be maintained using a simple shift and increment. This help towards minimizing execution overhead and reduce code size. Other frequencies may allow the same, but not just any frequency and so requirements may be in conflict.

The delayMicrosecond function is based on a delay busy loop executing exactly 16 mcu instructions (16 times 62.5nS @ 16MHz). Since yoiu can not delay a fractional instruction, other frequencies may not allow for this.

For some projects, clock requirements may be absolute, but others again may reflect your subjective preference (e.g. faster/simpler code). Like I said, if your priorities are for an exact usart baudrate, that may govern your choice more so than other issues. If you google for special puprose devices, I think you will see the fuill range of crystal frequencies in use. For a general purpose device such as Arduino however - 16 MHz is a pretty good choice.

8

Ah, ok... now I understand....

Thank you for explaning....!!!!

If I use premade code which is instruction timed it would be messy to use wrong clocks... i see...

But, for general purposes with communication overhead, 18,432 should work.

mmh, is a PWM on Pin X with Value 100 different from PWM on PinX with Value 100 on 18,432 if compiled with 18,432 in Boards.txt?

Yes.. if I understood right... but really slightly, because difference happens only if division got no Fullvalue.... difference is something like 0,01% ? Right?

Thank you!

Greetings ChrisS

9

prescalers for timers, counters, etc.. usually use powers :slight_smile: of two steps so 8MHz or 16MHz are really good values

And something not really rational digital engineers like very much powers of two :slight_smile:

10

is a PWM on Pin X with Value 100 different from PWM on PinX with Value 100 on 18,432 if compiled with 18,432 in Boards.txt?

The short answer is - Yes it is!

If you give it some thought - you can probably answer how and why that is yourself. :wink:

The follow up would likely be - Is it relevant? - and that is also for you to determine as it depends on your project requirements.

11

But, for general purposes with communication overhead, 18,432 should work.

I don't quite understand. For "general purposes", 16MHz works fine too. The error in the BRG at 16MHz is less than 1% for all "popular" speeds up through 38400bps, and 3.7% for 115200 and 7.8% at 230400bps. A 1% error in the bit rate does NOT translate to a 1% error rate in actual transmissions; in general, the clocks between transmitter and receiver can be off by a total of about 12% before you are sure to get errors. Usually half of that is allocated to receiver and half to transmitter, so you really want to keep error rates on each side below 5%, but the bit rate errors caused by the 16MHz clock of an Arduino should not be causing any real problems.
(also, note that at higher speeds, you need to start worrying significantly about factors OTHER than bitrate mismatch causing errors. RS232 was never designed to go so fast, and TTL-level serial is even more suspect...)

12

TTL-level serial is even more suspect

I would have thought TTL was the better choice for speed - it was designed as a fast-switching logic family, though it won't carry so far as RS-232.

13

Yes, I understood already what all of you had explained.
I thank you all for that...

In relation of the table in my first post... (that time i don't known it better) it seems to me, that optimal (absolutly errorfree) Bandwiths
are simply more ones on 18,432. I thought absolutly errorfree is better than little error included. I like "perfect things" :slight_smile:

The conflics about PWM etc. where an aspect to think about twice,
and I understood that 16 as better usable informatic power is the better way. And Errorfree Bandwidth is not so neccessary as usable
things with arduino.
.......
After all, my Result is to use 20MHZ. Its Power of 2. It's maxmimum speed of my mcu, and is supported by UsbASPLoader, for which i decided to include in my project.
......
Maybe, 16 Mhz is here the better way too, but if I understood right,
clock schould be power of 2. (to get everything work right, but mcu instruction code for 16Mhz which is not sooo neccessary for me as UsbAspLoader supports 20Mhz).
......

Thank you... Greetings
Chriss

14

my Result is to use 20MHZ. Its Power of 2

20x106 = 224.253496 :-?

15

20.000.000 is divideble by 2... so it doesn't create "blindsteps"...

mmh... don't know... maybe in future I would understand it in detail...
maybe my knowledge is much too low, to get it in my brain...
or my brain is much to small for this mathematics :wink:

doesn't matter... i will simply try it.... UsbAspLoader is supporting USB at 20 Mhz while insert Blinsteps in mcuinstructioncode to simulate 16Mhz.
Crazy...

Advantage is, that i can use lowspeed USB and 20Mhz... an you teached me that a little bit errors in communication are aceptable.
PWM and so on, i will test it, if it mets "my doing" in precision.
I think so.

I think thats a very easy and lowcost, aceptable middleway for simple playing and first steps....

If thats crap, i will change my quarz to 16Mhz... that should be no problem.

Greetings ChrisS

16

16MHz isn't a power of two either (that would be 16 777 216 Hz)
The problem lies in the fact that the common baud rates (100, 300, 1200, 2400, 4800, 9600, 19 200, 38 400) aren't simple multiples or powers of 2 either, and is further compounded by the fact that humans like decimal time periods.

However, digital logic doesn't really work out easily for odd divisors, and prefers powers of two.