Digital Clock

[junaid766]

i want to make a digital clock with 8051.
i searched on internet and found two type of clocks, one which only use 8051 and other which use RTC(e.g.DS1307) with 8051
i want to ask that which one is more accurate

 

[Gayan Soyza]

I won't go for any special RTC modules to make clocks.Thats why I choose micro controllers to do many tasks from a single device.

 

[SAMEH_GPC]

thank's a lot Gayan Soyza.

 

[rgbphil]

Hi,
If you use a crystal that has a frequency that can be divided by a multiple of 2, like a 32.768kHz crystal (can be divided by 2^15) then a micro based clock will be just as accurate as a RTC based clock...the limiting factor will be the crystal.

Clocks based on other frequency crystals have problems because there will always be some math errors in dividing down.

The reason for choosing a div by 2 crystal, is that you can have a free running interrupt counter providing the 'ticks'.

As for choosing between the two, with a RTC chip you will get some other functions like automatic calender and very low power shutdown modes. Additionally they might have a specially trimmed internal oscillator capacitors around the crystal that make a very accurate system. However carefully reading the datasheet for your micro and choosing the right crystal capacitors will probably be accurate enough for most applications, unless you want your clock to be accurate over a decade without resetting don't worry about this.

For a micro you'll need a micro with a external oscillator input circuit that is linked to an internal timer. You probably don't want to run the micro from the clock chip....but I might be wrong about this. The PIC 16F88 has two oscillator circuits, one for main processor and another that is linked to a timer that can be used as an internal RTC.

With a micro you can possibly do low power shutdown depending on what sort of micro you use (don't know about 8051 sorry)....but may have to put a bit more coding in making sure interrupts are not missed when the micro powers up, maybe a microsecond here and there might be lost....shouldn't be a major problem with most micros if you are careful with your power down/up code. No problem if you are permanently on.....unless you disable interrupts for some reason and miss a 'tick'.

Personally I'd just use a micro.......but it depends on what your application is. A battery device, with enough space on the board will probably benefit from an RTC. A micro only will probably suit most applications however.

As always it depends on the application, but the short answer to your question is that with proper coding a micro based clock will be just as accurate as a RTC based one.

Phil

 

[Mike - K8LH]

A number of cardinal crystal frequencies (4, 8, 16, etc.) work fine too. Anything that can be divided down to provide an accurate 1 or 10 msec periodic interrupt 'heartbeat'.

A ceramic trimmer capacitor can be added to the crystal oscillator circuit to fine tune the crystal frequency and improve accuracy. Or you could implement a soft' trim function instead with much finer control. The soft' trim function simply adds or subtracts one cycle during each 1 msec interrupt for 'n' number of interrupts during each 1 second interval to improve accuracy. I use this method in a clock with a 16 MHz crystal for accuracy to within approximately 1 second per month. Most of that 'drift' is due to temperature drift and crystal aging.

The battery backup capability of an RTC chip could be an advantage in many situations.

Happy Holidays. Mike

 

[rgbphil]

Hi Mike, nice to hear from you again.

With regards to accuracy, I went through a phase of looking at forums where these issues were discussed and the consensus was that a free running multiple of 2 crystal was the most cost effective v accurate way of doing clocks.

The reasoning in these forums was that if you used a cardinal frequency that was not a multiple of 2 then your interrupt would have to have this 'soft' trim function you've mentioned. There would be some error as a new timer countdown was loaded to accommodate the division because the albeit small amount of time the micro took to perform the reload would be an error....missing time as it were. It can be 'trimmed' out yes, manually by observation or counting instructions and adjusting the countdown accordingly.... a whole bunch of ways. Search for odd and evens algorithms if you have some spare time.

With a free running counter, you never load the internal timer with anything and never stop it. Hence you never need to worry about any error in working out the divisor. All you need to do is to set an interrupt on a zero rollover and make sure the RTC processing code (plus any other interrupt sources) total execution time is less than the tick time. Usually the oscillator has an internal divider (which will be a multiple of 2) so you set that divider to tick at 1second (or 1/2, 1/4, 1/8, 1/16...) depending on your needs.

There are lots of different techniques of varying complexity to get accuracy...some very complex and mind bending..too hard for me. Personally I preferred the method where you just add a multiple of 2 crystal and let the internal counter run freely....thus avoiding any adjustment in software. Of course this means using up another two pins on your micro especially for an RTC (assuming your micro has a low frequency oscillator).

Your right though, it can be done with a cardinal frequency....but it's a bit simpler with a multiple of 2 crystal.

I've used 32.768khz crystals on secondary oscillators because the micros I've used don't have a big enough timer register to use higher frequency crystals (for example a 3.2768MHz crystal which could be used as a main clock). I've never minded using up extra pins on the secondary oscillator, but it might be an issue for some applications.

In any case the accuracy is still pretty good no matter the approach and as you've said drift becomes dependent on the electrical charactistics of the oscillator (temperature, aging, inproper loading shifting the 'Q' of the oscillator slightly etc).

Phil

 

[Mike - K8LH]

Hi Phil,

I wonder if you perhaps mean crystal frequencies which are a "power of 2"?

The reasoning in these forums was that if you used a cardinal frequency that was not a multiple of 2 then your interrupt would have to have this 'soft' trim function you've mentioned.

The soft' trim function I mentioned is used to compensate for a crystal which may be slightly off frequency. Any crystal, cardinal, or power-of-2. You do realize that your 3.2768 MHz crystal might actually oscillate at 3,276,400 Hz, right? Or a 16.0 MHz crystal might actually oscillate at 16,000,200 Hz, right? In fact, not one PIC crystal oscillator I've ever measured on my Icom ProII receiver with its 0.5ppm timebase has been "dead on" the correct frequency.

There would be some error as a new timer countdown was loaded to accommodate the division because the albeit small amount of time the micro took to perform the reload would be an error....missing time as it were. It can be 'trimmed' out yes, manually by observation or counting instructions and adjusting the countdown accordingly.... a whole bunch of ways. Search for odd and evens algorithms if you have some spare time.

If you're talking about inserting a value into a free running timer register during an interrupt then yes, there could be a problem if you don't do it the right way. There are plenty of examples for correctly reloading Timer 0 on a PIC by adding the offset value plus 2 cycles to the free running timer register. I do agree that this isn't the best or easiest method for generating a 1 msec periodic interrupt, and trying to add values to a free running 16 bit timer is a nightmare (don't do it, grin).

Fortunately, PIC Timer 2 can be used with prescaler/postscaler settings to generate error free periodic interrupts just as easily as a free running timer with a power-of-2 crystal frequency. Another easy/error free method is using the CCP module "special event trigger" mode.

There are lots of different techniques of varying complexity to get accuracy...some very complex and mind bending..too hard for me. Personally I preferred the method where you just add a multiple of 2 crystal and let the internal counter run freely....thus avoiding any adjustment in software. Of course this means using up another two pins on your micro especially for an RTC (assuming your micro has a low frequency oscillator).

This is a misconception. For example, your power-of-2 crystal may actually oscillate at 32,760 Hz which explains why a real time clock derived from that oscillator may be off several seconds per week or month. In short, a power-of-2 crystal isn't necessarily any more accurate than another crystal.

Using a soft' trim function to tune or trim a 1 second period to within 1 cycle is relatively easy and painless. As it turns out, using a higher frequency crystal is an advantage. For example, a 16.0 MHz crystal allows for theoretical accuracy of plus or minus 1 Tcy per second (250 nsecs) or plus or minus 8 seconds per year. Unfortunately the method does not account for crystal aging or temperature drift and that's why my clocks drift up to almost one second per month instead of the theoretical 0.667 seconds per month.

Here's one way you might implement soft' trim code in an RTC interrupt routine;

void interrupt_rtc()         // 1 msec Timer 2 interrupts
{ pir1.TMR2IF = 0            // clear timer 2 interrupt flag
[COLOR=Magenta]  if(correction_ctr)         // if counts remaining this 1 sec period then
  { tmr2 =+ correction_val;  // add +1 or -1 Tcy to Timer 2 and
    correction_ctr--;        // decrement counter
  }
[/COLOR] 
  ...

  rtc--;                     // decrement 1000 msec counter
  if(rtc == 0)               // if 1 second interval then
  { rtc = 1000;              // reset 1000 msec counter and
    [COLOR=Magenta]correction_ctr = 44;     // reset 1 sec correction counter and[/COLOR]
    ...                      // perform all once-per-second functions
  }                          //
}

Anyway, I hope I've helped filter out some unqualified myths or misconceptions.

Happy Holidays. Mike

 

[junaid766]

thanks for you replies

any schematic of clock base on 8051 only (mean to say the accurate working code)

 

[rgbphil]

Hi again,

Sorry to hijack the thread a little on a bit of a side road junaid...but I'm not familiar with 8051 processors.

Realistically we're being very precious with accuracy here. For your application I suspect pretty much any of the replies we've been giving will make a good enough clock for general use.

Back to Mikes replies.

Yes I'm aware that a crystal will oscillator slightly off the specified frequency. There are several reasons already mentioned, temperature, aging as well as the more common improperly loading the oscillator circuit. That's why I mentioned using an RTC, they'll have specially trimmed internal caps to make the loading more accurate than any hobbiest is likely to do.

I agree that that even with a power of 2 crystal that some sort of trim might still be necessary if you want really good accuracy to compensate for inaccurate oscillators.

As for multiple of 2....yes, I meant a power of 2...binary is involved somehow!

I think were in agreement that there are methods for properly loading values into a free running counter....but again its code complexity vs accuracy...ahh engineering a world of eternal compromises! And I'm aware of setting up the CCP in PICs to make a periodic free running timer.

However one thing I didn't mention was an inherent issue (I won't say problem because we're being really picky here) to do with non power of 2 clocks. It's the granularity of the processor ticks.

If you have say your processor at 20MHz, depending on your PIC each instruction will execute in some fraction of that clock. Lets say f/4, so each instruction will execute in 25x10-9 seconds.
Any manual reload will need to take this granularity into account. Even automatic reloads like (I think) used in the CCP module method will take some time (not sure how this is done or how much time a reload/reset takes..but it will take some time).
This can be accomodated for in a soft trim for sure...but because any soft trim will necessarily be at the granularity of the processor it's another source of error. You'd need to accommodate the error of correcting the error.

I mentioned before about 'odds and evens', this was these super clock fanatics taking even this error on error correcting into account. Something to do with counting how many odd ticks have been made and how many even ticks have been made. Some people have way too much time on their hands.

For me it all got a little too much, I just left my timer running free with no reloads manual or automatic. For sure there'll be errors in the crystal oscillator circuit and probably propogation errors as the electrical signals in the free running counter get gated around....but it's a simple way to get reasonable accuracy.

I could sit down and monitor the clock over a period of months, work out a suitable trimming value and somehow enter it in......but haven't the patience. I could scope the clock with a super accurate piece of test equipment tweaking trim pots and calculating instructions times.....but dont have the equipment.

So it all boils down to complexity vs accuracy in either software or hardware and how much time I want to spend making a clock (that's a bit of an ironic statement).

The biggest error (not cummulative though) hasn't been mentioned, setting up the clock in the first place. Can anyone really click their time setting buttons with enough speed to sync totally accurately with the talking man on the other end of the phone????

Phil