More stable UART comm when using the internal clock

[danman43]

Numerous PIC's with internal UART's are also starting to feature internal clocks, allowing the elimination of external crystals/oscillators. While they can save a lot of money in production, overall stability when operating the UART can quickly go from hit-and-miss to total headache, especially when temperatures drift significantly. However, if the serial packet is relatively short, as in PIC-to-PIC data logging or similar applications, a trick can be used to firm up communications significantly.

It must be remembered that clock drift causes progressive error in a serial transfer. Since the UART syncs the baud clock on the edge of the start bit the bit center sample will be fairly close on the reception of bit 0. However, since the baud clock is driven by the internal clock, the following bit samples will drift further and further from center as additional bits come in. This means you are more likely to read the "later" bits in a byte (5,6,7) incorrectly but that the "earlier" bits (0,1,2) can stand a significant drift in clock.

If the data packet to receive is fairly small, say, just a byte or two, you can keep reception sync'ed by changing two things; splitting the data byte into two shorter bytes and making sure there is sufficient "recovery time" between the transmitted bytes. If you are using the software UART the first function is easy to do. Simply pick a shorter 5 bit UART transmit byte and spread your data across two bytes. However, if you are using the hardware UART you tend to be fixed at 8 bits. Split the data byte into two nibbles and pack each nibble in the bottom half of two bytes. Set the remaining nibble of each byte as all 1's. This will create a byte with data in positions 0-3, the "earlier" bits, and, effectively, "stop" bits in 4-7. If your clock is running fast it will detect bit 7 as a valid stop bit and will not throw an error. If your clock is running slow, however, the stop bit may be detected after the true stop bit has been sent. This is why it is important to allow a little time between byte transmissions. The line will default to the "stop" condition if no data is being sent. If you add a pause before sending the next byte (the equivalent of 1-2 bit times) your receiver won't care if the line is a true stop bit or just an idle state. Then, when the next start bit comes in, the UART will resync to the new data byte.

This is not the most efficient way to transfer data but, again, if the payload is small and not time critical, it can allow significant clock drift without compromising the serial link.

[Ken Johnson]

Interesting concept. Although I've never used 9-bit data transfers, this might be useful for extending the "byte-time" when using a hardware uart (but, since I've no experience with 9-bit setups, I don't know how hard/easy this is).

Ken