Hi,
I'm using 2x INTERRUPTS on an 18F4431 PIC.

1x is the HW QEI, which must count all rotation, and 1x GPS reader, where the GPS outputs 5x/sec, and needs to be read as many times as possible.

Both are set to HIGH, and I wonder how they actually work together.

Has anyone any advice how to manage them please?

Cheers, Camerart

 

Hi,
I'm using 2x INTERRUPTS on an 18F4431 PIC.

1x is the HW QEI, which must count all rotation, and 1x GPS reader, where the GPS outputs 5x/sec, and needs to be read as many times as possible.

Both are set to HIGH, and I wonder how they actually work together.

Has anyone any advice how to manage them please?

Cheers, Camerart

You are asking how to manage two separate interrupts. The answer depends on the specific hardware of the PIC18F4431, but the simplest way to do it is to arrange things so each interrupt routine runs to completion before another interrupt service routine can run. This may result in interrupt service routines being delayed while the other one is being serviced. To avoid this latency problem, you want to make them as short and efficient as possible.

I will take a look at the datasheet for the PIC 18F4431 to add any additional insights.

 

It looks like the PIC18F4431 has the flexibility to implement a variety of interrupt management schemes. I suggest you start simple and work your way up. At the top of p.97 in the current datasheet is the following paragraph:

When the IPEN bit is cleared (default state), the interrupt priority feature is disabled and interrupts are compatible with PIC® mid-range devices. In Compatibility mode, the interrupt priority bits for each source have no effect. INTCON<6> is the PEIE bit, which enables/disables all peripheral interrupt sources. INTCON<7> is the GIE bit, which enables/disables all interrupt sources. All interrupts branch to address 000008h in Compatibility mode.​

​

I suggest that you use this Compatibility mode to get started, unless you have a reason for not doing this.

 

Your interrupt routine will have flags set in a register indicating which interrupt was triggered. Your routine should determine which flag is set and process that one, then clear that flag. You can then check other flags before exiting the interrupt routine.
In some cases, depending on processor, you can just process one interrupt, clear flag and exit the routine and the processor will then trigger the next interrupt. It all depends on how you handle the interrupt flags and the type of processor.
If your interrupt routine(s) are short, you can simply check all expected interrupt flags for any or all interrupts that have been triggered before exiting the interrupt handler routine.
An interrupt routine can handle many interrupt flags (multiple interrupts) in one pass. If something triggers an interrupt while still in the interrupt handler, it will get triggered the interrupt routine again when you exit that routine (if you don't check all the flags on exit)
The key is to keep the interrupt handling routine as short as possible

 

It looks like the PIC18F4431 has the flexibility to implement a variety of interrupt management schemes. I suggest you start simple and work your way up. At the top of p.97 in the current datasheet is the following paragraph:

When the IPEN bit is cleared (default state), the interrupt priority feature is disabled and interrupts are compatible with PIC® mid-range devices. In Compatibility mode, the interrupt priority bits for each source have no effect. INTCON<6> is the PEIE bit, which enables/disables all peripheral interrupt sources. INTCON<7> is the GIE bit, which enables/disables all interrupt sources. All interrupts branch to address 000008h in Compatibility mode.​

​

I suggest that you use this Compatibility mode to get started, unless you have a reason for not doing this.

Hi P,
The GPS section is a new addition to the 4431 PIC as it was moved from a second PIC on the PCB, and has been running for a long time.
Re compatibilty mode, I'll look into it.
Thanks.
C

 

Your interrupt routine will have flags set in a register indicating which interrupt was triggered. Your routine should determine which flag is set and process that one, then clear that flag. You can then check other flags before exiting the interrupt routine.
In some cases, depending on processor, you can just process one interrupt, clear flag and exit the routine and the processor will then trigger the next interrupt. It all depends on how you handle the interrupt flags and the type of processor.
If your interrupt routine(s) are short, you can simply check all expected interrupt flags for any or all interrupts that have been triggered before exiting the interrupt handler routine.
An interrupt routine can handle many interrupt flags (multiple interrupts) in one pass. If something triggers an interrupt while still in the interrupt handler, it will get triggered the interrupt routine again when you exit that routine (if you don't check all the flags on exit)
The key is to keep the interrupt handling routine as short as possible

Hi S,
As the QEI is HW, will it keep counting while the GPS flag is up? While moving the QEI input, there is a constant stream of counts, so does this mean that while moving the QEI input there is a constant stream of flags?

It's difficult to understand how 2x things could happen at the same time.
C.

 

Hi,
While searching this topic, I cam across threads from me previously e,g, https://forum.allaboutcircuits.com/...rams-with-interrupts-and-parse.168960/page-18

I think I've got to find a video, that explains it visually, instead of words.

One question: On 18F4431 the QEI section is HW, so can this count in parallel to the other sections of the program, including the GPS interrupt?
C

 

In general, it is the case that most hardware does not need constant attention. There are two numbers that you should consider. How often does a hardware device need attention and how long does it take to give it the attention that it needs. From those numbers you can form an idea of how simultaneous events, i.e., two interrupt flags being set at the same time, will work itself out regardless of the order in which they are serviced. What you want to avoid is having the interrupt service time exceed the interval between successive interrupts. In practice you don't even want it to be close.

 

In general, it is the case that most hardware does not need constant attention. There are two numbers that you should consider. How often does a hardware device need attention and how long does it take to give it the attention that it needs. From those numbers you can form an idea of how simultaneous events, i.e., two interrupt flags being set at the same time, will work itself out regardless of the order in which they are serviced. What you want to avoid is having the interrupt service time exceed the interval between successive interrupts. In practice you don't even want it to be close.

Hi P,
I think I haven't really comprehended the concept of the clock speed, which is 8X4 32mHz, and the switching ability.

Also the QEI section is hardware, and I haven't figured out clearly, whether this can count the rotation of the incremental encoder, in parallel with the rest of the program inluding the GPS interrupt or is it slotting it's interrupts, between the GPS ones.
C.

 

Hi P,
I think I haven't really comprehended the concept of the clock speed, which is 8X4 32mHz, and the switching ability.

Also the QEI section is hardware, and I haven't figured out clearly, whether this can count the rotation of the incremental encoder, in parallel with the rest of the program inluding the GPS interrupt or is it slotting it's interrupts, between the GPS ones.
C.

I don't understand the meaning of "8x4" in conjunction with "32mHz". FYI "mHz' means millihertz. I think you meant "MHz" which is "Megahertz". I still don't understand the problem you are having.

In the simplest possible terms, you need to know:

1. How often do the interrupts occur in the worst-case scenario
2. How long does it take to service each interrupt

From there you can determine one or more alternative strategies.

 

I don't understand the meaning of "8x4" in conjunction with "32mHz". FYI "mHz' means millihertz. I think you meant "MHz" which is "Megahertz". I still don't understand the problem you are having.

In the simplest possible terms, you need to know:

1. How often do the interrupts occur in the worst-case scenario
2. How long does it take to service each interrupt

From there you can determine one or more alternative strategies.

Hi P,
I knew to have the capital H for Mr Hertz, but not milli Mega. There is an 8MHz Crystal, with a PLL X4.

The QEI counts an incremental encoder that may be turned 'say' 180 Deg in perhaps 1/2 sec. As it is quadrature, I pressume this is 180X4.

The GPS is inputting at 5/Sec constantly, and should be read as many times as possible.

C.

 

Hi P,
I knew to have the capital H for Mr Hertz, but not milli Mega. There is an 8MHz Crystal, with a PLL X4.

The QEI counts an incremental encoder that may be turned 'say' 180 Deg. As it is quadrature, I pressume this is X4, and may be turned at any time for perhaps 1/2 second.

The GPS is inputting at 5/Sec constantly, and should be read as many times as possible.

C.

Got it on the 8x4 with the 8 MHz crystal, that makes sense. So, the GPS module generates 5 interrupts per second or one every 200 milliseconds. Let us assume for the sake of argument that it takes 1 millisecond to service, that is 32,000 clock cycles. this would not be considered a heavy load for a typical CPU.

Now the encoder. It depends on how you are counting the transitions. I have never done this before, but I remember that others have broken the movement regime into slow, medium, and fast processing steps so that you don't need to count every transition of both of the edges. So, count the number of transitions for 180° of movement. Let us say it is 200. this would mean 400 transitions per second or 2.5 milliseconds per transition. Then assuming that an interrupt could be processed in 50 microseconds, there should be plenty of time to service of both of the interrupts without the need to implement a priority scheme.

If you can't arrange things to work under those kinds of conditions for some reason you can always go back and implement the scheme where the high priority interrupt can interrupt the low priority interrupt.

 

In the days before dedicated QEI hardware we used the input capture feature of the timer module to handle this. This would help you determine how fast the pulses are coming in.

 

hi papa,
A little previous background knowledge of the project.

GPS Baud rate 9600, message length approx 50 characters.
The QEI is a hardware module in the 18F4431

E

 

hi papa,
A little previous background knowledge of the project.

GPS Baud rate 9600, message length approx 50 characters.
The QEI is a hardware module in the 18F4431

E

Thank you @ericgibbs. That additional context is helpful. I knew the QEI was a module inside the PIC processor, and I have spent the last 45 minutes reading §17.2 of the processor datasheet to familiarize myself with the QEI peripheral.

So, the problem revolves around servicing the serial port interrupt assuming the 50 characters are arriving at the synchronous limit with a framing of 8N1 or a total of 10 bits/character. that is approximately 1.04 milliseconds per character. The PIC 18F4431 should be able to handle the serial input of a character in 50 microseconds (1600 clock cycles @ 32 MHz.).

I don't know how the QEI module is being used but I know that it does not interrupt on each transition of the quadrature input. So, the interrupt rate has got to be pretty slow if it is being used in position mode. The interrupts in position mode can occur for:

1. A period match event, POSCNT=MAXCNT
2. A POSCNT rollover in period mode only
3. An index pulse

It seems like these cannot occur at a very high rate.

 

I can add that they way to handle burst messages from a serial port on a character-by-character basis is to implement a circular buffer with about 2.5 times the capacity of a single message.

 

hi papa,
IIRC the GPS data is being parsed/processed and output to the flight control motors in real time.

E
Note: I did help Camerart some years ago to debug the QEI and GPS data acquisition programs.

 

hi papa,
IIRC the GPS data is being parsed/processed and output to the flight control motors in real time.

E
Note: I did help Camerart some years ago to debug the QEI and GPS data acquisition programs.

I remember that and I vaguely remember that thread, but don't recall the details of that design. I take it that this processor was not previously available, and this is a design upgrade. It still comes down to what needs to be done and how often the processor needs to do it. The processor seems like it should have the capability to do what is needed.

IIRC that previous project was done in Oshensoft, is that still the intention?

 

Hi P and E,
This project was started years ago, and I've had lots of help from E, and many others, with various questions, some of my questions were answered months or years ago, and as it's quite complicated and takes me a lot of concentration to proceded, and often they slip from my mind, only to turn up when I do a general search, and find my questions. Lots of it is going in though, and I'm much improved. I am only capable of the BASIC language, and use Oshonsoft because it suits me and I support the project.

I'll have to read P's replies more carefully, taking notes, so I hope to 'get' it this time.
I've read the QEI section of the D/S many times, but I know less the more I read. As E say the QEI has been running since being debugged, and only went wonky since the introduction of this second interrupt (GPS). I haven't altered the ISR, and I'm sure I have to to get them both 'happy'

I note that P says he doesn't think that the QEI does not interrupt on each transition of the quadrature input, which answers a question I had. How it is being read at the moment, is simply read [cap2bufl and cap2bufh] in the main loop.

Am I correct then, that reading the '2x cap2bufs' and each sentence of the GPS need to be timed and slotted in line, using the flags that each of them have?
So if I'm correct, the GPS sentence is stored in a buffer, and the QEI is stored on each of it's registers, so for example the QEI cap2bufs could be read as the GPS is parsed.
(I may get words mixed up, so correct me if necessary)
C.

 

Hi P and E,
This project was started years ago, and I've had lots of help from E, and many others, with various questions, some of my questions were answered months or years ago, and as it's quite complicated and takes me a lot of concentration to proceded, and often they slip from my mind, only to turn up when I do a general search, and find my questions. Lots of it is going in though, and I'm much improved. I am only capable of the BASIC language, and use Oshonsoft because it suits me and I support the project.

I'll have to read P's replies carefully, taking notes, so I 'get' it this time.
I've read the QEI section of the D/S many times, but I know less the more I read. As E say this has been running since being debugged, until the introduction of this second interrupt. I haven't altered the ISR, and I'm sure I have to to get them both 'happy'

I note that P says he doesn't think each movement needs and interrupt, which answers a question I had. How it is being read at the moment, is simply read [cap2bufl and cap2bufh] in the main loop.

Am I correct then, that reading the '2x cap2bufs' and each character of the GPS need to be timed and slotted, using the flags that each of them have?
So if I'm correct, the GPS sentence is stored in a buffer, and the QEI is stored on each of it's registers, so for example the QEI cap2bufs could be read as the GPS is parsed.
(I may get words mixed up, so correct me if necessary)
C.
C.

Almost. One thing you need to remember is that when reading a value from two separate registers you need to make sure the process is not disturbed by an interrupt. In any piece of code, which is not an interrupt service routine, you need to disable interrupts before you read the two register and you need to enable interrupts when you finish reading the pair of registers.

Maybe it would be helpful if you can describe the setup of the QEI module, and what should happen when the module generates an interrupt.