hi C,
As John has explained OERR is set when the UART's buffer overflows.
This is the point I have explained previously.
If you are receiving a long NEMA message , [say 50 Bytes long] terminated with <crlf> and you stop reading the RX bfr when a 'W' character is detected, at say at the 30th location, the NEMA source will continue sending the remainder of the message and so the UART bfr will see an Overflow...OERR.

E

Hi E,
I remember you explaining it, and have your little routine in the program that resets the UART, but it's difficult for me to visualise what happens when a buffer overflows. I've seen the example in the D/S and kind of understand.

In the SIM, after the 'W' I think I've got it to stop putting characters in the buffer, until the next $ starts the process again. (Not easy)
C

 

In the SIM, after the 'W' I think I've got it to stop putting characters in the buffer, until the next $ starts the process again. (Not easy)

hi,
You can do that in the Sim , but not in the real NEMA message source.

Which of the 3 known signal sources is the one that must be Read for the program to work as expected.? [ I the must have source]

 

hi,
You can do that in the Sim , but not in the real NEMA message source.

Which of the 3 known signal sources is the one that must be Read for the program to work as expected.? [ I the must have source]

Hi E,
I think I follow.

How I think I've written it: Digits are arriving at the RX PIN (Unless I switch the DATASWITCH to nothing!) contantly, and when a $ arrive,the program puts the characters into BUF1 VARIABLES, until a 'W' or 'LF' or '>40' where it stops putting them in BUF1, and waits until it 'see's a '$' again.

I can now see the difference between the SIM and LIVE, but I think it still works.

SOURCES: when LIVE,
1/ GPS,
2/ 3xdigit DEGREES from 4431,
3/ a simulation of REMOTE from a MACRO on a Terminal, through a radio.
EXAMPLES: #74

C.

 

hi,
So if I follow your description correctly.
The project has no control over of when the GPS message is being sent/received.?
The other two sources are requested for data by the main program, so they do not send data until asked.??

E

 

hi,
So if I follow your description correctly.
The project has no control over of when the GPS message is being sent/received.?
The other two sources are requested for data by the main program, so they do not send data until asked.??

E

Hi E,
At the moment there is no control on any of the incoming messages. There is a DATASWITCH that switches between them, and has a no DATA position if necessary.
C.

 

hi,
You can do that in the Sim , but not in the real NEMA message source.

Which of the 3 known signal sources is the one that must be Read for the program to work as expected.? [ I the must have source]

Hi E,
You can do that in the Sim , but not in the real NEMA message source.

It's difficult for me to differentiate between the SIM and LIVE.

In order to stop DATA from arriving at the RX PIN, I can [ PIE1.RCIE = 0 'Switch off INTERRUPT ] or switch the DATASWITCH to 'no input' Which is preferable?
C.

 

n order to stop DATA from arriving at the RX PIN, I can [ PIE1.RCIE = 0 'Switch off INTERRUPT ] or switch the DATASWITCH to 'no input' Which is preferable.?

hi,
Switching Off the Interrupt will not stop the RX data from arriving at the buffer.
Between which two points is the Data switch connected and on what Event is it Opened.?

Rem, the GPS has no way of knowing that its data message is being Read or not, it will just send the complete message upto <crlf>

E

 

hi,
Switching Off the Interrupt will not stop the RX data from arriving at the buffer.
Between which two points is the Data switch connected and on what Event is it Opened.?

Rem, the GPS has no way of knowing that its data message is being Read or not, it will just send the complete message upto <crlf>

E

Hi E,
I'm trying to allow the program to PARSE a sentence before the next INTERRUPT interferes with the process.

If I switch off the INTERRUPT, even though the DATA is arriving at the BUFFER, in the off state would it affect it?

The physical way is to switch the DATASWITCH (A MUX chip with 4x INPUTS and 3x sources) to the empty INPUT.

EDITo you prefer one of these suggestions over the other?
C.

 

Hi E,
I'm trying to allow the program to PARSE a sentence before the next INTERRUPT interferes with the process.

If I switch off the INTERRUPT, even though the DATA is arriving at the BUFFER, in the off state would it affect it?

The physical way is to switch the DATASWITCH (A MUX chip with 4x INPUTS and 3x sources) to the empty INPUT.

EDITo you prefer one of these suggestions over the other?
C.

Can't the ISR use a separate buffer for each message.
The interrupt can be running constantly and fill the buffers according the switch position.

 

Can't the ISR use a separate buffer for each message.
The interrupt can be running constantly and fill the buffers according the switch position.

Hi J and E,
Yes, There can be a separate buffer for each message, but it appears to be ok with only 1x. I'll change if asked.

I was able to visualise a $Message coming in today! It's like a speeding train going by, which can't be stopped, and we're counting the carriages.

I'm now having difficulties reading my own routine, but what is supposed to happen:

As there is an almost constant stream of messages coming in from 3x sources, there needs to be more time for the MAIN LOOP to process (Including PARSE the message in the buffer and clear the buffer), so until I know what ratio MAIN%/INTERRUPT%, I was switching off the INTERUPT at the end of each message, so MAIN LOOP for a while, then switch the INTERRUPT back on, for another full message, wait for a $, then READ it fully till it's end, then repeat.

If the above is ok, then I have a choice: PIR1.RCIF = 0 or switch the DATASWITCH to to an empty INPUT and RECEIVE no DATA.
EDIT:
I hope this makes sense,
C.

 

Hi J and E,
Yes, There can be a separate buffer for each message, but it appears to be ok with only 1x. I'll change if asked.

I was able to visualise a $Message coming in today! It's like a speeding train going by, which can't be stopped, and we're counting the carriages.

I'm now having difficulties reading my own routine, but what is supposed to happen:

As there is an almost constant stream of messages coming in from 3x sources, there needs to be more time for the MAIN LOOP to process (Including PARSE the message in the buffer and clear the buffer), so until I know what ratio MAIN%/INTERRUPT%, I was switching off the INTERUPT at the end of each message, so MAIN LOOP for a while, then switch the INTERRUPT back on, for another full message, wait for a $, then READ it fully till it's end, then repeat.

If the above is ok, then I have a choice: PIR1.RCIF = 0 or switch the DATASWITCH to to an empty INPUT and RECEIVE no DATA.
EDIT:
I hope this makes sense,
C.

Why do you want to stop the RX?
The interrupt works at background and can stop when all messages are ready
You can check the ISR timing from a window in the SIM.
It is about 40us at 8MHz between characters (~ 1000us) or the MAIN runs at 96% speed.

 

Why do you want to stop the RX?
The interrupt works at background and can stop when all messages are ready
You can check the ISR timing from a window in the SIM.
It is about 40us at 8MHz between characters (~ 1000us) or the MAIN runs at 96% speed.

Hi J,
The interrupt works at background and can stop when all messages are ready
Can the Rx be left ON, even though the messages are endless one behind the other?

You can check the ISR timing from a window in the SIM.
Do you mean the 'Real time Duration' box? or where do I find the ISR timing window?
C.

 

Disabling interrupts for the UART will not stop overflow as the UART is still running, just not being processed. To eliminate RX overflow (RCSTA.OERR) or framing errors (RCSTA.FERR), you have to disable the UART altogether (clear RCSTA.CREN).
When you switch streams, odds are high you will get a framing error for the first byte, as you may be receiving it mid-stream. When switching input streams, always discard the first character.
Your interrupt routine can still process characters all the time. By checking the buffers or flags used in the interrupt routine itself, you can decide to store a character or just dump it (if you already have a full buffer). So, no need to disable RX interrupts really, just have the interrupt routine figure out what to do with each character, whether to save it or dump it. When you get a new "start of data stream", you can decide to ignore it, or overwrite the current buffer if the main program has not processed it yet (you have to set up different flags to indicate which routine is doing what...)
Bottom line, the RX interrupt routine should be short and simple, all it has to do is process one character, validate it, and decide if it is storing it or ignoring it. The MAIN program does the rest of the work.

EDIT: My example is based on your basic 16F877 chip Your registers may be slightly different, depending on which PIC it is.

 

Disabling interrupts for the UART will not stop overflow as the UART is still running, just not being processed. To eliminate RX overflow (RCSTA.OERR) or framing errors (RCSTA.FERR), you have to disable the UART altogether (clear RCSTA.CREN).
When you switch streams, odds are high you will get a framing error for the first byte, as you may be receiving it mid-stream. When switching input streams, always discard the first character.
Your interrupt routine can still process characters all the time. By checking the buffers or flags used in the interrupt routine itself, you can decide to store a character or just dump it (if you already have a full buffer). So, no need to disable RX interrupts really, just have the interrupt routine figure out what to do with each character, whether to save it or dump it. When you get a new "start of data stream", you can decide to ignore it, or overwrite the current buffer if the main program has not processed it yet (you have to set up different flags to indicate which routine is doing what...)
Bottom line, the RX interrupt routine should be short and simple, all it has to do is process one character, validate it, and decide if it is storing it or ignoring it. The MAIN program does the rest of the work.

EDIT: My example is based on your basic 16F877 chip Your registers may be slightly different, depending on which PIC it is.

Hi S,

Disabling interrupts for the UART will not stop overflow as the UART is still running, just not being processed. To eliminate RX overflow (RCSTA.OERR) or framing errors (RCSTA.FERR), you have to disable the UART altogether (clear RCSTA.CREN).
When you switch streams, odds are high you will get a framing error for the first byte, as you may be receiving it mid-stream. When switching input streams, always discard the first character.
Your interrupt routine can still process characters all the time. By checking the buffers or flags used in the interrupt routine itself, you can decide to store a character or just dump it (if you already have a full buffer). So, no need to disable RX interrupts really, just have the interrupt routine figure out what to do with each character, whether to save it or dump it. When you get a new "start of data stream", you can decide to ignore it, or overwrite the current buffer if the main program has not processed it yet (you have to set up different flags to indicate which routine is doing what...)
Bottom line, the RX interrupt routine should be short and simple, all it has to do is process one character, validate it, and decide if it is storing it or ignoring it. The MAIN program does the rest of the work.

EDIT: My example is based on your basic 16F877 chip Your registers may be slightly different, depending on which PIC it is.

Hi S,
Here's comment in the program, from many moons ago, from 'E':
'NOTE:After STR_DONE.............(or SBUF)
'To avoid A framing error, you are best To switch dataswitch between Ascii characters
'by checking BAUDCON.RCIDL=1. If it is =1,
'Then the UART is idle And Not receiving any serial data stream.

Actually, I had it working with the INTERRUPT on, but I've lost that program, and working through a newer one (I'm a bit slow).

I'll keep the INTERRUPT switched on. It's hard to visualise just how fast processors can work.

My INTERRUPT routine, does ignore unwanted digits, and waits for a '$' which is the beginning of all messages. At the moment though, when another message starts it doesn't finish the previous one, Doh!

Thanks.
C.

 

hi C,
Would you kindly post the original text, you claim I posted and in context.?
E.

NOTE:After STR_DONE.............(or SBUF)
'To avoid A framing error, you are best To switch dataswitch between Ascii characters
'by checking BAUDCON.RCIDL=1. If it is =1,
'Then the UART is idle And Not receiving any serial data stream.

 

That is correct, if you can determine that UART is idle with BAUDCON.RCIDL , that is the best time to switch inputs. But, depending on timing, best to still check FERR and OERR after switching.

 

hi C,
Would you kindly post the original text, you claim I posted and in context.?
E.

NOTE:After STR_DONE.............(or SBUF)
'To avoid A framing error, you are best To switch dataswitch between Ascii characters
'by checking BAUDCON.RCIDL=1. If it is =1,
'Then the UART is idle And Not receiving any serial data stream.

Hi E,
I searched but couldn't find the original, so appologies to 'J' if it was he that posted it.
I leave the comment there to remind me, but in the SIM, I never get BAUDCON.RCIDL=1, perhaps because it IS the SIM and not LIVE?
C

 

That is correct, if you can determine that UART is idle with BAUDCON.RCIDL , that is the best time to switch inputs. But, depending on timing, best to still check FERR and OERR after switching.

Hi S,
During my search for the answer to #115, I saw probably your original post to explain this. Sorry to be so slow.

Also I'm just getting used to adding FLAGS. I assume they are used, 'say' at the end of a process, to move to the next proces, by IF FLAG.
C

 

hi C,
I queried that post, it is not typed in my writing style.

Query: I understand that you have set the NMEA message output rate to 5 per second, if so, do you really need a 0.2Sec GPS update rate for the project.?

E

 

hi C,
I queried that post, it is not typed in my writing style.

Query: I understand that you have set the NMEA message output rate to 5 per second, if so, do you really need a 0.2Sec GPS update rate for the project.?

E

Hi E,
Ah! a bit of forensics there, and giving you the credit, where it's not due

I was playing at programming the GPS module, and found that I could switch to only the $message wanted, and change the time period. I don't think that it does any harm to have 5x, and as the DATASWITCH 'looks' towards the GPS, there is no delay for the next message.
C