More serial access issues

[Geoffrey Hausheer]

Well, after tracing the events through wineserver, I see
'serial_queue_event' gets called, serial_get_poll_events returns
'POLLOUT', async_notify gets called (but async->thread->wait is 0, so it
doesn't do anything besides setting the status to STATUS_ALERTED.  The
secod serial_get_poll_events returns 0 (due to the status no longer
being STATUS_PENDING), but this doesn't really matter as the
'register_async' call doesn't create a reply.

Back in my application, __register_async does not reset u.Status (since
'ret' is 0), which means that 'finish_async' never gets called, which
appears to be the only way that FILE_AsyncWriteService can be called
(which actually does the write) ,and no data is written to the serial
port.

It all seems to operate as the code dictates, so I'm not sure what the
right fix is.  It would seem to me that something is not working right
in __register_async.  Perhaps finish_async should not be gated by
'u.Status'?  Or u.Status should unconditionally be set equal to 'ret'?

The second seems more likely to me, as that is the only way the
WriteFile could return TRUE (in fact I see no way that WriteFile could
return true in today's code, regardless of what the server does (since
u.Status can only be changed from STATUS_PENDING if ret != 0 (and
STATUS_SUCCESS == 0), so u.Status can never equal STATUS_SUCCESS.

I am having a lot of difficulty understanding exactly what the server
call is doing (I think it is checking that it is clear to write to the
Serial port, though it seems to be awfully complex if that is all).
Also, I don't know what the conditions are under which finish_async
should be called.

I changed the code to unconditionally set u.Status = ret, and WriteFile
is no longer returning an error, but this didn't help (I'm never seeing
FILE_AsyncWriteService get called, because call completion is disabled).

So it looks like there are several points that are preventing
FILE_AsyncWriteService from being called, and maybe I'm barking up the
wrong tree.  I can see a few possibilities: (1) some other routine is
supposed to do the write, and I'm missing it, or (2) the server is
supposed to do the write (perhaps via asyncy_notify?), in which case I
don't see any place where the write buffer is passed to the server, or
(c) the server is supposed to tell the client to do the write (again by
async_notify?), in which case, I'm not seeing how that works.

This code seems to run around in circles to me.

.Geoff

-----Original Message-----
From: Geoffrey Hausheer
Sent: Wednesday, April 14, 2004 2:05 PM
Subject: More serial access issues


Well, I broke down and pulled out the oscope and rs232 breakout box to
try to figure out why my app isn't able to communicate with the device.

turns out that Rein's patch is correctly deasserting DSR, however, I am
not getting any data over the Tx pin.  And after I checked the output of
WriteFile, it is failing.

GetLastError doesn't return anything useful (a value of 997 which
FormatMessage() can't do anything with).  But some debugging led me to
determine that NtWriteFile is returning 0x103 which is STATUS_PENDING.

After that I'm somewhat lost as to what is going on.  Obvioulsy,
'register_new_async' is returning this status, which apparently happens
when wine_server_call returns 0 or STATUS_PENDING (not sure if the
second
is even possible).  But about here I am getting completely confused as
to
what we are trying to accomplish.

The file is opened via:
CreateFile("COM1", 0, NULL, OPEN_EXISTING, 0, NULL)
so we're not in overlapped mode.  SetCommTimeout is called with the
COMMTIMEOUTS structure containing all 0s.  All flow control is disabled
using SetCommState.  Before a write, we always call 'PurgeComm' and
ClearCommError.

In Windows, this combination results in a write always occurring when
WriteFile is called, regardless of whether there is anything connected
to
the serial port.  Wine appears to be waiting for something, and I'm not
sure what.

If anyone has any ideas how I might proceed, i'd be glad to hear them.

Thanks,
.Geoff