Hi Florian,
For "I/O Intr" records, StreamDevice uses intrCallbackOctet but still needs to
poll the device, because despite its name, intrCallbackOctet does not deliver
any data asynchronously when nobody reads synchronously. The "I/O Intr" records
receives ALL input, regardless of the active reader, which may be the record
itself, some other StreamDevice Record or even non-StreamDevice records or any
other software calling asynOctet->read on that port.
Thus, to avoid receiving the data twice, in case the intrCallbackOctet receiver
is the polling record, StreamDevice discards the input received with the polled
read and only uses the input received with intrCallbackOctet.
As ALL "I/O Intr" StreamDevice records receive ALL input, they all match the
input against their 'in' commands. Only those records which could match the
input successfully are processed. All others silently ignore the input!
The intrCallbackOctet input log messages should show up in the logs BEFORE the
message form the polled read (because asyn calls the interrupt callbacks before
returning from read). What do you have in the logs right before the first line
you posted? Anything from AsynDriverInterface::asynReadHandler() and
StreamCore::readCallback()?
As StreamDevice did not receive a termination signal, it assumes there may be
more input and tries to read it. But that results in a timeout, which is then
interpreted as a termination signal, because no InTerminator is used.
This is probably not what you want. If the message never exceeds one CAN frame,
set eomReason to ASYN_EOM_END. This avoids wasting time on another read attempt.
If you may have messages that span multiple frames and have a method to find out
when this is the case in your driver, do that. Otherwise waiting for timeout (or
InTerminator or maxInput) is in fact the only way.
Now the question is why the input is rejected. Hard to say without knowing your
protocol. What do you have in your 'in' command?
Dirk
On Tue, 2023-07-04 at 09:05 +0200, Florian Feldbauer via Tech-talk wrote:
> Hey all,
>
> we have some devices controlled via CAN bus.
> Since CAN bus is based on the transmission of 1-8 bytes, I wrote an
> AsynPortDriver with an asynOctet interface as lower level driver.
>
> I wanted to use StreamDevice as higher level driver defining the actual
> payload data that is tranmitted between our PC and the devices.
>
> Sending and receiving messages in principal works, but I have an issue
> with I/O Interrupts and I don't know why.
> Setting the streamDebug variable to 1, I see the following output from
> StreamDevice:
>
> 2023/07/04 08:54:44.301618 can1 AsynDriverInterface.cc:951:
> AsynDriverInterface::readHandler(CAN1:TEST:R): ioAction=AsyncRead
> read(63 bytes, timeout=0 sec) returned status asynSuccess: received=4
> bytes, eomReason=NONE, buffer="<07><00><00><ea>"
> 2023/07/04 08:54:44.301765 can1 AsynDriverInterface.cc:977:
> AsynDriverInterface::readHandler(CAN1:TEST:R): AsyncRead poll: received
> 4 of 63 bytes "<07><00><00><ea>" eomReason=NONE [data ignored]
> 2023/07/04 08:54:44.301889 can1 AsynDriverInterface.cc:1123:
> AsynDriverInterface::readHandler(CAN1:TEST:R) readMore=-1 bytesToRead=63
> 2023/07/04 08:54:44.302015 can1 AsynDriverInterface.cc:951:
> AsynDriverInterface::readHandler(CAN1:TEST:R): ioAction=AsyncRead
> read(63 bytes, timeout=0.5 sec) returned status asynTimeout: received=0
> bytes, eomReason=NONE, buffer=""
> 2023/07/04 08:54:44.302140 can1 AsynDriverInterface.cc:1051:
> AsynDriverInterface::readHandler(CAN1:TEST:R): ioAction=AsyncRead,
> timeout [0.5 sec] after 0 of 63 bytes ""
> 2023/07/04 08:54:44.302262 can1 StreamCore.cc:963:
> StreamCore::readCallback(CAN1:TEST:R, StreamIoTimeout input="", size=0)
> 2023/07/04 08:54:44.302378 can1 StreamCore.cc:1015:
> StreamCore::readCallback(CAN1:TEST:R) inputBuffer="", size 0
> 2023/07/04 08:54:44.302490 can1 StreamCore.cc:1067:
> StreamCore::readCallback(CAN1:TEST:R) end flag received
> 2023/07/04 08:54:44.302605 can1 StreamCore.cc:1127:
> StreamCore::readCallback(CAN1:TEST:R) input line: ""
> 2023/07/04 08:54:44.302726 can1 StreamCore.cc:1151:
> StreamCore::readCallback(CAN1:TEST:R) async match failure: just restart
> 2023/07/04 08:54:44.302847 can1 AsynDriverInterface.cc:806:
> AsynDriverInterface::readRequest(CAN1:TEST:R, 500 msec reply, 500 msec
> read, expect 0 bytes, async=yes)
> 2023/07/04 08:54:44.302964 can1 AsynDriverInterface.cc:831:
> AsynDriverInterface::readRequest CAN1:TEST:R: queueRequest(...,
> priority=0, queueTimeout=-1 sec) = asynSuccess [async=true]
>
> The readHandler reads the message from the bus but ignores it. According
> to the comments in the code it is ignored because the asyncReadHandler
> should also receive this message and handle the I/O interrupt, but it
> seems the Interrupt callback is not executed.
> Any idea why the callbacks don't work?
>
> I'm using
> base 7.0.6.1
> stream 2.8.24
> asyn (current HEAD on master branch)
>
> Cheers,
> Florian
>
>
- Replies:
- Re: Issue with streamdevice and I/o Intr Florian Feldbauer via Tech-talk
- References:
- Issue with streamdevice and I/o Intr Florian Feldbauer via Tech-talk
- Navigate by Date:
- Prev:
Issue with streamdevice and I/o Intr Florian Feldbauer via Tech-talk
- Next:
Re: Issue with streamdevice and I/o Intr Florian Feldbauer via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
<2023>
2024
- Navigate by Thread:
- Prev:
Issue with streamdevice and I/o Intr Florian Feldbauer via Tech-talk
- Next:
Re: Issue with streamdevice and I/o Intr Florian Feldbauer via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
<2023>
2024
|