POSIX EventDriven details

[GoogleCodeExporter]

Hey all.

Is the event driven serial port i/f for qextserialport using interrupts to 
work? If not, how can you tell data has been received without polling?

I have a controller I'm trying to talk to and I seem to get multiple 
signals back for what I thought would qualify as one response from the 
device.

For instance a response looks like "0001 ABCD", but my function, which is 
connected to the serial port object's 'readyRead()' signal runs multiple 
times, indicating that readyRead() was emitted more than once. All my 
function does is print out what the response is and then prints out a new 
line.

So if my expected device response is "0001 ABCD", I get anything from
------------
0001 A\n
BCD
------------
------------
0001 ABC\n
D
------------
------------
0001 AB\n
CD
------------

... and so on, with every 'new line \n' being an instance where the 
function was called again. Is the device response just not continuous? I'd 
like to understand how EventDriven communication is implemented in 
QextSerialPort so I can understand exactly what is happening.

-Preet

Original issue reported on code.google.com by preet.de...@gmail.com on 27 Nov 2009 at 7:31

[GoogleCodeExporter]

This doesn't have anything to do with event driven reads.  Serial connections 
are stream based, meaning your 
data is not guaranteed to arrive in a complete packet - it has no way of 
knowing what a complete packet for 
your app might look like, so your app needs to be prepared to accept data piece 
by piece.  The same 
could/should happen with poll based reading.

Original comment by lst...@gmail.com on 29 Nov 2009 at 7:11

• Changed state: Done

[GoogleCodeExporter]

Hi lstask,

Thanks for the response. Is the EventDriven mode based on interrupts? If not 
how does
it work (as opposed to polling which continually checks the device).

-Preet

Original comment by preet.de...@gmail.com on 30 Nov 2009 at 7:24

[GoogleCodeExporter]

You can take a look at the source code :)  It uses a couple Qt classes that 
provide events from the OS 
corresponding to activity on a file descriptor (unix) or events on a handle 
(win).

Original comment by lst...@gmail.com on 30 Nov 2009 at 8:45

[GoogleCodeExporter]

Hey lstask, one more quick question for you. When I send a command to a device 
over 
the serial port, and receive multiple signals that indicate a device response, 
I'm 
running into trouble with software preemption. Is there an easy way to go 
'atomic' 
temporarily with regards to receiving these events (they occur fast enough that 
they 
preempt any attempt to disconnect the slot from the signal)? Even if my program 
would 
piece the device response together piece by piece, my event handler never 
reaches 
completion before it gets preempted. 

I was thinking of trying to modify QextSerialPort to only send one readyRead() 
event 
and then wait until an acknowledge from my application before it could send 
more. 
This also seems like it might be a significant undertaking and I'm 
overcomplicating...

Original comment by preet.de...@gmail.com on 4 Dec 2009 at 9:47

[GoogleCodeExporter]

I wouldn't modify the source for this.

If you're in a single threaded app, you should be able to set a flag at the 
point that you know you want to stop 
listening for signals, and then the next time your handler gets triggered, take 
that into account.  I think this is a 
more general Qt issue - you might want to post to the Qt-interest mailing list.

Original comment by lst...@gmail.com on 5 Dec 2009 at 6:31

[GoogleCodeExporter]

Unfortunately I'm using a multithreaded application. Is there any way to use 
waitForReadyRead() with QextSerial? That seems like it would solve this problem.

Original comment by preet.de...@gmail.com on 7 Dec 2009 at 5:24