using mulitple interrupts....

[Harry Mueller]

I'm really new to using interrupts so any answer is welcome and no response would be too simple or basic.

I'm writing code to operate a balancing robot and want to have at least 3 and possibly 4 interrupt driven functions. Right now I've got 2, each of which works well by itself but the timing in one goes way out if both are in the program at the same time. I guess that makes sense and an obvious solution would be to add another timing chip. However, I'd like to try to solve the problem with s/w...there are still a lot of resources avaiable on my 16F877.

One isr calculates the period and duty cycle of an accelerometer. It gives me readings from -1g to +1g based on the fwd/backwd tilt of the robot.

[Ttelmah]

What you don't say, is the clock rate, and what divider is being used with the RTC, also the intervals involved in the accelerometer pulses.
The first code works, because assuming the routines are declared in the order shown, it has priority over the other call.
Now unfortunately, the PIC, is relatively poor in it's interrupt handling. Some part of this is CCS, but the main part is the hardware. The chip has a _lot_ of general purpose registers, and no quick way of saving/restoring these. The global interrupt handler, saves the global registers, then tests what interrupt has triggered, and only then calls the first handler 'found' (triggered and enabled). Then the code restores all the registers, exists, and if another interrupt is present, the whole sequence happens again. The overhead associated with this, is perhaps 50 instruction times (it is _worse_on the 18 family chips....).
It sounds as if the accelerometer, must generate a fairly frequent output. So what is happening, is that there is a high probability that when the second interrupt occurs, the code finds the first interrupt has also triggered. This then gets serviced first, adding this extra latency to the response for the second handler. If the interval involved with the accelerometer is short, it may even generate multiple triggers, effectively locking out the second handler for a while.
There has been a post in the last few days, where I posted an 'overview', for a way to alter the way that the interrupt handler is called, so that one handler checks before exiting, whether other events have occured, massively reducing this latency. So long as all the events are asynchronous, you are always going to have the problem of one event changing the delays involved in reaching the other handler, unless you add hardware to do some part of the handling for you.
It _may_ be possible to make a better solution, by generating your own global handler, and if you post some of the timings involved, and the same for the third event (and which interrupt it is going to use), some ideas about this may be forthcoming. However you need to post about all three events, since otherwise may solutions may exist for the two source problem, which then have problems in the 'three source' situation.

Best Wishes

[Harry Mueller]

[Harry Mueller]

[Harry Mueller]

Thanks Ttelmah, I think I've digested what you've said.

I don't want to steer this thread into a different direction and my original purpose is still the first priority.

Given what you've said I've made some assumptions. Please correct me if I'm wrong.

The CCP1 interrupt runs every time an edge changes on the accelerometer signal....averaging about every 500 uS.

The Timer_0 interrupt runs every 100 uS.

You've suggested that interrupt overhead is about 50 instruction cycles long or about 10 uS for my clock speed.( BTW, I can't see how an effect this small could completley obliterate my servo centering signal.)

If I can figure out how long it takes to run the code in each interrupt I should be able to manipulate my timing to get an approximate solution. This is not really elegant, I'm just rambling here, trying to figure out how to deal with this.

Regards....Harry

[Ttelmah]

First comment, the set_time0(6), sightly lengthens the interrupt repeat 'time'. At this point, the processor, will have probably executed about 28 instructions from the start of the interrupt event, and the counter will already be at 14. The interrupt will then occur 249*2 instruction times from this point. Your total repeat rate for this interrupt will be about 526 instruction times. About 9500 times/sec. The handler itself, will involve 25 instructions, plus those in the global handler (about 60 instructions), so the processor will be spending about 1/6th it's time in this handler. This makes the probability of a delay when the second handler is called very high...
Now you seem to be using this as effectively a pulse generator, generating a pulse that is high for 14 counts, then low for 166. So about 1.5mSec high, and 17.5mSec low. I'd have to sit down and do an instruction count for the real code, to get the figures accurate, but I doubt if I am far off. Realistically, if this is all this is doing, then consider using the other CCP module, programmed as a PWM, and doing this in hardware. The existing code is using a huge amount of processor time to do very little.
You still have not said what the third interrupt wants to be. This affects whether it will 'mind' a timing error caused by the other interrupt or not.

Best Wishes

[Harry Mueller]

I'm not really stingy with my information...I just keep forgetting. Sorry. I've spent the last few hours thinking about this and I'm already understanding it much better.

Based on your comments, I've reprogrammed timer_0 to interrupt every 1.5 mS and with this code both interrupts are working well. Now timer_0 is being called every 1.5 mS rather than every 50 uS.

I was trying to save CCP2 to use in compare mode to measure the gyro output duty cycle.

Three interrupts may be enough for now because I may be able to balance the robot just by turning the motor on or off without involving PWM.

If I can get this working I may try to implement some sort of Kalman filter but right now I'm leaning towards just trying the empirical approach.

The last step would be quadrature encoding on both wheels but that may beyond the capabilities of the 16F877. I'll see.