Comport Serial Port Card (8 Ports)

Maurizio · Post by **Maurizio** » Thu Jun 19, 2008 12:55 pm

It is some time that I using AirMail3 with wine.
I have the latest version of Wine but after I configure the Ports from
ttyR0 to ttyR7 and running AirMail3 this application is not able to
comunicate using the equivalent COM1 .... COM4 ports.

I'm not sure if Wine is converting correctly ttyR0 to COM1 and so forth.

The result is that for the Hurricane season I can NOT use E-Mail under
Emergency situations.

Any Ideas and Help ?

Thanks

Mario N0ABZ

LJB · Post by **LJB** » Thu Jun 19, 2008 3:24 pm

I have also been trying to get serial ports working on my system. To start with, create symlinks in your .wine/dosdevices directory that point to your serial ports. If you don't do this, wine will default to com1 -> /dev/ttyS0

in your case,
cd ~/.wine/dosdevices
ln -s /dev/ttyR0 com1
ln -s /dev/ttyR1 com2
etc....

Then you must ensure your linux user has permission to access the serial ports. On my system (Ubuntu 8.04 ) I added my user to the 'dialup' group.

Unfortunately, I can send data out the serial port, but not receive it properly.

Maurizio · Post by **Maurizio** » Thu Jun 19, 2008 5:46 pm

LJB wrote:

I have also been trying to get serial ports working on my system. To start with, create symlinks in your .wine/dosdevices directory that point to your serial ports. If you don't do this, wine will default to com1 -> /dev/ttyS0

in your case,
cd ~/.wine/dosdevices
ln -s /dev/ttyR0 com1
ln -s /dev/ttyR1 com2
etc....

Then you must ensure your linux user has permission to access the serial ports. On my system (Ubuntu I added my user to the 'dialup' group.

Unfortunately, I can send data out the serial port, but not receive it properly.

Thanks, this solve my problem. Why you can send data out ?
I can using the ports !

Mario

LJB · Post by **LJB** » Sun Jun 22, 2008 12:57 pm

Maurizio wrote:Thanks, this solve my problem. Why you can send data out ?
I can using the ports !

Mario

I don't know what my problem is. I can send data out the serial port, but data sent to the serial port is delayed by around 10 seconds, which makes my application unusable.

I've been adding trace statements to the source code to get an idea of what's going on, but haven't gotten very far yet.

Uwe Bonnes · Post by **Uwe Bonnes** » Mon Jun 23, 2008 5:12 am

LJB> Maurizio wrote:

Thanks, this solve my problem. Why you can send data out ? I can
using the ports !

Mario

LJB> I don't know what my problem is. I can send data out the serial
LJB> port, but data sent to the serial port is delayed by around 10
LJB> seconds, which makes my application unusable.

LJB> I've been adding trace statements to the source code to get an idea
LJB> of what's going on, but haven't gotten very far yet.

Probably the programm requests some notification that isn't
delivered. Either because Wine doesn't provide that notification or because
the card or the driver for that card doesn't provide the notification. Did
you try on a another serial port, like the chipset built in port?

--
Uwe Bonnes [email protected]

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

LJB · Post by **LJB** » Mon Jun 23, 2008 2:50 pm

Uwe Bonnes wrote: Probably the programm requests some notification that isn't
delivered. Either because Wine doesn't provide that notification or because
the card or the driver for that card doesn't provide the notification. Did
you try on a another serial port, like the chipset built in port?

--
Uwe Bonnes [email protected]

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Let me state my problem clearly.

I am trying to get the Garmin Mapsource program to communicate with my GPS over a serial port. Mapsource autodetects the GPS but will not transfer data to or from it.

For debugging purposes, I have connected a null modem cable from my Motherboard serial port (Intel 865G chipset) to a USB/serial adapter. I can communicate perfectly between two minicom terminal programs, but when trying to communicate between minicom and teraterm under wine I have trouble. Characters typed in the teraterm window appear in the minicom window immediately, but characters typed in the minicom either take 10 seconds or so to appear in the teraterm window, or do not appear at all. The symptoms are identical regardless of hardware handshaking settings or whether the teraterm/wine program uses the MB or USB serial port.

Starting teraterm, typing some characters into minicom, and quitting teraterm produces the following trace:

Code: Select all

fixme:font:WineEngCreateFontInstance Untranslated charset 255
fixme:imm:ImmReleaseContext (0x700a2, 0x12ca18): stub
trace:comm:io_control 0x74 IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x32ec84 20 0x32ec2c
trace:comm:io_control 0x74 IOCTL_SERIAL_SET_QUEUE_SIZE 0x32ec98 8 (nil) 0 0x32ec4c
fixme:comm:set_queue_size insize 8192 outsize 2048 unimplemented stub
trace:comm:io_control 0x74 IOCTL_SERIAL_PURGE 0x32ecb4 4 (nil) 0 0x32ec60
trace:comm:SetCommTimeouts (0x74, 0x32ecc4)
trace:comm:io_control 0x74 IOCTL_SERIAL_SET_TIMEOUTS 0x32ec8c 20 (nil) 0 0x32ec40
trace:comm:dump_dcb bytesize=8 baudrate=9600 fParity=0 Parity=0 stopbits=1
trace:comm:dump_dcb ~IXON ~IXOFF
trace:comm:dump_dcb fOutxCtsFlow=0 fRtsControl=1
trace:comm:dump_dcb fOutxDsrFlow=0 fDtrControl=1
trace:comm:dump_dcb ~CRTSCTS
trace:comm:io_control 0x74 IOCTL_SERIAL_SET_BAUD_RATE 0x32ec98 4 (nil) 0 0x32ec40
trace:comm:io_control 0x74 IOCTL_SERIAL_SET_LINE_CONTROL 0x32ec9d 3 (nil) 0 0x32ec40
trace:comm:io_control 0x74 IOCTL_SERIAL_SET_HANDFLOW 0x32ec80 16 (nil) 0 0x32ec40
trace:comm:io_control 0x74 IOCTL_SERIAL_SET_CHARS 0x32ec92 6 (nil) 0 0x32ec40
trace:comm:SetCommMask handle 0x74, mask 0
trace:comm:io_control 0x74 IOCTL_SERIAL_SET_WAIT_MASK 0x32ecb4 4 (nil) 0 0x32ec60
trace:comm:SetCommMask handle 0x74, mask 1
trace:comm:io_control 0x74 IOCTL_SERIAL_SET_WAIT_MASK 0x32ecb4 4 (nil) 0 0x32ec60
trace:comm:io_control 0x74 IOCTL_SERIAL_WAIT_ON_MASK (nil) 0 0x7e0569e4 4 0x7e056974
trace:comm:get_modem_status 4126 -> MS_DSR_ON  MS_CTS_ON  
trace:comm:check_events mask 0x00000001
trace:comm:check_events old->rx          0x0000132d vs. new->rx          0x0000132d
trace:comm:check_events old->tx          0x000001ec vs. new->tx          0x000001ec
trace:comm:check_events old->frame       0x00000012 vs. new->frame       0x00000012
trace:comm:check_events old->overrun     0x00000000 vs. new->overrun     0x00000000
trace:comm:check_events old->parity      0x00000000 vs. new->parity      0x00000000
trace:comm:check_events old->brk         0x00000000 vs. new->brk         0x00000000
trace:comm:check_events old->buf_overrun 0x00000000 vs. new->buf_overrun 0x00000000
trace:comm:wait_for_event device=0x74 fd=0x00000013 mask=0x00000001 buffer=0x7e0569e4 event=0x88 irq_info=0x12e904

trace:comm:get_modem_status 4126 -> MS_DSR_ON  MS_CTS_ON  
trace:comm:check_events mask 0x00000001
trace:comm:check_events old->rx          0x0000132d vs. new->rx          0x0000132d
trace:comm:check_events old->tx          0x000001ec vs. new->tx          0x000001ec
trace:comm:check_events old->frame       0x00000012 vs. new->frame       0x00000012
trace:comm:check_events old->overrun     0x00000000 vs. new->overrun     0x00000000
trace:comm:check_events old->parity      0x00000000 vs. new->parity      0x00000000
trace:comm:check_events old->brk         0x00000000 vs. new->brk         0x00000000
trace:comm:check_events old->buf_overrun 0x00000000 vs. new->buf_overrun 0x00000000
/*repeat above section many times*/


trace:comm:get_modem_status 4126 -> MS_DSR_ON  MS_CTS_ON  
trace:comm:check_events mask 0x00000001
trace:comm:check_events old->rx          0x0000132d vs. new->rx          0x0000132e
trace:comm:check_events old->tx          0x000001ec vs. new->tx          0x000001ec
trace:comm:check_events old->frame       0x00000012 vs. new->frame       0x00000012
trace:comm:check_events old->overrun     0x00000000 vs. new->overrun     0x00000000
trace:comm:check_events old->parity      0x00000000 vs. new->parity      0x00000000
trace:comm:check_events old->brk         0x00000000 vs. new->brk         0x00000000
trace:comm:check_events old->buf_overrun 0x00000000 vs. new->buf_overrun 0x00000000

trace:comm:io_control 0x74 IOCTL_SERIAL_GET_COMMSTATUS (nil) 0 0x32fba8 20 0x32fb50
trace:comm:io_control 0x74 IOCTL_SERIAL_GET_TIMEOUTS (nil) 0 0x32fac0 20 0x32fb3c
/*repeat above section many times*/

trace:comm:get_modem_status 4126 -> MS_DSR_ON  MS_CTS_ON  
trace:comm:check_events mask 0x00000001
trace:comm:check_events old->rx          0x00001345 vs. new->rx          0x00001345
trace:comm:check_events old->tx          0x000001ec vs. new->tx          0x000001ec
trace:comm:check_events old->frame       0x00000012 vs. new->frame       0x00000012
trace:comm:check_events old->overrun     0x00000000 vs. new->overrun     0x00000000
trace:comm:check_events old->parity      0x00000000 vs. new->parity      0x00000000
trace:comm:check_events old->brk         0x00000000 vs. new->brk         0x00000000
trace:comm:check_events old->buf_overrun 0x00000000 vs. new->buf_overrun 0x00000000
trace:comm:wait_for_event device=0x74 fd=0x00000013 mask=0x00000001 buffer=0x7e0569e4 event=0x88 irq_info=0x12fc7c

trace:comm:get_modem_status 4126 -> MS_DSR_ON  MS_CTS_ON  
trace:comm:check_events mask 0x00000001
trace:comm:check_events old->rx          0x00001345 vs. new->rx          0x00001345
trace:comm:check_events old->tx          0x000001ec vs. new->tx          0x000001ec
trace:comm:check_events old->frame       0x00000012 vs. new->frame       0x00000012
trace:comm:check_events old->overrun     0x00000000 vs. new->overrun     0x00000000
trace:comm:check_events old->parity      0x00000000 vs. new->parity      0x00000000
trace:comm:check_events old->brk         0x00000000 vs. new->brk         0x00000000
trace:comm:check_events old->buf_overrun 0x00000000 vs. new->buf_overrun 0x00000000
trace:comm:get_modem_status 4126 -> MS_DSR_ON  MS_CTS_ON  
trace:comm:check_events mask 0x00000001
/*repeat above section many times*/

trace:comm:io_control 0x74 IOCTL_SERIAL_PURGE 0x32e360 4 (nil) 0 0x32e30c
trace:comm:io_control 0x74 IOCTL_SERIAL_CLR_DTR (nil) 0 (nil) 0 0x32e30c
trace:comm:SetCommMask handle 0x74, mask 0
trace:comm:io_control 0x74 IOCTL_SERIAL_SET_WAIT_MASK 0x32e360 4 (nil) 0 0x32e30c
fixme:htmlhelp:HtmlHelpW HH case HH_CLOSE_ALL not handled.
trace:comm:get_irq_info TIOCGICOUNT err Bad file descriptor
warn:comm:get_modem_status ioctl failed
trace:comm:wait_for_event get_modem_status failed
trace:comm:check_events mask 0x00000001
trace:comm:check_events old->rx          0x00001345 vs. new->rx          0x00000000
trace:comm:check_events old->tx          0x000001ec vs. new->tx          0x00000000
trace:comm:check_events old->frame       0x00000012 vs. new->frame       0x00000000
trace:comm:check_events old->overrun     0x00000000 vs. new->overrun     0x00000000
trace:comm:check_events old->parity      0x00000000 vs. new->parity      0x00000000
trace:comm:check_events old->brk         0x00000000 vs. new->brk         0x00000000
trace:comm:check_events old->buf_overrun 0x00000000 vs. new->buf_overrun 0x00000000
warn:comm:check_events TIOCINQ returned error
trace:comm:get_irq_info TIOCGICOUNT err Bad file descriptor
warn:comm:get_modem_status ioctl failed
trace:comm:wait_for_event get_modem_status failed
trace:comm:check_events mask 0x00000001
trace:comm:check_events old->rx          0x00001345 vs. new->rx          0x00000000
trace:comm:check_events old->tx          0x000001ec vs. new->tx          0x00000000
trace:comm:check_events old->frame       0x00000012 vs. new->frame       0x00000000
trace:comm:check_events old->overrun     0x00000000 vs. new->overrun     0x00000000
trace:comm:check_events old->parity      0x00000000 vs. new->parity      0x00000000
trace:comm:check_events old->brk         0x00000000 vs. new->brk         0x00000000
trace:comm:check_events old->buf_overrun 0x00000000 vs. new->buf_overrun 0x00000000
warn:comm:check_events TIOCINQ returned error
/*end*/

By adding trace statements and recompiliing, I determined that the ReadFile function is called and it always returns false, setting a STATUS_PENDING error.