#INT_xxx HIGH

[Guest]

Hello everybody,

Has anyone tried to use the #INT_xxx HIGH? (version 2.231 or later)I�ve tried to use it and i�ve got some trouble.

When I put #DEVICE HIGHT_INTS on my code. It doesn�t run. When the program runs the first interruption, it locks.

Will I have to setup my INTs manually (such a fast INT)?

Thanks for any help.

[bfemmel]

If you mean a FAST int then the answer is yes; you must do all the work yourself. Where as the global interrupt hadler saves all sorts of registers, the FAST handler does nothing, if you need a register saved you need to do it yourself. Look at the assembly code generated by the compiler to see what registers it is using in your interrupt routine.

You said that your code is locking up. I would imagine that if you looked at the code you might find that it is re-entering the interrupt routine as soon as it leaves. Try toggling a bit in your interrupt routine and watching it on the scope to see if this is the case. I found this with when I tried to implement a FAST interrupt. Try clearing the appropriate interrupt bit manually in your code before you exit the routine.

[Ttelmah]

What are you doing in your interrupt handler?.
I tried a couple of experiments with it, and it seemed to work OK. It develops a second global routine, and correctly saved the registers. However it doesn't appear to generate the default 'interrupt protection', that is applied if the same routine is used in the main code, and in an interrupt handler, between the two interrupt handlers, so you have to be careful to ensure that any routines used in both locations are coded as 'inline', or disable the high priority interrupts temporarily in the low priority code. Remember also that it still has the high overhead of a standard handler...

Best Wishes

[Pbernardi]

(The post is mine, i wasn�t logged in)

Well, the HIGH is a recent implementation. Looks very similar to FAST, buts the readme says that a high interruption can stop another interruption (such a FAST), but the registers are saved.

So, I though I did�t have to configurate manually the INTs...do I have to do it?
_________________
Paulo Bernardi

[Pbernardi]

Ttelmah,

Well, actually I don�t have a interrupt handler. So I relly need?

It would be so nice if this "HIGH" just modify the priority, and let the athers things untouched.

Thanks for helping.
_________________
Paulo Bernardi

[Pbernardi]

Well, I think it can be a bug.

The CCS generated the following code:

[bfemmel]

Pbernardi wrote:

[Pbernardi]

I clear the flag in each interruption.

But bfemmel, look at it and see if it isn�t strange.

The program goes to line 0008 when the timer1 overflows.

But the timer1 is a low priority interruption, and the adress 0008 is for high priority interruption.

So, actually it doesn�t run any interruption! (the flag for timer1 is on low priority code - 0018, so it doesn�t enter the function)

It would be easy to debug if were the flag. I�d put a breakpoint inside each interruption and the program would find it, but it does�n happen.
_________________
Paulo Bernardi

[bfemmel]

Pbernardi wrote:

[Ttelmah]

It most definately should not return to address 0008. The instruction here is a goto, not a 'call', so the Retfie should return to the original caller.
I have a test program that I originally used to try this feature, which seems to work fine. I had the transmit buffer empty interrupt set as 'high', and the timer2 interrupt using the normal handler. Both correctly cleared the interrupt bits concerned, and vectored to the right routines:

[Pbernardi]

Well, I found the light.

I thought the CCS could be missconfigurating the priority bits for any reason and - bingo. The priorities were wrong.

So I configurated it by myself.

Ttelmah and bfemmel, many thanks for helping.
_________________
Paulo Bernardi