Drift auto-corrector for any microcontroller
You need to describe your actual problem - not just summarise it. 

eg I am using UARTs at 9600 baud.
My clock source is RC/Xtal/ceramic resonator ...
At xxx MHz ... . ... 

For asynchronous communications(UARTS / RS232) you need usefully better than 1/2 a bit difference in time across a data word.
So say using N81 = 1 start + 8 data + 1 stop = 11 bits
so 1/2 a bit error is 1/22 or about 4% or better difference in frequencies. 
A cheap crystal should be able to achieve this with both arms tied behind its back.
Unless there is an exceptionally good reason not to use a cheap crystal it's the easiest solution. 



Added:


  The UART baud is 38400bps,
  Clock is XTAL with 2 33pF 5% capacitors tied from ground to each leg on a PCB and
  The crystal speed is 22.1184Mhz.
  The communication is half-duplex due to the limitations of radio module. 


38400 baud with N81 needs double the absolute frequency accuracy of what I listed overall and the same time accuracy.
ie with an N81 async signal 1/2 bit is 0.5 bits / (1 start + 8 data + 1 stop)
= .5/10 = 1/20 ((I said 1/22 before)
= +/- 5% overall between ends
or +/-2.5% at each end.    

Look at your crystal specs - if they allow &lt;&lt; 2.5% drift for all reasons (time,. temperature, ...) then the problem is not frequency stability.
2.5% = +/- 25,000 parts per million
= far far worse than any sensible crystal specs. 

The error is more likely to lie in RF link errors.
This can be checked by examining results with known suitably stable and accurate TX &amp; RX clock sources across the same link.  Try lower and lower still data rates to see what happens. 

Random noise will tend to kill bits semi-randomly.
Clocks off frequency will 1st cause parity errors when they shouldn't and then affect the bit sent last, then next to last etc. (This is because an off frequency clock will cause off centre sampling which gets worse and worse as the bits are sent until the last or later ones fall off the edge of the correct bit.

A cheating way of addressing just marginal clock speed failures is to shorten the start bit time at the TX end if the TX clock is slower than RX clock and lengthen the TX clock length if the TX clock is too fast relatively. This is "desparate stuff", may even work, and should not be needed.

Link noise is a more likely error cause.