Questions about int_global

[E_Blue]

I'm struggling with High and Low interrupts in a PIC18F67J50, time to time, the CCS interrupt dispatcher make a mess with FSR and BSR registers, specially with FSR in delay routines and with the BSR with USB stack.

So, I wonder if there an example about how to, and what register take in account when we do our own interrupt dispatcher.

I know how to handle interrupts, I start with ASM in 1999, so I'm familiar with those procedures but I'm dubious about all those temporary registers that CCS compiler uses to pass data from one function to another, for example.

I don't know their RAM addresses and how many they are.
_________________
Electric Blue

[Ttelmah]

ex_glint.c with the compiler.

On what registers to save, this is completely dependent on what _your_ code does in the interrupts.
Ideally you look through the assembler for every routine in the interrupt, and then save every register these use.
CCS's approach is to save everything, and should be totally OK.

You don't say what compiler version?.
With the current releases, I've not seen a single problem with BSR or FSR. Thing that _will_ cause problems are where any variable is 16bit or larger, and is accessed inside the ISR, and in the main code. Two solutions:

[PCM programmer]

Some posts from Ttelmah with sample code for #int_global:
http://www.ccsinfo.com/forum/viewtopic.php?t=54131&start=7
http://www.ccsinfo.com/forum/viewtopic.php?t=49614&start=5
http://www.ccsinfo.com/forum/viewtopic.php?t=44491&start=3
http://www.ccsinfo.com/forum/viewtopic.php?t=50807&start=6
http://www.ccsinfo.com/forum/viewtopic.php?t=50018

[E_Blue]

I'm using V5.048

I was using

[jeremiah]

Perhaps someone with 5.048 (preferably the OP, but either way I don't have that version currently) can generate a small test program so we can take a look at the assembly and see what is going on (and hopefully generate a bug report for CCS for someone to email).

It would just need the basics:
device include
fuses
clock settings
interrupt handler
main

They don't have to do anything particularly interesting since all we care about is seeing the context save process CCS generates.

[Ttelmah]

So how do you declare the actual interrupt you are using as high priority?.

You do understand that _two_ things are needed before an interrupt is high priority?.

First 'HIGH_INTS=TRUE', and then the interrupt that you want to be high priority has to be declared as:

[E_Blue]

Yes I'm using, or was using, both 'HIGH_INTS=TRUE' and #INT_RDA2 HIGH .

I'm dubious about #priority

It's ok to use

[Ttelmah]

#PRIORITY has nothing to do with the priority of interrupts!.....

It dates from before PIC's had any form of hardware priority. It sets the order that the interrupt flags are polled in the CCS global handler. So if two interrupts occur 'together', the one set first in this, will be the one seen. This will then be handled, and followed by the second interrupt.

In fact though by default the order is the order the interrupt handlers are declared if this is omitted. I prefer to use this, since then the order in the code, is the order the handlers are dealt with.

So, get rid of #priority, or only include interrupts using the standard handler.
Or preferably just declare your interrupt handlers in the order you want them to be checked.

What on earth are you using INT_AD for?.

Understand that getting into and out of an interrupt handler usually takes longer than the ADC takes to perform a conversion (or a very similar time). INT_AD should only be used, where you are using an 'event' to trigger the ADC (CCP). Otherwise this is extra unwanted complexity.

Just amended this.
Have you looked at the errata sheet?.
Add 'delay_cycles(1); delay_cycles(1)' after any instruction that enables the UART (setup_uart), or make sure you disable the interrupts before this is done.
There is also a problem if using timer1 or 3 in async mode.

[E_Blue]

If I use only one interrupt level the programs runs ok, so I'm running the program that way now.

So, I think, the problem is in the interrupt dispatcher.


I use INT_AD because the program must process two USART at 19200bps, USB data and one SPI at 3MHZ, all running from an state machine on CCP1 and CCP2 interrupts.

The CCP1 INT have a lot of work to do, so when start an AD conversion continues with rest of the tasks.
Plus the A/D is running slow on purpose because is running on high noisy environment.
_________________
Electric Blue

[Ttelmah]

So, don't have a CCP1 interrupt.

Program the CCP with a special event trigger to start the ADC.

Then use the ADC interrupt to read the ADC, and do the tasks you want from the CCP.

The more interrupts you have, the longer the latency in the worst case.

Separately, if there is an SPI slave, this is the one that needs to be high priority. SPI has no margin at all, _requiring_ the data to be loaded before the next transaction starts. The UART has a whole character time of buffering.

It's almost certainly when you enable the high priority UART interrupt it is delaying the SPI too much, hence your problems....

It sounds as if you are doing much too much inside interrupts.

Running the ADC slower does not help it reject noise. It makes it's overall accuracy worse. Once the internal capacitor is disconnected from the external pin, it starts charging or discharging according to leakages in the chip. By the time the last bit is read, this becomes significant. Microchip generally recommend that the Tad is as close to their minimum specified as possible.

In fact the data sheet for your chip says:
"For correct A/D conversions, the A/D conversion clock
(TAD) must be as short as possible but greater than the
minimum TAD".

[E_Blue]

I'm using CCP1 this way

[Ttelmah]

So, don't enable INT_CCP1.
Just use INT_AD.
Get rid of the extra interrupt.

It'll arrive at INT_AD automatically after the CCP event has triggered _and_ the ADC has converted. As setup, this is already starting an ADC conversion. Speed the ADC up. I think you misunderstand, and think that the ADC will integrate while converting if you run it slower. It doesn't. It's a successive approximation ADC and the capacitor is disconnected during conversion.

[E_Blue]

Yes I have both interrupts running CCP1 and A/D besides the other ones(USART2,USB,CCP2 and Timer1)

The program doesn't run at same speed all the time, have 3 clock speeds, 48MHZ full running, 8MHz in low power mode, and 32KHz during sleep mode.
_________________
Electric Blue

[Ttelmah]

Understand, that the CCP1 interrupt triggers on it's event, and then the INT_AD interrupt will trigger after the ADC has done the conversion. Using both interrupts here is just wasting the seventy or so cycles it takes to get into and out of the first interrupt. Just use INT_AD, and handle the CCP events in this.

Then how can you have INT_TIMER1?. This will never trigger. INT_TIMER1 triggers when timer1, wraps from FFFF to 0000. You are resetting timer1, when it matches the CCP, so it never does this wrap.

Interrupts need to be thought about, not just used 'willy nilly'.

[E_Blue]

Timer1 INT only runs when is in sleep mode, so, before get into sleep mode I change the Timer1 and CCP setup.

In sleep mode the program runs a 32768Hz every 2 seconds.
_________________
Electric Blue