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
