Re: Problem with serial port

[Félix Ortega]

Quoting Uwe Bonnes :
> > > > > > "Félix" == Félix Ortega  writes:
>
> Félix> Sorry, with my desesperation I forgot to tell you the version of
>    Félix> wine I'm running is the 0.9.2 version. I have tried 0.9.0 and
>    Félix> 0.9.1, with the same result. The strange thing is the driver does
>    Félix> not use the WaitCommEvent call, tha I think is work in progress
>    Félix> now.
>
> No, most WaitCommEvent functionality is there. Maybe heavy use of threads
> and some special case still cause trouble.

Ok, I think the problem with the other driver is essentially the same, but the
second driver uses WaitCommEvent (with events) and the first driver uses
timeouts (polling). But the problem I think is the data never gets written to
the port (something related to flow control?)
> Félix> I have another driver for a similar printer that does use
>    Félix> this call, and doesn't work neither. I'm studying the windows
>    Félix> source code of this second driver (I have access to it) to make a
>    Félix> linux program that at least initialize the printer. I will keep
>    Félix> you informed on this second project.
>
> Look at the test directories and try to create tests mimicing your error.

I will try to do that, I haven't looked the test dir too much.
> Félix> For the olivetti printer, I
>    Félix> don't know what is the problem, and I don't know where to look
>    Félix> for :(.
>
> Perpaps some serial spy would be of help. Capture the communication of the
> windows program with the device, do the same under wine and compare.

I have done that, with portmon on the windows side and with some patches that
you (I think) sent to the list, so the write and read operations log the
contents. The data is the same, and the sequence also, but on wine the data
never gets to the printer, It stalls on the buffer and after a timeout the
program clears the output buffer and starts again.
At first I thought that the problem was related with the asynchronous I/O
(somehow the timeout fires before the data gets written), so I disabled the
asynchronous write for ports, as said on a thread I found on google. The diff
was something like changing the line
    if (flags & (FD_FLAG_OVERLAPPED|FD_FLAG_TIMEOUT))
with
    if (flags & (FD_FLAG_OVERLAPPED))
at function NtWriteFile on ntdll/file.c file, so the write never gets its own
thread unles specified. But the problem remains the same, but the 
timeout never
get's fired and the program hangs trying to write on the serial port.

I'm starting to thing that there is a problem with the way the serial port is
initialized, but I don't have any proof of that.

Thanks!
> However I don't have a suggestion for a serial caputure program for you :-(
>
> Uwe Bonnes                [e-mail]
>
> Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
> --------- Tel. [phone] -------- Fax. [phone] ----------

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.