It's a simple problem......

[johnh]

For those who know what they're doing....unlike me!


Hello people,

If i compile this simple bit of code

[Ttelmah]

[SteveS]

By inspection I think it's this:

You defined a timer interrupt service routine, but it is not complete:

#int_TIMER0
TIMER0_isr()

is what you have. You need at least:

#int_TIMER0
TIMER0_isr()
{
}

to make it compile. You need to add whatever code in there to accomlish what you want to have happen during the interrupt (reload timer, etc).

[johnh]

Excellent, thanks people..

Suspect my project will kick out a few more problems yet!!

Be back soon...

John
_________________
There are 10 kinds of people who understand binary, those who do and those who don't

[johnh]

next problem......

i want the RTCC to interrupt every ~17ms

at the moment the setup of the timer0 is

[johnh]

for completeness - this is my actual code inside the isr

[neil]

Hi John,
There's a few no-no's in that code I'm afraid!

1) *Never* put CCS's delays in an interrupt. An interrupt needs to be kept short. I know the delay only looks like one command, but it creates a loop which ties up the processor for that duration. This kinda spoils the original intention of using interrupts!

2) Don't use 'while' loops in an interrupt, again for the same reason as above. Depending on the while() condition, this will tie up the processor for the duration it is true.

What is the "while(--x)" supposed to do? That looks to me like it would just continue to decrement 'x' forever, as it is not an operation which returns a true or false. 'x' will just wrap around from 0 to 255. I could be wrong here though.

Finally, you are testing if "data_test <= 0". Unless this is declared as a signed number, it can never be <0.

The best advice I can give is not to put any sort of loop in an interrupt. You can use an interrupt to trigger an event which takes a long time to execute by setting a 1-bit flag in the interrupt, then polling for it in main(). If it is true, make it false, then do whatever you want to do.

I always keep my main loop as a series of flag tests which don't do anything until required, so the poll time is very short. It is only when an event is triggered that the time-consuming bit needs to be done.
Any time based events can be triggered by postscale variables inside an interrupt, so no software delays need to be used. This then (dare I say it) makes your program start to look like a multi-tasking system!

I like your quote by the way! I saw another one yesterday on someone's website: "The thing I like about standards is that there are so many to choose from"

All the best,
Neil.

[neil]

Hi John, me again.

To calculate the interrupt period, remember that inside the PIC, the xtal frequency is divided by 4; so at 4MHz, your 'instruction clock' is at 1MHz, or 1MIPS.

For Timer0, you have a prescaler, so if you assign the prescaler to the watchdog timer (timer0 div by 1) it increments every micrsecond. The timer0 is an 8-bit register, so it will roll-over when it reaches 255, back to 0 and trigger the interrupt. Therefore, the interrupt period is 256us.

If you set the prescaler to divide by 256, you interrupt every 256^2, or 65536us -> 65.536ms. To get your desired ball-park interrupt rate, look in the datasheet for the possible values the prescaler can be set to, and choose one which fits best. Some people have produced spreadsheet charts for quick reference. I think Neutone is one.

To get multiples of that rep. rate, you can create a variable and increment or decrement it inside the ISR, then test for either zero, or a certain value. When true, set a flag ready to be picked up in main(), or do 'something', provided it is *short*!

Example. Provides an event every 10ms approx.

[Pete Smith]

[neil]

Oh well, the code looks shorter. I'll use that in future. Maybe I should get the old Kernaghan & Ritchie book out again!

Neil.