ISRRX Goes Away
Moderators: David Barker, Jerry Messina
ISRRX Goes Away
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
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
-
- Swordfish Developer
- Posts: 1469
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
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
but I haven't had a chance to review it to see if there are any hazards to doing this.
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
ISRRX Module
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
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
-
- Swordfish Developer
- Posts: 1469
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
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.
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.
Tried that already
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
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
-
- Swordfish Developer
- Posts: 1469
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
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
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.
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
Sounds Like a Plan
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.
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.
-
- Swordfish Developer
- Posts: 1469
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
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.
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.