Facebook
Google
GitHub
Linkedin
Oshonsoft programs with INTERRUPTS and PARSE
- Thread starter camerart
- Start date
Hi E,
Thanks for your CODE, I'll check it in my SIM. Were you able to test my CODE in #72, with your SIM? I don't think I can cope with two CODE versions, if mine is no good, I'll switch to yours.
Did you notice the note also in #72, where the end of all $Sentences is now a W?
C.
hi C,
Code in #72, sorry to say, it did not work correctly even with a simple message, a number of problems
The last one I posted was the remnants of #72
I saw the 'W' but why did you change from '?'
E
BTW: you are getting all these set backs by not sitting down and preparing a simple flow chart of events in the program sections and how they effect the program as a whole.
Of the 3 input sources, messages which do you have control over when they are be Read.? obviously not the GPS
Code in #72, sorry to say, it did not work correctly even with a simple message, a number of problems
The last one I posted was the remnants of #72
I saw the 'W' but why did you change from '?'
E
BTW: you are getting all these set backs by not sitting down and preparing a simple flow chart of events in the program sections and how they effect the program as a whole.
Of the 3 input sources, messages which do you have control over when they are be Read.? obviously not the GPS
Hi E,
I wonder why #72 didn't work with your system, and it does on mine?
Ok, as it sounds like you have repaired #72 with yours, I'll switch to yours. I hope 'J' and 'MR C' agree?
As mentioned, I don't now need 70ish BUFFER length as since we started, I have added an altimeter/barometer, so don't need the end of the $NMEA sentence. This means that if I curtail the message after the W I have all I need.
I was advised to start again and work through it step by step. I am not capable of flow charts, they just change to mush. My only way is to trial and error, till a working CODE appears out of the depths.
In #74 I posted examples of the 3x $Sentences, that are used. The COMPASS, ALTIMETER, RADIO and SCREEN are all gleaned using SPI.
EDIT I change this: If char = "W" Or char = 0x0a Or rxin > 39 Then '*** ends the message ****
Which also takes care of too long messages.
C.
Last edited:
hi C,
Just because you stop reading at 'W' does not mean that the $NMEA stops being sent, so if you do not read the remainder, they will cause a UART Overflow error set.
So when you next set Int Enable and get an interrupt you will have to clear the RX buffer etc...
E
Hi E,
It's a pity that you can't run my program, as it takes care of any overflow. It's quite hard for me to see why, as I had to concentrate hard to get it to do that.
Perhaps some one else with a Simulator can try and overflow it? 'J' reported back #75 and onwards but didn't mention this problem.
C.
Hi E,hi ,
So does the program I posted.
E
Yes, I noticed that.
I tried some tests in the SIM, and saw that where mine resets everything to '0' at $, I found that yours keeps adding digits at whatever RXI it is at, so missing that $Sentence.
I would send a video, if the SIM didn't take forever each time
I'll try more tests on both programs, and try to find the best out of them, if I can.
Cheers,
C.
Hi E,
I've been playing with the GPS, and learnt how to program them. I soldered a cell in place of the backup power capacitor, then got the GPS to only 'see' the NMEA sentence, we need, $GNRMC. Then I got it to send Sentences 5/Sec.
I have a DATASWITCH that switches between the 3x sources.
In the program after each sentence has been parsed, it switches to the next source, and waits for a clean sentence, and so on.
C.
Hi E,hi ,
So does the program I posted.
E
Thanks for your program, I usually just adopt them, but this time, I was advised to make an INTERRUPT routine, as small as possible, with no gosubs or gotos, so that I would understand what's happening.
As usual I kind of understand what's happening, but it's never that clear.
Anyway, I found a similar error in my effort, to the one I found in your program, so I modified mine, and now I think it is working. I've tried all sorts of messages, with errors and too long etc, but it keeps getting the correct ones.
If anyone finds problems with it let me know, or I'll try adding the PARSE section into it, before adding it to the MAIN program.
C.
Do you know it is working?
Did you get valid results?
Try only to parse one short sentence and look what you get from parsing.
No interrupts, because they should work now, no pin declarations only variable declarations and making a string from the buffer.
Computer hardware, software, programming is an engineering discipline.
Getting systems to work by trial and error is a direct path to frustration and failure.
Things may appear to work for wrong reasons. Two wrongs do not make it right.
It may work today. It will fail tomorrow.
Sorry to have to tell you this.
Hi Mr C,
I appreciate your comments, but I've never been a good programmer, and I've had this conversation many times, this is why I'm still using BASIC, that I learnt by osmosis in the 80s, when my son had his Spectrum for Christmas.
This time, as advised, I tried re-writing the INTERRUPT section of the MAIN program. I concentrated to the point of almost being ill, and managed to write 75% of it by skill and 25% by trial and testing (Using the Simulator) This is the best I can do I'm afraid.
Cheers, C.
Hi J,
I think it is working, but only on the Simulator so far.
The program in #91 is only the INTERRUPT test program.
The program in #92 is #91 with the PARSE added to it.
Using the $Sentences in #74 and the SIM, I first tried the shorter one, then the longer ones, which all parsed out the relevant VARIABLES.
Then I tried spoiling the sentences, and adding them togeher in a long STRING, which also worked. (So far)
I'm sure it could be improved. I may have another look on a good day.
It would be appreciated if someone else could test it in their Simulator.
C
Hi C
OERR ( overflow error) is set when a new character is received before you read the last one received. There is no place to store the new character since RCREG still has the old one that hasn’t been read.
When OERR is set, the receiver shuts down and no more interrupts (or RCIF to poll) will be generated until you reset the USART by disabling then reenabling it.
OERR can be avoided only when you detect RCIF and read RCREG faster than the character rate (about 1ms/char at 9600 baud). Typical solutions include:
Lower the latency between RCIF set and reading the character just received. Interrupt driven buffers are common. Polling RCIF can be problematic.
Process characters faster.
Lower the baudrate.
Add some pacing - delay between characters - at the transmitter.
Use a flow control protocol like RTS/CTS, XON/XOFF etc.
Oshensoft may provide something too.
It is important to test OERR on each character received and take appropriate action whenever it is set i.e. reset the USART and discard any message in progress due to lost characters.
OERR ( overflow error) is set when a new character is received before you read the last one received. There is no place to store the new character since RCREG still has the old one that hasn’t been read.
When OERR is set, the receiver shuts down and no more interrupts (or RCIF to poll) will be generated until you reset the USART by disabling then reenabling it.
OERR can be avoided only when you detect RCIF and read RCREG faster than the character rate (about 1ms/char at 9600 baud). Typical solutions include:
Lower the latency between RCIF set and reading the character just received. Interrupt driven buffers are common. Polling RCIF can be problematic.
Process characters faster.
Lower the baudrate.
Add some pacing - delay between characters - at the transmitter.
Use a flow control protocol like RTS/CTS, XON/XOFF etc.
Oshensoft may provide something too.
It is important to test OERR on each character received and take appropriate action whenever it is set i.e. reset the USART and discard any message in progress due to lost characters.
Last edited:
Hi JT,
Ok, I think I've got it.
I am simulating an INTERRUPT routine in Oshonsoft, and a forum member reports he gets OERR overload. It's possible that his system is not up to date, other than that I don't see why he gets the error, and I don't. I'll test it live on the PCB.
Thanks
C.
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
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
