Problem with serial port

[Félix Ortega]

I'm trying to make work a driver for a financial printer (Olivetti Pr20) on
wine. I'm having problems with the serial port, it seems that no data is
written to the device. I have tried everything I have thinked, searched on the
list, searched on google, but the printer does not work.
I think there is a problem somewhere between wine and the serial port driver,
since the program try to write data and it seems the data is cleared from the
buffer by the function ClearCommError before it is sent to the printer. After
that, the program tries to read data but the data (response from the printer)
never come.
Perhaps I'm missinterpreting the output? I have tried to solder the DSR/DTR pins
with the CTS/RTS pins, just in case is a problem of DSR/DTR flow, but it does
exactly the same.

I attach the output from the program with DEBUGFLAGS=+comm,file, and the output
from portmon in a windows machine with the same program. I have cleaned a
little the wine log, so only the i/o and comm functions from the port are
shown.

I don't know where the error can be, can you help me?

Thanks in advance.

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

[Cihan Altinay]

Quoting Félix Ortega :
> I'm trying to make work a driver for a financial printer (Olivetti Pr20) on
> wine. I'm having problems with the serial port, it seems that no data is
> written to the device. I have tried everything I have thinked, searched on

Please try the attached patch with the latest cvs. It is a workaround for
a symptom where data is flushed away in wine but not in Windows. It would
be interesting to know if that works for you as well.

Cheers,
Cihan

[Félix Ortega]

Quoting Cihan Altinay :
> Quoting Félix Ortega :
> > I'm trying to make work a driver for a financial printer (Olivetti Pr20) on
> > wine. I'm having problems with the serial port, it seems that no data is
> > written to the device. I have tried everything I have thinked, searched on
>
> Please try the attached patch with the latest cvs. It is a workaround for
> a symptom where data is flushed away in wine but not in Windows. It would
> be interesting to know if that works for you as well.
>
> Cheers,
> Cihan

It does not work :( The test program freezes trying to flush the serial 
port (at
function PurgeComm). Just before that the trace says  that the cbOutQue has 6
elements (at function ClearCommError). I think the program writes on 
the serial
port, but for any reason the writing operation doesn't succeed and the writing
operation stalls trying to do the tcdrain part. The program does not 
stops with
tcflush because tcflush discards the buffers.
Perhaps is something related to the line discipline of the port, somehow the
port doesn't accept input.

I keep investigating, many thanks!

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

[Uwe Bonnes]

> > > > > "Félix" == Félix Ortega  writes:

Félix> Quoting Cihan Altinay :
    >> Quoting Félix Ortega :
    >> 
    >>> I'm trying to make work a driver for a financial printer (Olivetti
    >>> Pr20) on wine. I'm having problems with the serial port, it seems
    >>> that no data is written to the device. I have tried everything I
    >>> have thinked, searched on
    >>  Please try the attached patch with the latest cvs. It is a
    >> workaround for a symptom where data is flushed away in wine but not
    >> in Windows. It would be interesting to know if that works for you as
    >> well.
    >> 
Félix, just to make things sure, are you running a recent wine?

[Félix Ortega]

Sorry, with my desesperation I forgot to tell you the version of wine I'm
running is the 0.9.2 version. I have tried 0.9.0 and 0.9.1, with the same
result. The strange thing is the driver does not use the WaitCommEvent call,
tha I think is work in progress now.
I have another driver for a similar printer that does use this call, 
and doesn't
work neither. I'm studying the windows source code of this second 
driver (I have
access to it) to make a linux program that at least initialize the printer. I
will keep you informed on this second project. For the olivetti printer, I
don't know what is the problem, and I don't know where to look for :(.

Thanks to all.
Quoting Uwe Bonnes :
> > > > > > "Félix" == Félix Ortega  writes:
>
> Félix> Quoting Cihan Altinay :
> > > Quoting Félix Ortega :
> > > > I'm trying to make work a driver for a financial printer (Olivetti
> > > > Pr20) on wine. I'm having problems with the serial port, it seems
> > > > that no data is written to the device. I have tried everything I
> > > > have thinked, searched on
> > >
> > > Please try the attached patch with the latest cvs. It is a
> > > workaround for a symptom where data is flushed away in wine but not
> > > in Windows. It would be interesting to know if that works for you as
> > > well.
> Félix, just to make things sure, are you running a recent wine?
>
> 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.

[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.

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.

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.

However I don't have a suggestion for a serial caputure program for you :-(

[Cihan Altinay]

Uwe Bonnes wrote:
> 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.
>
> However I don't have a suggestion for a serial caputure program for you :-(

How about the freeware Portmon from sysinternals:
http://www.sysinternals.com/Utilities/Portmon.html

It helped me a lot...

Cheers,
Cihan

[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.

[Uwe Bonnes]

> > > > > "Félix" == Félix Ortega  writes:

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

Didn't Cihan already found some mismatches in initialization. Perhaps there
is more mismatch lingering around.

Bye