Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

PIC Interrupts

Status
Not open for further replies.

UTMonkey

Member
Hi All,

instead of tagging this (side question) on the end of an existing thread, I thought I would create a new one.

Can someone check if I have this right, This is not for any particular project - just for my own knowledge (and also I would like to know what the experts do!).

I would like to be able to get a PIC to generate an accurate(ish) trigger.

My previous thread mentions a 300hz trigger from a PIC running at 8Mhz (2MIPS).

Thanks to Mister E who directed me to his utility to find the best values to plug into my timer:-

Prescaler 1:1
Reload 58876

Are the following assumptions correct:-

1. My interrupt service would contain at the very beginning code to "reload" 58876 to the various timer registers, previous threads have suggested that the TIMERx keeps on ticking whilst an interrupt is serviced but won't trip on a rollover until my interrupt service tells it to do so (at the end). I would imagine this ensures that each interrupt is called as close to 300 times a second.

2. If assumption 1 is true then, any delays that are built into the main code (such as the kind done by delay code generators) must be recalculated based on the cycles used in servicing the interrupt.

Example:
My interrupt must be occur once every 3.3 milliseconds (300hz), that means for a PIC running at 8Mhz (2MIPS) there are (roughly) 6666 ticks between each interrupt.

Lets say my interrupt service takes 1000 ticks (a lot I know), that means that there are 5666 ticks left for my main body of code. So to put a "count to 5 minutes" delay in the main code would actually take longer (roughly over 15% longer).

Have I got this right? what do the experts do?

Many thanks in advance.

Mark
 
If calling interrupts, the ISR time will obviously be added to the code delay, if it's called whilst in the code delay routine. It's another reason for keeping ISR's as short and fast as possible.

300Hz is incredibly slow in PIC terms, you could do 300Hz with a clockwork processor! :D

As for timers, TMR0 is the poorest and lowest spec of all the PIC timers, if you use TMR2 instead it all becomes much simpler and easier to use, and doesn't come with the problems of TMR0.
 
You can generate a precision pulse, as accurate as the crystal frequency of the oscillator. There is a particular problem with 300Hz in that .33 does not translate easily using binary division, or really any division for that matter.

Use the Special Event Trigger feature of the CCP1 module. Load the Timer1 compare value into CCPR1H:L and set up to create an interrupt on every match. Timer1 is automatically reset each time at compare and continues to run and create your interrupts. For precision you must not use any prescaler with Timer1. Also, you do not deduct the Timer1 count as you would a normal Timer1 interrupt. Load CCPR1 with 6667 (based on 500ns clock increments) and preload Timer1 with 0. That will produce a nice accurate 299.985 Hz interrupt cycle.
 
In you example requiring a 5 minute delay. Instead of doing the delay in the main loop, you could use the interrupts to increment or decrement counter bytes at every interupt event

Using your 300Hz interrupt, it needs a total of 90000 interrupts to create a 5 minute delay. Your main loop just has to keep checking a flag that you can set to indicate that the delay has been reached.

It still has a very small error, as an interrupt can occur imediatly after you set-up the counters, but you could minimise it by temporary turning off the interrupt and resetting the interrupt timer just before setting the delay counters.
 
Thanks guys, thats really helpful.

I do take Nigels point, a slow 300hz as an example is kind of strange so if I was to change it to something like 10Khz:-

That means a preload (If I were to stick with Timer0) of 65343, which means there are roughly 66 ticks per interrupt!

Surely this makes life even more complicated?

Regards

Mark

p.s. CCP1 sounds interesting, I may have a crack at that!
 
10KHz can be produced exactly using the PWM module. At 8Mhz you can get an exact 10KHz with the Timer2 prescaler set to 1:1 or 1:4. No mess, no fuss, no interrupts. Clocks out on RC2 or RC1 depending on whether you use CCP1 or CCP2 to produce the pulses.
 
Status
Not open for further replies.

Latest threads

Back
Top