Yes, it is possible to adjust your UART clock to match the incoming signal by measuring the first bit transitions. It helps in network applications to send a start character with a bit-0 set to 0.

 

I wondered what a processor needs to have if it uses a serial link in the most common way, connecting to a computer. If you had an FTDI interface chip to connect to USB, what's it's accuracy? So I looked that up, and it seems the FT232R runs off a 12MHz oscillator, specified as +/- .02MHz, or .167% accuracy. Then I assume that the 12MHz clock is divided down to get a baud rate, which means a divisor of 104, where the ideal divisor would be 104.167, and that mismatch adds another .160% of inaccuracy (always in the same direction, but assume a worst-case combination with the oscillator frequency). So the total frequency deviation from the FT232R is 0.327%. If a PIC with a 2% inaccurate oscillator has to communicate with that interface, I don't see how it could fail. Two PIC processors together might have more of a problem, though it seems clear that almost all the time, it would work.

If you wanted to calibrate a PIC oscillator to get the best match of its UART to another processor (or an interface chip like the FT232R), it seems to me that the best way to do it would be to use incoming characters with bit 7, the last bit in the character, being low. Then the receiver would have the widest span to work with, from the low-going edge of the start bit to the high-going edge where bit 7 ends and the stop bit begins, i.e. 9 bit times. But I don't know what the increment in the oscillator tuning actually is; if it's too coarse, any change you made would only make the accuracy worse. Microchip doesn't specify this, but people on the internet say the range is around +/- 12%, and you only get 32 levels, so that's almost 1% change for a single bit of increment. That seems as if 1 or 2 bits of change to OSCTUNE would be the maximum you could ever use.

 

Don't forget that outputs have rise and fall times, and that there are wires that degrade the signals.

At high baud rates and/or long cable lengths, these imperfections may become significant. Perhaps up to 5% error might be OK at low baud rates and short distances, but perhaps useless at high rates and longer distances.

I use a crystal wherever I can, if only to save me even having to think about oscillator accuracy.

 

Some MCUs have better OSC range adjustment and stability than others. Hence your mileage will vary from one MCU to another.
I know MSP430G2553 allows fine tuning of its internal RC oscillator. It also has auto baud detection.
I have used MSP430G2553 with internal RC oscillator with no problems at 115200 baud.

 

At high baud rates and/or long cable lengths, these imperfections may become significant.

And you may be transmitting the serial data over some RF transceiver which will add its own signal degradation and noise.

 

All true, but if you have transmission channel effects to worry about, you should be calculating how bad those effects can be before doing anything else. If there's significant distortion, you might need to look for a better communication scheme. I'd worry that "If it's bad now, it could be twice as bad tomorrow."

 

if you have transmission channel effects to worry about, you should be calculating how bad those effects can be

Exactly my point. The previous calculations seem to assume perfect square edges and perfect transmission lines.

I am not thinking of faulty transmission channel, just real-world wires and real-world rise/fall times.

 

Hi All,
You have left me behind somewhat! I'm not so technical, when it comes to electronics and programming.

I have added the usual 8MHz crystal to the main PIC, and using the internal 8MHz OSC on the secondary one. If there's a problem, then I'll add a crystal to the seconday.

I've just updated the schematic and PCB on the main thread here: https://forum.allaboutcircuits.com/...l-by-location-pic-in-oshonsoft.148795/page-35

Thanks, C.

 

Hi,
I've been using a secondary PIC with it's internal OSC, and changed it's use lately, then finding UART errors.
Having been reminded about UARTs' need for crystal accuracy, also the age of the PIC, I'm using. I've now have added a crystal. I noted that some of you, use internal OSC with no bother, and my project suffered occasional errors, so for safety and simplicity, I'll keep using them.
C

 

I have used PIC's with internal oscillators for UART's and never had a problem. Which PIC you're using may matter.

Also, don't sue the crystals...they have no money.

 

Internal OSC is ok for short strings of data, as the error margin can be "caught up" with the stop bit. So even with a 2% error in baud rate, 3 or 4 characters will still be captured properly. However, if sending 40 or 50 characters with no gap/pause between characters, an error in baud rate can accumulate such that the last characters can be totally out of sync.
Internal OSC can also work fine if you put a delay between each character. 1ms at 9600 baud gives an entire character time delay. Even 200us delay between characters would give a 2 bit pause at 9600 baud (approx.). One character at a time with long delays between would allow a baud rate error of close to 10% and still work because each character is received independently before the timing goes out of sync. A pause before the next start bit enables this re-sync to happen.

 

I have used internal OSC with GPS just fine. That's a couple hundred chars, or more, each burst. I'm pretty sure the hardware UART on the PIC is syncing on every char.

 

I have used internal OSC with GPS just fine. That's a couple hundred chars, or more, each burst. I'm pretty sure the hardware UART on the PIC is syncing on every char.

Hi U,
So have I upto now, when I started getting ocassional errors, and was advised to try adding a crystal which is no bother to me. Early days, but I haven't seen any errors so far, and will always add them for this aging PIC, 18F4431, and for any time critical applications.
Cheers, C.

Internal OSC is ok for short strings of data, as the error margin can be "caught up" with the stop bit. So even with a 2% error in baud rate, 3 or 4 characters will still be captured properly. However, if sending 40 or 50 characters with no gap/pause between characters, an error in baud rate can accumulate such that the last characters can be totally out of sync.
Internal OSC can also work fine if you put a delay between each character. 1ms at 9600 baud gives an entire character time delay. Even 200us delay between characters would give a 2 bit pause at 9600 baud (approx.). One character at a time with long delays between would allow a baud rate error of close to 10% and still work because each character is received independently before the timing goes out of sync. A pause before the next start bit enables this re-sync to happen.

Hi S,
For my limited memory, where I probably would forget this timing answer, it's safer for me to use crystals.
Thanks. C

 

hi,
I tried a number of MCU internal RTC clocks, their long time accuracy was poor, so I switched to the DS3231 RTC module.
The DS3231 long term accuracy is excellent, a second or so in a month, I use them on a SD Data logger projects.
E

 

hi,
I tried a number of MCU internal RTC clocks, their long time accuracy was poor, so I switched to the DS3231 RTC module.
The DS3231 long term accuracy is excellent, a second or so in a month, I use them on a SD Data logger projects.
E

Hi E,
From comments in this thread, where many have had good results using the Internal oscillator, but I now have chosen to use XTLs, I'll continue doing that. They're small and simple to add.

Regarding more accuracy, your suggestion looks good, and as I haven't learnt iC2 but instead leant SPI, I found this: in case there are others.
https://docs-emea.rs-online.com/webdocs/0f6e/0900766b80f6ed2d.pdf
Thanks, C.

 

If the crystal is 20MHz and the baud is 115200 the error is worse.
The divisor is 11.
Hence the actual baud is 20000000 / 16 / 11 = 113636
The error is 1.4%.

This is why you really need a 18.432MHz crystal.

Note however, if your two boards are using crystals of the same frequency (or multiples of the same frequency or some integer fractions) then your error is practically 0%.

I agree with you "MrChips".