RX in-SERIN PARSE CODE (Oshonsoft)

Thread Starter

camerart

Joined Feb 25, 2013
3,283
Hi,
I have CODE that reads RX IN DATA and PARSES it into sections, for use later.
Because of other clashes, I want to try SERIN instead.
Is this a completely different CODE or can I slip the SERIN into where the RX IN was for PARSING.

As I don't know the term for the RX IN CODE, I've posted a section:

Gereral answers please, just so I know which way to look.
Cheers, Camerart
Code:
On High Interrupt
Save System

If PIE1.RCIE = 1 Then
    'overrun error
    If RCSTA.OERR = 1 Then
        RCSTA.CREN = 0  'disable UART
        RXIRQchar = RCREG  '1    'clear UART RX registers
        RXIRQchar = RCREG  '2
        RCSTA.CREN = 1  'reenable UART
        Gosub IRQinitBuf  're-init buffer, discard bad sentence
    Goto RXIRQdone  'done, wait for next character
Endif  'OERR

'framing error
If RCSTA.FERR = 1 Then
    RXIRQchar = RCREG  'Read char to clear RCIF and FERR
    Gosub IRQinitBuf  'Re-init buffer, discard bad sentence
    Goto RXIRQdone  'wait for next
Endif  'FERR

'No UART errors, process character
If PIR1.RCIF = 1 Then
    RXIRQchar = RCREG  'read the received char, clears RCIF

    'Look for $, start/restart filling buf when found
    If RXIRQchar = "$" Then  'Start (re)filling buf on any $
        Gosub IRQinitBuf  'init buffer, index and flags
        buf(rxpsn) = RXIRQchar  'store $
        buf_fill = 1  'start storing the sentence
        Goto RXIRQdone  'done with this character
    Endif  'char was $

    'no UART errors and character was not $
    'If $ was found previously, process character looking for W and no buffer overflow.
    'If haven't found $ yet, just ignore character.

        If buf_fill = 1 Then  'if filling buffer, see if there is room in buf
            If rxpsn >= (rxbufsize - 1) Then  'last char was at end of buf - buffer overflow so..
            Gosub IRQinitBuf  'restart buffer, discard sentence
            RXerr = 1  'let main know that the buffer overflowed and is restarting
            Goto RXIRQdone  'done, resume looking for next $
        Endif  'buffer overflow

        rxpsn = rxpsn + 1  'else, there's room in buf so bump index and store character, might be W
        buf(rxpsn) = RXIRQchar

            If RXIRQchar = "W" Then  'if end of sentence..
                RCSTA.CREN = 0  'shut down UART
                PIE1.RCIE = 0
                buf_done = 1  'flag buf full
                Goto RXIRQdone  'and bye!
            Endif  'RXIRQchar was W
        Endif  'if buf_fill = 1
    Endif  'RCIF=1
Endif  'RCIE=1

'Exit point for each RXinterrupt. Process timers
RXIRQdone:
 

Ian Rogers

Joined Dec 12, 2012
1,028
Serin is quite a different beasty... Software serial will not be easy to get this done will.. No interrupts at all.

Hserin is similar to whats happening now.

Looking a your ISR its very cluttered... I would just read in the sentence in the interrupt and parse it outside the interrupt.
When you say "It Clashes"! With what? if your answer is preceeding sentences, then the serial is coming in too fast.
 

ericgibbs

Joined Jan 29, 2010
16,792
hi C,
We covered this about 7 years ago.;)
In the ISR just read and store the message, set a Flag and then outside the ISR use the csv parser subroutine to pick out the variables
E
 

Thread Starter

camerart

Joined Feb 25, 2013
3,283
Serin is quite a different beasty... Software serial will not be easy to get this done will.. No interrupts at all.

Hserin is similar to whats happening now.

Looking a your ISR its very cluttered... I would just read in the sentence in the interrupt and parse it outside the interrupt.
When you say "It Clashes"! With what? if your answer is preceeding sentences, then the serial is coming in too fast.
Hi I,
So far I've got SERIN to produce a 'full' message, but it's intermittent.

At the moment there is a 2 into1 RX switch, working fine, 1/2 is RC and 1/2 is GPS. The RC section is Asyncronous, (At the moment) and needs a kind of toggle switch, for RX TX on both sides. As this is tricky, then we are looking for alternatives. My mate is concentrating on SPI on a different PIN to RX, which will suit, if he gets it working. (December is the 'give in' date)
So that's the 3x altenatives, for us to choose from.
C.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,283
hi C,
We covered this about 7 years ago.;)
In the ISR just read and store the message, set a Flag and then outside the ISR use the csv parser subroutine to pick out the variables
E
Hi E,
Only 7 years ago? How time flies :)

What's ISR? My guess Interrupt, store and read? I'll have to look at that. Actually as with most of the program, I didn't write much of it, thanks to Forums, and helpful people. This section has been working for 'years' with no comments.

The problem is the GPS which is difficult to read via SPI, but we've just received some CODE from another forum, and in another language, that my mate is looking at. Hopefully, he'll get it going, and this will satisfy, many things.
C
 

Ian Rogers

Joined Dec 12, 2012
1,028
Regarless of how it comes in.. You might have trouble either way.... If you have two sentences coming in on two separate serial ports, then you will have to service them both... you will need two interrupts and then you will have to "choose" a priority.

On RS232 there is a CTS function so if the ISR is processing you can halt transmission while the ISR is working.

CTS can be held low or high ( sort of traffic lights ) to do what you need... But you will have to check your GPS / RC to see if they handle hardware handshaking..
 

Thread Starter

camerart

Joined Feb 25, 2013
3,283
Regarless of how it comes in.. You might have trouble either way.... If you have two sentences coming in on two separate serial ports, then you will have to service them both... you will need two interrupts and then you will have to "choose" a priority.

On RS232 there is a CTS function so if the ISR is processing you can halt transmission while the ISR is working.

CTS can be held low or high ( sort of traffic lights ) to do what you need... But you will have to check your GPS / RC to see if they handle hardware handshaking..
Hi I,
Choice 1/ At the moment is a switch between the 2x RX inputs, that sequences them ok.

Choice 2/ Re RS232, If I understand correctly, if SERIN on another PIN is used there is an ON/OFF switch (CTS) so this is possible.

Choice 3/ I think, perhaps what's best, is to help my mate as much as I can, with SPI, which would solve a lot of ideas, so I'll do that until our deadline of December, then that leaves us with only 2x options, which we'll pick off in turn.

Choice 1,2 or 3 will need this: Re RC: The Radio control between BASE and REMOTE can be toggled, but I'll see what happens with SPI first.
C
 

sagor

Joined Mar 10, 2019
786
Do NOT use serin inside an interrupt routine. SERIN is a software loop, internally, and will hold up any and all other interrupt routines (more or less).
You can use an interrupt to detect a change of state on the RX pin assigned to the SERIN port, and then trigger a flag to read with the actual SERIN command outside the interrupt routine. That said, an interrupt routine can take some time in some cases, and may be longer than the start bit of the serial data coming in, depending on serial rate. You have to figure out the timing to determine the best way to read with SERIN. In well planned, proper timing, you may be able to read one character with SERIN in an interrupt routine, but you stand a chance of some lock-up.
SERIN in a main loop can also be interrupted by other interrupts, causing the SERIN to fail to read a proper character if the interrupt routine takes too long and you miss a bit. Only solution is to disable interrupts when reading with SERIN, or disable interrupts that take longer to run.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,283
Do NOT use serin inside an interrupt routine. SERIN is a software loop, internally, and will hold up any and all other interrupt routines (more or less).
You can use an interrupt to detect a change of state on the RX pin assigned to the SERIN port, and then trigger a flag to read with the actual SERIN command outside the interrupt routine. That said, an interrupt routine can take some time in some cases, and may be longer than the start bit of the serial data coming in, depending on serial rate. You have to figure out the timing to determine the best way to read with SERIN. In well planned, proper timing, you may be able to read one character with SERIN in an interrupt routine, but you stand a chance of some lock-up.
SERIN in a main loop can also be interrupted by other interrupts, causing the SERIN to fail to read a proper character if the interrupt routine takes too long and you miss a bit. Only solution is to disable interrupts when reading with SERIN, or disable interrupts that take longer to run.
Hi S,
All a bit complicated! As mentioned, I think it's best that I help my mate with SPI, which will make this unnecessary.
If we fail, then I'll come back to this in December.
Thanks,
C
 
Top