Accurate chronography and multitasking controller

Thread Starter

aeroguy

Joined Sep 16, 2009
40
Hello,

I'm considering my approach to a new appliance controller I want to put together.

The controller is responsible for receiving user inputs, listening to a sensor, and sending a signal to a peripheral actuator (as well as an LCD display).

I've built a controller that does the above tasks, but now want to build an "enhanced" version that includes a clock/timer (in the traditional sense of human timekeeping).

Some configurations I've considered:

#1
I have a feeling that I could do a mediocre to poor job using my MCU internal oscillator with timer driven interrupts that are appropriately prioritized to track time. I think this is fairly poor due to the fact that at times global interrupts will be disabled, and also because temperature and other factors will influence the speed of the internal oscillator.

#2
A slight improvement to #1 might be able to be made by using the same general approach as #1, but driving the MCU (or just TIMER0) with a more accurate external oscillator.

#3
I could shell out for an additional RTC IC, which would track time and communicate it to the MCU for displaying and other things. I suspect that I would want an accurate crystal to drive the RTC IC if I go this route.

My questions:
A. Do any of the above configurations sound reasonable or particularly poor to anyone else?
B. Does anyone have another suggestion I haven't considered?
C. Any experience with something like this or general comments?

Thanks in advance,
Eric

PS - in case it matters, the primary MCU is a PIC18F45K22
 
Last edited:

MrChips

Joined Oct 2, 2009
19,923
Generally, there are two ways of tracking time on an MCU. (There are other ways, but I will keep it simple).

The first way is to use an external RTC chip driven by a 32.768kHz xtal as in your #3. The advantage of this is the RTC does it's own thing, independent of the MCU, keeping track of year, month, day, day of week, hours, mins, secs, DST, leap years, and alarms.

The second way is to use a 32.768kHz xtal to run your MCU. This clock will increment a counter (large number of bits). You have to define your zero start time. This solution is simpler in hardware but requires some additional software if you want to display date & time.

32.768kHz xtal oscillators are reasonably stable and are used in digital watches. If you wish to adjust the clock frequency to be exact you will have at use a trim capacitor in the xtal tank circuit. The only other difficulty is finding an accurate time base or frequency meter in order to calibrate the oscillator.
 

Thread Starter

aeroguy

Joined Sep 16, 2009
40
The second way is to use a 32.768kHz xtal to run your MCU. This clock will increment a counter (large number of bits). You have to define your zero start time. This solution is simpler in hardware but requires some additional software if you want to display date & time.
Thanks Mr. Chips!

I'm tempted by the second solution you mention above for the sake of hardware simplicity. However, I'm paranoid that deep into this project I'll find that my timer drifts due to my need to disable global interrupts occasionally when updating the LCD display, listening to an SPI input, etc.

I think I'll take your suggestion on the RTC chip for robustness and simplifying software.

Much appreciated!
 

MrChips

Joined Oct 2, 2009
19,923
No. The second solution is still valid. The timer counter continues to run independent of what the MCU might be doing, including handling interrupts.
 

Thread Starter

aeroguy

Joined Sep 16, 2009
40
No. The second solution is still valid. The timer counter continues to run independent of what the MCU might be doing, including handling interrupts.
I think I'm envisioning the configuration of this counter wrongly. What I'm imagining is using an internal timer (say, timer0) which is at best a 16-bit timer. Whenever that overflows, an interrupt could be triggered which incremented a counter and restarted the timer.

Since that situation would be affected by GIE being disabled, you must have a different scheme in mind?

Sorry - I'm quite new to MCU development.

thanks!
 
Last edited:

ErnieM

Joined Apr 24, 2011
8,011
Ive seen micros that have two oscillators, a high speed for normal instruction clock processing and an auxiliary 32.768kHz used for both low power instruction clocking and an internal counter/timer or sometimes a full real time clock.

I believe something like this is what MrC is referring to.

My issue with such clocks is what happens when you turn the power off? It isn't the easiest thing to separate all the power so just the micro can run off a battery. For price insensative devices I've just used external RTC that can use a coin cell for backup power (so they always run).
 

MrChips

Joined Oct 2, 2009
19,923
You will use timer1/3/5 module with the 32768Hz xtal on SOSCI and SOSCO pins on the secondary oscillator. The 16-bit timer/counter will run even in sleep mode and will overflow every 0.5 sec. This should be lots of time for you process all your interrupts as well as the timer interrupt. Generally speaking, one does not disable GIE. Just make sure that all your interrupts do not consume a lot of processor time. In any case 500ms is a long time in MCU times.

Edit: If you need to keep time when there is no power as ErnieM suggests, then you will have to add a coin battery. You will have to decide if you want a coin battery to power the MCU in sleep mode or to use an external RTC powered by the coin battery.
 
Last edited:

Markd77

Joined Sep 7, 2009
2,806
If global interrupts are disabled, then the timer keeps running and the timer interrupt will happen as soon as they are re-enabled. The long term accuracy won't be affected unless global interrupts are continuously disabled for longer than the timer interrupt period.
 

thatoneguy

Joined Feb 19, 2009
6,359
If global interrupts are disabled, then the timer keeps running and the timer interrupt will happen as soon as they are re-enabled. The long term accuracy won't be affected unless global interrupts are continuously disabled for longer than the timer interrupt period.
This is true, and as long as the display output isn't driven, a PIC in sleep/low power mode,only updating time with a 32kHz clock, uses 1uA of power (under 850nanoAmps in some devices), hence "NanoWatt Technology", they can run for a very, very long time off a 3V coin cell if not driving a display.
 
Top