Uwe Bonnes wrote:
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.
Ok, I'll see if it is still necessary.
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....
It's a bit more complicated. When connecting to the device G-Ware reads out all stored values (quite a lot of traffic). Most of the commands to do that are 16 or 96 bytes long and are not terminated by any character (the command length is fixed depending on the command code). It happens quite frequently that commands (mostly the shorter ones) are sent out one after another in one string (ie. 32/192 bytes) with no problem. So the device actually decodes the command and interprets the correct amount of bytes that follow as parameters or whatever and then continues with the next command after sending a reply. What seems to happen under wine is that a command string is put in the transmit buffer and before it is actually sent out completely the buffer is flushed and a new command is sent out resulting in an error because the parameters are wrong (or sometimes 'command too long').
What I don't know is why this happens under wine and I tried a lot to find out... any help would be appreciated.
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...
I would think so as well but maybe something that works differently under windows prevents this loss? Therefore I thought an actual test would clarify.
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"
Sorry, forgot to ask for comments here. Is it possible to do what I suggest? Does it sound right at all?
Thanks a lot, Cihan