>>>>> "Cihan" == Cihan Altinay <[EMAIL PROTECTED]> writes:
Cihan> Uwe Bonnes wrote: >> If you need input into the serial port, consider using some kind of >> loopback. Either use the plug with the appropriate pins shorted , or >> use two serial lines with a crossover cable. >> >> Where do you live. I could consider sending you the plug.. Cihan> I am currently in Australia so I guess it wouldn't be possible Cihan> although it would help a lot. It's only a RS232 9 pin connector with 3 solder blobs. If you have a solder iron, easily done yourself. Cihan> I found in the documentation that the PARMRK flag duplicates 0xff Cihan> in the stream to avoid confusion with the actual error Cihan> character. I verified that by inspecting the stream with/without Cihan> flag set. Can we simply clear the PARMRK flag in wine or is Cihan> there something similar under windows? >> Clear all those offending flags and write a comment that somebody >> looking in the code can understand. Cihan> Can I just do that around line 1106 where c_iflag is initialized? Cihan> I will send a patch out shortly. Looks reasonable Cihan> I am still trying to figure out what the problem might be when Cihan> using purge to clear the output buffer. When G-Ware writes Cihan> subsequently to the port it looks like this: Cihan> 1) Purge (input/output) Cihan> 2) Write Cihan> 3) SetWaitMask (RXCHAR|RXFLAG|CTS|DSR|RLSD|BRK|ERR) Cihan> 4) WaitCommEvent Cihan> (4a) Read input if there's something) Cihan> Goto 1) Cihan> As you can see there is no TXEMPTY flag so G-Ware seems to rely Cihan> on the buffers to be emptied beforehand and then just calls Purge Cihan> before writing again. Just to make sure I wrote a short program Cihan> that does the following: Cihan> 1) Write command Cihan> 2) Purge Cihan> 3) Write Cihan> another command (Without any delay). Obviously some bytes from Cihan> the first command are flushed away and thus the device indeed Cihan> returns the same error value I get under G-Ware. Here you forgot the behaviour of the actual device. It probably only reacts when a complete command is written and terminated in some way, perhaps a CR or something like that. If G-Ware send this "magic" byte as the last command, no need fot tcdrain or such.... Cihan> I can prevent it Cihan> by using tcdrain() or insert a sleep with a large enough value. Cihan> I also tried to _see_ it by using a tty instead of the serial Cihan> port but interestingly that does work, ie. no bytes are lost. Cihan> Uwe, could you try and see what happens when you use the loopback Cihan> and do a Write-Purge-Write sequence under both, wine and windows? I am sure that bytes will get lost without any kind of line dicipline... Cihan> One more thing regarding the page fault in the EventService: We Cihan> obviously have to set the buffer to 0 when the event mask changes Cihan> because that's what the API spec says. But maybe we have to Cihan> monitor which threads exist and wake them up when SetCommMask is Cihan> called so that they finish their work before SetCommMask returns. Cihan> MSDN says: "...WaitCommEvent returns immediately" Bye -- Uwe Bonnes [EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------