"Cihan" == Cihan Altinay cihan@uq.edu.au 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