Hi,
IMPORTANT NOTE:
I recall from years ago, sometimes when Oshonsoft acts strangely, it may be the ?formatting?. I used to copy and paste the whole program into a text page, then re-introduce it back into Oshonsoft, when it usually corrected.

This time I swapped two of the GOSUBS around, and it appears to have corrected both of the last two posts.

I'll continue testing!
C.

 

The line of code above, "Next txi" just runs into that subroutine. It should not.
A subroutine should have one and only one entry method, being "called" as a subroutine or function. You cannot just have code run directly into it and expect a "Return" to work. Return to where???

 

The line of code above, "Next txi" just runs into that subroutine. It should not.
A subroutine should have one and only one entry method, being "called" as a subroutine or function. You cannot just have code run directly into it and expect a "Return" to work. Return to where???

Hi S,
Thanks for checking.
Programming still baffles me after years of practice. Most of this program has been written for me, by others.

Here is the whole GOTO section, does this clarify your statement?

EDIT: My " it appears to have corrected both of the last two posts" statement in #661 only worked in SIM, but not in real life
C

 

You still have the same fault, after "Next txi" your code simply falls to the "get_valq:" label. You cannot have a subroutine called "get_valq" and simply have code run into it... Either it is a subroutine or it is not.
After Next txi, you either exit the routine directly, or jump to some other code that is NOT a subroutine.

 

You still have the same fault, after "Next txi" your code simply falls to the "get_valq:" label. You cannot have a subroutine called "get_valq" and simply have code run into it... Either it is a subroutine or it is not.
After Next txi, you either exit the routine directly, or jump to some other code that is NOT a subroutine.

Hi S,
After running the simulator, I found this error. The program GOSUBS to get_valq" ok, then tests for the other 2x GOSUBS, then as you say drops down to "get_valq" again and RETURNS to MAIN, which is the main LOOP.

I'm now searching for earlier examples to find what I must have missed when 'Cutting and pasting' program sections.

EDIT: I found earlier programs, with a RESUME just before the first GOSUB, but this section has changed, so I can't simply add the RESUME back.
Thanks, C.

 

Program the subroutines outside the interrupt routine, they do not have to be located there. If you need it within the interrupt routine, call them and when they return, you just add another return in the main interrupt routine after the subroutine call.

 

Program the subroutines outside the interrupt routine, they do not have to be located there. If you need it within the interrupt routine, call them and when they return, you just add another return in the main interrupt routine after the subroutine call.

Hi S,
When the INTERRUPT was written, there was only one GOSUB choice, but I have modified it to 3x GOSUB choices, and that appears to have broken the flow. There are no GOSUBS in the INTERRUPT routine, only GOTOs, I'm not sure exactly what to do.

I tried a RETURN before GET_VALQ, but it didn't help.
C.

 

hi C,
Try to minimise the size/length of Code within an ISR, use Bit flags, Set during an ISR Call, that the Main program can interpret and take the required action.
E

 

hi C,
Try to minimise the size/length of Code within an ISR, use Bit flags, Set during an ISR Call, that the Main program can interpret and take the required action.
E

Hi E,
From experience, I think it's too complicated for me to attempt. There are quite a few BIT flags and PIC registers already, I'm sure I would mix them up. Is there an easier solution?
C.

 

Hi,
I'm looking at the INTERRUPT and I've asked a question elseware about CASE.

Also I notice this section of CODE which doesn't seem correct. It gives 2x examples of RCSTA.CREN, is this correct?
C.
---------------------------------------
If RCSTA.OERR = True Then '[Overrun Error bit] any error reboot serial module..
RCSTA.CREN = 0 '[Continuous Receive Enable bit]
RCSTA.CREN = 1 '[Continuous Receive Enable bit]
valid = 0
rxin = 0
Goto jump
Endif
------------------------------------------------

 

If RCSTA.OERR = True Then '[Overrun Error bit] any error reboot serial module..
RCSTA.CREN = 0 '[Continuous Receive Enable bit]
RCSTA.CREN = 1 '[Continuous Receive Enable bit]
valid = 0
rxin = 0
Goto jump
Endif

Hi C,
The red lines are correct.

The PIC USART can hold at most one character while it is receiving the next one. If you don't read that character before the next one has been received you will get an OVERRUN error (RCSTA.OERR == TRUE) which indicates that you have missed one or more characters.

In the PIC hardware, setting the OERR flag also stops any further interrupts so it is important to check OERR on each character received to ensure that you 1) haven't missed anything and 2) that the interrupts haven't been shut off. If you don't, a missed overrun will result in the USART going silent until it is reset. If you are waiting on a line of characters with OERR==True, you will wait forever until you detect and fix the error. That is why you check OERR on each character received and remedy the problem as required.

The two lines in red are how you reset an overrun error to reset the USART and restore the interrupts. Any line of data received should be discarded since it likely has missing characters.

Have fun!

 

Hi C.
RCSTA.CREN = 0 '[Continuous Receive Enable bit]
RCSTA.CREN = 1 '[Continuous Receive Enable bit]

Off > On Clears the OERR, so why do you think the code is wrong.???

 

Hi C.
RCSTA.CREN = 0 '[Continuous Receive Enable bit]
RCSTA.CREN = 1 '[Continuous Receive Enable bit]

Off > On Clears the OERR, so why do you think the code is wrong.???

Hi E,
I don't think it's wrong, but I'm going through the INTERRUPT, that I'm having trouble with, trying to figure it out, so I can follow your suggestion: "minimise the size/length of Code within an ISR, use Bit flags, Set during an ISR Call, that the Main program can interpret and take the required action. "
Now I understand.
C

 

Hi C,
The red lines are correct.

The PIC USART can hold at most one character while it is receiving the next one. If you don't read that character before the next one has been received you will get an OVERRUN error (RCSTA.OERR == TRUE) which indicates that you have missed one or more characters.

In the PIC hardware, setting the OERR flag also stops any further interrupts so it is important to check OERR on each character received to ensure that you 1) haven't missed anything and 2) that the interrupts haven't been shut off. If you don't, a missed overrun will result in the USART going silent until it is reset. If you are waiting on a line of characters with OERR==True, you will wait forever until you detect and fix the error. That is why you check OERR on each character received and remedy the problem as required.

The two lines in red are how you reset an overrun error to reset the USART and restore the interrupts. Any line of data received should be discarded since it likely has missing characters.

Have fun!

Hi J,
OFF/ON = RESET. A clear explanation, thanks.
C.

 

hi C,
Try to minimise the size/length of Code within an ISR, use Bit flags, Set during an ISR Call, that the Main program can interpret and take the required action.
E

Hi E,
I tried to minimise the INTERRUPT, but it was too difficult. I tried moving the 'msg_eol:' section into the MAIN LOOP, but got a compiler warning, so put it back.

I failed to get MIDSTR to work, but got the 'get_vald:' GOSUB to work using LEFTSTR.

Here is a shorter version of PARSING if anyone wants to Simulate it:

Enter these into SEND STRING, in this sequence, which wil eventually match the DATASWITCH:
$GNRMC,123519,A,4807.038,N,01131.000,W,022.4,084.4,230394,003.1,W*6A?
$QEIDEG,123,?
$REMOTE,1100,1200,1300,1400,1500,1600W,?

C.

 

hi C,
Change the program, section to this, it will give a clear reading

If Len(strtim) <> 0 Then ' if string is zero length don't hserout........
Hserout " T=", strtim, " N=", strlat, " W=", strlong, CrLf
Endif

If Len(strqeideg) <> 0 Then
Hserout " QEIDEG= ", strqeideg, CrLf
Endif

If Len(strtx1) <> 0 Then
Hserout " REMOTE=", "-", strtx1, "-", strtx2, "-", strtx3, "-", strtx4, "-", strtx5, CrLf
Endif

If PIR1.RCIF = 1 Then yled = 1
INTCON.GIE = 1 '????
Goto main

What exactly am I supposed to be looking for.??

 

hi C,
Change the program, section to this, it will give a clear reading

If Len(strtim) <> 0 Then ' if string is zero length don't hserout........
Hserout " T=", strtim, " N=", strlat, " W=", strlong, CrLf
Endif

If Len(strqeideg) <> 0 Then
Hserout " QEIDEG= ", strqeideg, CrLf
Endif

If Len(strtx1) <> 0 Then
Hserout " REMOTE=", "-", strtx1, "-", strtx2, "-", strtx3, "-", strtx4, "-", strtx5, CrLf
Endif

If PIR1.RCIF = 1 Then yled = 1
INTCON.GIE = 1 '????
Goto main

What exactly am I supposed to be looking for.??

Hi E,
"Change the program, section to this, it will give a clear reading", so it does, thanks.

"What exactly am I supposed to be looking for.??" Nothing in particular, only affirmation that I should carry on with this CODE.
Thanks, C.

 

Hi,
I've put the PARSE section #675 into the FULL program, and it is working, although there's an issue with [ leftstr-rightstr-midstr ] I re-tried to get [ midstr ] to work, but it never did.

Here is the now clean HSEROUTs:

Thanks, C.

 

As a note, I've seen a bug in Oshonsoft when concatenating strings.
I submitted it as a bug, but never heard back.
Example:

j = "A" + Chr(13) + Chr(10)
'Above messes up, puts in double A and chr(10)

but this works:

j = "A"
j = j + Chr(13)
j = j + Chr(10)
'Above concatenation works ok

Try adding each string characters separately to the destination variable.

EDIT: I just tried that bug with latest version of Oshonsoft, and the bug seems to be fixed. So, this may be a false alarm...

 

As a note, I've seen a bug in Oshonsoft when concatenating strings.
I submitted it as a bug, but never heard back.
Example:

j = "A" + Chr(13) + Chr(10)
'Above messes up, puts in double A and chr(10)

but this works:

j = "A"
j = j + Chr(13)
j = j + Chr(10)
'Above concatenation works ok

Try adding each string characters separately to the destination variable.

EDIT: I just tried that bug with latest version of Oshonsoft, and the bug seems to be fixed. So, this may be a false alarm...

Hi S,
Over the years we've had a few bug problems, but I think Vladimir, is working hard at correcting and updating things as best as he can. I also have the latest version, and there are quite a few differences, that a couple of years back.
I presume you are saying that the MIDSTR etc prolem, I'm having may be a bug?
I did get an answer once from Vlad, but I don't think he answers all problems.
C.