How to deal with RTCC in apps with timing constraints?

[krugger]

Let's make an specific post for this doubt:

I'm programming an application that has to around 2 seconds of consecutive ADC measures each 10 minutes.

I think I do understand (hopefully) how to create an internal RTCC using timer0, but...

How long does it takes to the PIC to perform all the timer0() interruption attention routine?

The point is that once the measures have started, I can't allow the timer0() to interrupt or its execution time will affect to my measures, in correlating them in time (i.e. If it interrupts and takes 10 ms to run its attention code once it returns the measure It'll take won't be the next to the previous one but one 10 ms later).

So, the solution would be disable interruptions each time the measures start, before calling the measuring routine, and enable them again once they've finished, but the problem is that as the measuring & sending process last for, let say, 5 seconds, I'll be losing 5 seconds on my RTCC in each measuring cycle.

Any idea of how can I deal with this?

Thank you!

Pablo

[temtronic]

1) It'll help if you specify the PIC you're using...

2) there's a Real Time Clock in the Code section that works very well. Easy,simple as pie , to use it to 'trigger' your ADC routine every 10 minutes.

[temtronic]

I think this is the link....

http://www.ccsinfo.com/forum/viewtopic.php?t=26177

[krugger]

Thank you Temtronic for your answers,

I'm using PIC16F1827, but I don't have problems with designing a clock, but with dealing with it together with my measures.

I need 2.4 seconds of continuous measures (they'll be used to calculate FFT once received in the master node), so during those 2.4 secs, I need to disable interruptions to avoid losing measures while the clock timer interruption routine is being treated.

The question is, how can I do for not losing the correct time in each measuring process? Maybe I can calculate how long does it takes to measure and send the measures and sum this time to the clock variables before enabling interrupts again...

Thanks again!

Pablo

[andrewg]

The rule of thumb I've seen is that interrupts take about 60 cycles, plus whatever processing you're doing in the handler. I haven't needed to measure it myself. That means your interrupt handler should execute in microseconds, not milliseconds. If timing is critical to your application, you really need to do some tests to measure things.

If you really need to disable interrupts but keep the clock ticking, then poll the interrupt flag while interrupts are disabled and increment a counter. Then 'catch up' when interrupts are re-enabled.
_________________
Andrew

[FvM]

If you are able to perform exactly timed AD data acquisition for 2 seconds (are you?), then it's no problem to stop the RTCC timer meanwhile. You know the time amount and can add it to the timer variables.

You can also switch to polling the timer instead of getting interrupted by it for a while. It effectively reduces the latency.

[temtronic]

another way is to have a hardware RTC

or have your software RTC only interrupt say every 5 seconds that way the ADC code will NOT get interrupted as it only needs 2 seconds to complete.