CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug Reports on this forum. Send them to support@ccsinfo.com

More stable UART comm when using the internal clock

 
Post new topic   Reply to topic    CCS Forum Index -> Code Library
View previous topic :: View next topic  
Author Message
danman43



Joined: 06 Feb 2008
Posts: 1

View user's profile Send private message

More stable UART comm when using the internal clock
PostPosted: Fri Jun 13, 2008 9:56 am     Reply with quote

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



Joined: 23 Mar 2006
Posts: 197
Location: Lewisburg, WV

View user's profile Send private message

PostPosted: Sun Jun 15, 2008 7:51 am     Reply with quote

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
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> Code Library All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group