ISRRX Goes Away

Coding and general discussion relating to user created compiler modules

Moderators: David Barker, Jerry Messina

Post Reply
Widgetman
Posts: 136
Joined: Sun Dec 16, 2007 7:39 pm
Location: Florida

ISRRX Goes Away

Post by Widgetman » Thu Mar 24, 2011 12:19 pm

Hi All,
Well I am still working on figuring out ISRRX and how it behaves. I was able to decode packets now, but I am finding that when I jam a few too many packets into the RX buffer it seems to crawl off into a hole even when I stuck in a ISRRX.Initialize command on the overrun flag being set. Has anyone else run into a situation when the ISRRX module goes away ?
Thanks


Main Code:


While true

If ISRRX.Overrun Then
ISRRX.Initialize
End If


While ISRRX.DataAvailable()
RXData(ByteCount) = ISRRX.ReadByte()
ByteCount = ByteCount + 1
If (ByteCount = 14 And RXData(1) = $1F) Then ' Filters Out Only 1F Packets
PacketFlag = true
'ISRRX.Reset ' Reset ISRRX After Packet Comes In
Break // exit 'while' loop if packet received
EndIf
Wend



If SecCount = DelayTime Then
'USART.Write("Hello World",13,10)
If ManualFlag = false Then
Toggle(GREEN_LED)
delayMS(500)
SecCount = 0
End If
End If

If (PacketFlag) then

' Do Something

end if

Wend

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Post by Jerry Messina » Thu Mar 24, 2011 1:21 pm

It looks like there may be a flaw in the buffer index handling.

If you get exactly RX_BUFFER_SIZE number of characters come in without reading any of them, you're left with the situation FIndexIn = FIndexOut and the FMaybeOverrun flag set. In this condition, the buffer is full (but hasn't overflowed yet... the next incoming char would do that), however since FIndexIn = FIndexOut, DataAvailable() will return FALSE even though you have RX_BUFFER_SIZE number of characters in the buffer.

I don't see an easy way of detecting this situation. Perhaps changing the DataAvailable() function to

Code: Select all

public function DataAvailable() as boolean
   disable(OnRX)
   Result = FIndexIn <> FIndexOut
   // check for a full buffer
   if ((Result = false) and FMaybeOverrun) then
       Result = true
   endif
   enable(OnRX)
end function
but I haven't had a chance to review it to see if there are any hazards to doing this.

Widgetman
Posts: 136
Joined: Sun Dec 16, 2007 7:39 pm
Location: Florida

Thanks

Post by Widgetman » Thu Mar 24, 2011 2:01 pm

Hi Jerry,
Thanks for the input. Alias I guess I am off on another quest in the world of Swordfish and Pics. I will let ya know what I find.

Widgetman
Posts: 136
Joined: Sun Dec 16, 2007 7:39 pm
Location: Florida

ISRRX Module

Post by Widgetman » Thu Mar 24, 2011 2:19 pm

Hi,
I took a look at the ISRRX.bas file as suggested. Although I can make the changes Jerry suggested I have to ask the silly question am I allowed too ? It seems hard to believe I am the first to run into this situation with all the Swordfish users out there. Maybe I am overlooking something silly ? I will continue to play with some ideas, and I also will test the change Jerry recommended.
Thanks

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Post by Jerry Messina » Thu Mar 24, 2011 2:30 pm

I don't know if you're running into the situation I described or not, but it would only happen under some very specific circumstances, like you get exactly RX_BUFFER_SIZE number of characters come in without reading anything.

Couple that with the fact that a lot of folks don't even seem to use ISRRX (they just poll the serial port using usart.read() expecting that to work), and that could be the reason.

For a quick test, if you just make the buffer bigger using the #option RX_BUFFER_SIZE, that should change what you see.

Widgetman
Posts: 136
Joined: Sun Dec 16, 2007 7:39 pm
Location: Florida

Tried that already

Post by Widgetman » Thu Mar 24, 2011 2:36 pm

Hi Jerry,
I thought of that and did a overload option of 4x and 8x the packet size. It did not seem to matter I could still splatter it through my interface. I was thinking about doing a ISSRX.Initialize in the dataavailable() routine after I get a bytecount = 12. This way by the time I process the current packet the ISRRX is already reset, but I am not sure that would correct the issue. I think the ISRRX moudle really needs a bufferflush routine, but I am not quite sure how to implement it.
Thanks

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Post by Jerry Messina » Thu Mar 24, 2011 2:50 pm

If that's the case then I doubt what I said is the issue. As soon as the interrupt handler in ISRRX sees one too many characters, it sets the BufferOverrun flag and that should be caught by the ISRRX.Overrun() routine.

If you wanted to flush the buffer, you can enable the commented out ISRRX.Reset you've got already

Code: Select all

While ISRRX.DataAvailable()
    RXData(ByteCount) = ISRRX.ReadByte()
    ByteCount = ByteCount + 1
    If (ByteCount = 14 And RXData(1) = $1F) Then ' Filters Out Only 1F Packets
        PacketFlag = true
        ISRRX.Reset    ' Reset ISRRX After Packet Comes In. <<--- flushes the buffer
        Break // exit 'while' loop if packet received
    EndIf
Wend
but you'll lose any additional messages/partial messages that are already in the buffer. There's really no way of avoiding that if you have async characters coming in... there's never a "safe" time to flush the buffer even if you were to try and do it in the ISR itself.

Widgetman
Posts: 136
Joined: Sun Dec 16, 2007 7:39 pm
Location: Florida

Sounds Like a Plan

Post by Widgetman » Thu Mar 24, 2011 4:33 pm

Hi,
Thanks for the input Jerry. I think I already tried the reset in the packet handler, but I will try again. The other issue may be I am running at 8MHZ in the real box and my development card I used to start learning about this was at 25MHZ. At 4800 baud maybe I am not processing packets fast enough, but I find that hard to believe. I will fiddle around with some changes and see what I get. Overall this has been a good learning experience. Thanks again for all your input.

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Post by Jerry Messina » Thu Mar 24, 2011 5:07 pm

4800 baud is ~2ms/byte, so a 14 byte message takes 28ms to transfer. Even at 8MHz (500ns/instruction), that's a boatload of time before you have to worry about things overrunning/overflowing unless you have added something to the ISRRX OnDataEvent that takes a long time (>2ms) to execute.

As long as you can process a message in 28ms, you shouldn't ever need more than two messages (28 bytes) worth of buffering for ISRRX.

Post Reply