Hi,
My project has come to what I think is a time critical phase.
PIC 18F4431.
There is an INTERRUPT for a signal coming from a GPS at 5/SEC.
There is another 20mS INTERRUPT for outputing from a shift register for 5x Channel PWM mtor control.

Here is a link to quite a long thread where GUARDS were added in case of lost signals: https://forum.allaboutcircuits.com/...location-pic-in-oshonsoft.148795/post-1538180
This also has timer INTERRUPTS.

I also have SEROUTS for monitoring what's going on, and have been told that this is a problem. I'm trying to figure out a solution for this.

As usual, I'm out of my depth, while juggling

What's the best way to manage all this please?
EDIT: Since I posted this, I can see that it isn't quite correct, as there are 4x programs, with different INTERRUPTS, so generally the question is ok.
C

 

Hi C,
Are you using the High and Low priority interrupt options?
E
https://forum.allaboutcircuits.com/threads/interrupts-in-oshonsoft-basic.191971/post-1800224

 

Hi C,
Are you using the High and Low priority interrupt options?
E
https://forum.allaboutcircuits.com/threads/interrupts-in-oshonsoft-basic.191971/post-1800224

Hi E,
I remember INTERRUPT priority!

I've just added a section of CODE (SERVO control) with timer interrupt into a MAIN program which only has HIGH INTERRUPT.
There are other timer interruptss as well.

EDIT: Should each interrupt, be in it's own section, with a HIGH or LOW designation?
C

 

Try to reduce the Interrupt processing:
1) Reduce the amount of GPS traffic. Remove unwanted sentences via GPS configuration utility. Only send from the GPS what you really need.
2) In interrupt routines, store and flag the data but process results in main program loop. In other words, minimize the amount of processing done within the interrupt routine.
3) As I told you , literally a couple of years ago, use byte arrays instead of strings. Manipulating strings uses up way more CPU power/time than processing byte values. The same data is stored in a string character or a byte. It is just how you look at it for evaluation. Using string manipulation in an interrupt routine is wasting a lot of CPU cycles due to string overhead.
4) Prioritize the interrupts with high and low levels. UART could be low level as the UART has a 2 byte buffer, which gives extra time to process. Of course, this may depend on UART speed and amount of traffic.
5) Will your code work with GPS sending 4/SEC instead of 5/SEC? That saves 20% of your interrupt time right there...

If you are really dependent on debugging with SEROUT, maybe disable interrupts while outputting serial data. That will mess up "live" processing, but the debug data will be intact. It all depends on how often you need to output that debug data and how much of it. SEROUT is created with just timing loops. If you reduce the SEROUT baud rate, then delays/errors due to interrupt processing may be less frequent.

Is your UART being used in both directions? If one is just used for receive, you could use the TX part of the same UART to transmit debug data instead of SEROUT. That would be more reliable.

Good luck

 

Try to reduce the Interrupt processing:
1) Reduce the amount of GPS traffic. Remove unwanted sentences via GPS configuration utility. Only send from the GPS what you really need.
2) In interrupt routines, store and flag the data but process results in main program loop. In other words, minimize the amount of processing done within the interrupt routine.
3) As I told you , literally a couple of years ago, use byte arrays instead of strings. Manipulating strings uses up way more CPU power/time than processing byte values. The same data is stored in a string character or a byte. It is just how you look at it for evaluation. Using string manipulation in an interrupt routine is wasting a lot of CPU cycles due to string overhead.
4) Prioritize the interrupts with high and low levels. UART could be low level as the UART has a 2 byte buffer, which gives extra time to process. Of course, this may depend on UART speed and amount of traffic.
5) Will your code work with GPS sending 4/SEC instead of 5/SEC? That saves 20% of your interrupt time right there...

If you are really dependent on debugging with SEROUT, maybe disable interrupts while outputting serial data. That will mess up "live" processing, but the debug data will be intact. It all depends on how often you need to output that debug data and how much of it. SEROUT is created with just timing loops. If you reduce the SEROUT baud rate, then delays/errors due to interrupt processing may be less frequent.

Is your UART being used in both directions? If one is just used for receive, you could use the TX part of the same UART to transmit debug data instead of SEROUT. That would be more reliable.

Good luck

Hi S,
Thanks for your thought out reply.

Try to reduce the Interrupt processing:
1) Reduce the amount of GPS traffic. Remove unwanted sentences via GPS configuration utility. Only send from the GPS what you really need.
The latest M9N GPS modules I have remember the configuration, others don't.
Using M9Ns, they appear to default to a faster BAUD of 38400 without warning, so I leave them.
I set them to GNRMC only.
2) In interrupt routines, store and flag the data but process results in main program loop. In other words, minimize the amount of processing done within the interrupt routine.
I have tried this, but seem to keep adding stuff in the INTERRUPT, so they are fairly long.
I may need help with this.
3) As I told you , literally a couple of years ago, use byte arrays instead of strings. Manipulating strings uses up way more CPU power/time than processing byte values. The same data is stored in a string character or a byte. It is just how you look at it for evaluation. Using string manipulation in an interrupt routine is wasting a lot of CPU cycles due to string overhead.
This is all beyond my limits, and do get reminded, that I've been told before!
It's a shame about STRING arrays, as I prefer them, but I'll revert to BYTE arrays
4) Prioritize the interrupts with high and low levels. UART could be low level as the UART has a 2 byte buffer, which gives extra time to process. Of course, this may depend on UART speed and amount of traffic.
Everything needs to be as fast as possible as it's controlling a fast moving vehicle.
The choice is between reading the CONTROL and acting on it (SERVO/MOTOR).
If UART is HIGH and SERVO/MOTOR is LOW, I imagine there won't be much delay? This can change later?
5) Will your code work with GPS sending 4/SEC instead of 5/SEC? That saves 20% of your interrupt time right there...
Yes. While testing, I could slow them to 1/SEC, and speed up later.
If you are really dependent on debugging with SEROUT, maybe disable interrupts while outputting serial data. That will mess up "live" processing, but the debug data will be intact. It all depends on how often you need to output that debug data and how much of it. SEROUT is created with just timing loops. If you reduce the SEROUT baud rate, then delays/errors due to interrupt processing may be less frequent.
SEROUT tells me a lot of things, and I could slow it down a lot.
I have spare buttons on the PCB, that I could use to SEROUT at will.
Is your UART being used in both directions? If one is just used for receive, you could use the TX part of the same UART to transmit debug data instead of SEROUT. That would be more reliable.
Yes, On the BASE MASTER UART ,this is the CONTROL, the BASE send BORI (BASE out REMOTE in) and receives ROBI. (battery etc)
On both SLAVES, UART is only RX for the GPS and TX is the SPI-CS.
Can you explain the DEBUG DATA please? Is it what I call SEROUT at the moment?
C.

 

Yes, I was thinking that if any hardware UART was just using the RX portion, you could configure the TX portion to output your debug statements with HSEROUT instead of the software SEROUT routine. However, if you are using the TX pin for chip select (CS), then that idea won't work obviously.
That said, using the TX of a UART will not have as many problems because the characters are created by the UART hardware with independent timing (just depends on baud rate generator), CPU load and interrupt load would not affect the TX from a UART (except for delays filling the TX registers). Each character set would be correctly formed. Maybe think of changing the CS to the pin you are using for SEROUT and use the hardware UART for TX of your debug sentences. (Swap them around if possible)

 

Yes, I was thinking that if any hardware UART was just using the RX portion, you could configure the TX portion to output your debug statements with HSEROUT instead of the software SEROUT routine. However, if you are using the TX pin for chip select (CS), then that idea won't work obviously.
That said, using the TX of a UART will not have as many problems because the characters are created by the UART hardware with independent timing (just depends on baud rate generator), CPU load and interrupt load would not affect the TX from a UART (except for delays filling the TX registers). Each character set would be correctly formed. Maybe think of changing the CS to the pin you are using for SEROUT and use the hardware UART for TX of your debug sentences. (Swap them around if possible)

Hi S,
I may have misled you, both MASTER and SLAVE send SEROUT, only the SLAVE uses the SS-CS.

BASE and REMOTE-SLAVEs:
I think the SPI CS is fixed:
If the TRIS IN/OUT could be switched to OUT then SEROUT, then switch to IN then CS, this may be possible, but I don't like this idea.
Also the DATA could be sent to MASTER via SPI and output as below.

BASE and REMOTE MASTER:
The DATA could be TX'd with the UART via HSEROUT, if it doesn't spoil the BORI-ROBI control etc DATA, which shouldn't be slowed down.

Alternatively, I could push a button to 'see' the DATA, which would only affet the timing while the button was being pressed.
C.

 

Well, that is an issue I guess, can't help there. Too bad you weren't using the PIC18F44K22 (or 45K22 for more RAM) instead, it has 2 hardware EUSART devices (and seem to be pin compatible with your chip for the most part...). Not sure what other differences there are...

 

Well, that is an issue I guess, can't help there. Too bad you weren't using the PIC18F44K22 (or 45K22 for more RAM) instead, it has 2 hardware EUSART devices (and seem to be pin compatible with your chip for the most part...). Not sure what other differences there are...

Hi S,
I'll bear in mind the other PIC, but I think I spent some time comparing a selection, and chose the 18F46K20.

I commented the SEROUT out, and it smoothed a lot.
The SERVO CODE is a routing that moves them backwards and forwards, and now I've got to figure out how to just send the the angle of each channel, which I think will also speed/smooth things.
Thanks.
C.