Hi! From time to time, complaints can be heard about functionality of the serial port implementation in wine. Just now I have one of examples of the serial communication problem. There is a very simple program, called ft or softjump, intended to dump or modify some particular addresses of an EEPROM of an amateur radio. It uses a serial port in non-canonical mode, writing always 5 binary chars into it and reading (also binary) reply. I've run this program under wine but there were problems - the program never dumped any data. The source is included in the program archive; it was about 30 minutes of work to convert it for Linux. After successfull compilation, I've run the resulting Linux program (pure Linux, not winelib) and it worked as expected. For the testing purposes, I've then compiled the original windows version using winegcc. I was able to run the program, but the results were identical to those with original windows binary (no data).
The windows binary output shows this:
patrol@arcus:~/ft817$ wine ft.exe ft.exe by Peter May, VK2JCG, vk2jcg@yahoo.com.au
This program uses undocumented CAT commands to read or update the EEPROM in the Yaesu FT817 and FT897 Radios. The soft jumper settings are stored in location 4 and 5 of the EEPROM. Power the radio off and on to activate the new settings. If you do a reset of the radio, you will have to run this program again to rewrite the values
The program assumes that the radio is connected to COM1: and the CAT rate is set to 38400 baud
*** USE AT YOUR OWN RISK ***
Serial port COM1: successfully reconfigured.
Read current data from EEPROM gives : patrol@arcus:~/ft817$
Its Linux version works well:
patrol@arcus:~/ft817/Source$ ft ft by Peter May, VK2JCG, vk2jcg@yahoo.com.au
This program uses undocumented CAT commands to read or update the EEPROM in the Yaesu FT817 and FT897 Radios. The soft jumper settings are stored in location 4 and 5 of the EEPROM. Power the radio off and on to activate the new settings. If you do a reset of the radio, you will have to run this program again to rewrite the values.
*** USE AT YOUR OWN RISK ***
Linux version by Pavel Troller - OK1XPT, patrol@sinus.cz Serial port /dev/tts/0 successfully reconfigured.
Read current data from EEPROM gives : DD BF patrol@arcus:~/ft817/Source$
Do you see ? The windows version doesn't output the actual EEPROM data.
+file,+comm trace from wine looks like this:
trace:file:CreateFileW L"COM1:" GENERIC_READ GENERIC_WRITE creation 3 attributes 0x0 trace:file:RtlDosPathNameToNtPathName_U (L"COM1:",0x7fb3fdd0,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"COM1:" 520 0x7fb3fb44 (nil)) trace:file:get_dos_device L"COM1" -> "/dev/ttyS0" trace:file:CreateFileW returning 0x2c trace:comm:GetCommState handle 0x2c, ptr 0x7fb3fe70 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_GET_BAUD_RATE (nil) 0 0x7fb3fe18 4 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_GET_LINE_CONTROL (nil) 0 0x7fb3fe1d 3 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_GET_HANDFLOW (nil) 0 0x7fb3fe00 16 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_GET_CHARS (nil) 0 0x7fb3fe12 6 0x7fb3fdb0 trace:comm:GetCommState OK trace:comm:dump_dcb bytesize=8 baudrate=38400 fParity=0 Parity=0 stopbits=2 trace:comm:dump_dcb ~IXON ~IXOFF trace:comm:dump_dcb fOutxCtsFlow=0 fRtsControl=0 trace:comm:dump_dcb fOutxDsrFlow=0 fDtrControl=1 trace:comm:dump_dcb ~CRTSCTS trace:comm:dump_dcb bytesize=8 baudrate=38400 fParity=0 Parity=0 stopbits=2 trace:comm:dump_dcb ~IXON ~IXOFF trace:comm:dump_dcb fOutxCtsFlow=0 fRtsControl=0 trace:comm:dump_dcb fOutxDsrFlow=0 fDtrControl=0 trace:comm:dump_dcb ~CRTSCTS trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_SET_BAUD_RATE 0x7fb3fe18 4 (nil) 0 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_SET_LINE_CONTROL 0x7fb3fe1d 3 (nil) 0 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_SET_HANDFLOW 0x7fb3fe00 16 (nil) 0 0x7fb3fdb0 trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_SET_CHARS 0x7fb3fe12 6 (nil) 0 0x7fb3fdb0 trace:comm:SetCommTimeouts (0x2c, 0x7fb3fe5c) trace:comm:COMM_DeviceIoControl 0x2c IOCTL_SERIAL_SET_TIMEOUTS 0x7fb3fe0c 20 (nil) 0 0x7fb3fdb0 trace:file:WriteFile 0x8 0x7fb3f9cc 48 0x7fb3fdd4 (nil) Serial port COM1: successfully reconfigured.
trace:file:WriteFile 0x2c 0x7fb3fe54 5 0x7fb3fe4c (nil) trace:file:ReadFile 0x2c 0x7fb3fe8c 4 0x7fb3fe4c (nil) trace:file:WriteFile 0x8 0x7fb3f9b4 38 0x7fb3fdbc (nil) Read current data from EEPROM gives : trace:file:WriteFile 0x8 0x7fb3f9b8 2 0x7fb3fdc0 (nil)
You can see the port configuration phase, as well 5 bytes being written and a read being attempted. However, resulting "count" variable (see source) is probably 0, because there is no output of values read. I don't know, whether it is due to wrong command being written to the radio, or failure to read its response.
Original package can be downloaded freely for example here: http://www.817-onair.de/download.php?id=6&sid=c66545090cd6b5cbc2e1c06321...
My Linux variant is attached to this mail. Sorry for the lengthy mail, but I hope that it can really help to improve the serial communication support in wine. With regards, Pavel Troller
"Pavel" == Pavel Troller patrol@sinus.cz writes:
Pavel> Hi! From time to time, complaints can be heard about Pavel> functionality of the serial port implementation in wine. Just now Pavel> I have one of examples of the serial communication problem. Pavel> There is a very simple program, called ft or softjump, intended ... Pavel> My Linux variant is attached to this mail. Sorry for the lengthy Pavel> mail, but I hope that it can really help to improve the serial Pavel> communication support in wine. With regards, Pavel Troller
Pavel,
do you have a scope? Can you look what physically happens on the serial line? Does the program via wine actually write out the challange? Does the the device react to the challange? Whats the delay between challange and response?
I suspect something with our wait implementation to go wrong. The program immediate does a read after the write, and doesn't repeat the read if 0 characters are read. So if the device reacts slow, the read will be to early.
Can you try to put a Sleep() between the Readfile() and the Writefile() in the windows program?
Bye