Sleep on pic24 with RTCC not working

[temtronic]

When you decide on an external xtal, if you get a 'binary' one you'll have ZERO problems with UART speeds.
A 'binary' xtal is one that is a factor of 2. IE 2.457600 when divided down will give precise 9600 UART speed. Some datasheets have charts or tables showing this. PC UART clocks were/are 14.something MHz, again to give precise timings.

The 'problem' with say a 16.000000 MHz xtal is that the UART speed will be slightly off. If it's say -2% off and the other unit is +2% off, that's a 4% difference and the UARTs probably won't talk nicely to each other. Add in the PIC is cold (outside...data logging) and PC in warm office and the difference can be greater, so you lose communications.


jay

[JMarysse]

Hi temtronic,

Thanks for this, we will keep this in mind when we start the redesign.

[Ttelmah]

Yes. This is why I suggested 7.3728MHz, as being one near to 8MHz, that does this. Exactly 64*115200.

[newguy]

Have to play devil's advocate. If you structure your code to require "integer ticks", then an integer crystal makes that easy. If you require CAN, then an integer crystal is pretty much the only thing that will work.

Serial is one of those things where a little frequency error, in my mind, is okay.

[Ttelmah]

The need for a binary UART crystal, rises the lower the frequency you want to run.

If you clock your CPU at 32MHz, the basic division error is only 0.6%. But clock at 4Mhz, and this shoots up to 3.6%....
In fact pure 'binary' crystals (not binary UART crystals) can be the best values for 'integer ticks'. Remember the internal timers themselves count in binary, so for a 1mSec 'tick', a 4.096MHz crystal is one of the easiest choices.
Obviously 'special needs' will have their own clocks required. USB & CAN for example.
It's a place where a bit of thought can improve the design for very little cost.