sio vs uart vs ucomm problems / differences

Mike Tancsa mike at sentex.net
Tue Nov 25 18:19:18 PST 2008


We are in the process of migrating one of our embedded apps to use 
uart by default instead of sio in RELENG_7 in prep for the day when 
sio eventually disappears.  Unfortunately, the application doesnt 
want to work with uart with puc backed devices, but still works with 
sio. Stranger still, the app works with the uart driver when uart 
attaches to the built in com port on the isa bus.  However, its uart 
devices when its connected to a PUC backed serial card where the 
problems happen.

e.g. when the uart driver attaches as so,

puc0: <Oxford Semiconductor OX16PCI954 UARTs> port 
0xe520-0xe53f,0xe540-0xe55f mem 
0xa0005000-0xa0005fff,0xa0006000-0xa0006fff irq 15 at device 17.0 on pci0
puc0: [FILTER]
uart0: <16950 or compatible> on puc0
uart0: [FILTER]
uart1: <16950 or compatible> on puc0
uart1: [FILTER]
uart2: <16950 or compatible> on puc0
uart2: [FILTER]
uart3: <16950 or compatible> on puc0
uart3: [FILTER]

the applications does not work.  When its the sio driver, it works as expected

puc0: <Oxford Semiconductor OX16PCI954 UARTs> port 
0xe520-0xe53f,0xe540-0xe55f mem 
0xa0005000-0xa0005fff,0xa0006000-0xa0006fff irq 15 at device 17.0 on pci0
puc0: [FILTER]
sio1 on puc0
sio1: type 16550A
sio1: [FILTER]
sio2 on puc0
sio2: type 16550A
sio2: [FILTER]
sio3 on puc0
sio3: type 16550A
sio3: [FILTER]
sio4 on puc0
sio4: type 16550A
sio4: [FILTER]

Unfortunately, we only control the FreeBSD side of things and the 
other end of the serial connection is a windows app we dont 
control.  Everything seems to work ok from our side, but the other 
side which we dont control seems to be missing some things we are 
sending it and vice versa.  I also tested the application with a ucom 
attached driver and it also does not work so I suspect something our 
app is doing.

However, if I use something like minicom or cu, I see 2 way 
communication just fine and I can transfer data back and forth just 
fine.  Is it possible some defaults are different from sio to uart 
that our app might not be setting properly when opening up the port ?

The open routine is below

static int
open_dev(struct dev *dev)
{
     struct termios t;
     int val;


     cur_state.carrier = 0;
     if (cur_state.num_trans == 0) {
         cur_state.startup = time(0);
     }
TRY_OPEN_AGAIN:
     dev->fd = open(dev->name, O_RDWR);
     if (dev->fd >= 0) {
         if (debug) {
             syslog(LOG_LOCAL1 | LOG_DEBUG,
                     "(%s) %s:%d: open_dev",
                     dev->name,
                     __FILE__,
                     __LINE__);
         }
         if (tcgetattr(dev->fd, &t) >= 0) {
             t.c_ispeed = dev->speed;
             t.c_ospeed = dev->speed;
             t.c_lflag &= ~(ICANON | ISIG | IEXTEN | ECHO | ECHOE | 
ECHOK | ECHOKE | ECHONL | ECHOCTL | ECHOPRT | ALTWERASE | NOFLSH
| TOSTOP | FLUSHO | PENDIN | NOKERNINFO | EXTPROC);
             t.c_iflag &= ~(ISTRIP | ICRNL | INLCR | IGNCR | IXON | 
IXOFF | IXANY | IMAXBEL | IGNBRK | BRKINT | INPCK | IGNPAR | PARM
RK);
             t.c_oflag &= ~(OPOST | ONLCR | OCRNL | OXTABS | ONOEOT | 
ONOCR | ONLRET);
             t.c_cflag &= ~(CSIZE | CSTOPB | PARENB | CCTS_OFLOW | 
CRTS_IFLOW | CDTR_IFLOW | CDSR_OFLOW | CCAR_OFLOW);
             t.c_cflag |= (CS8);
             t.c_cc[VMIN] = 1;
             t.c_cc[VTIME] = 0;
             tcsetattr(dev->fd, TCSANOW, &t);
             val = fcntl(dev->fd, F_GETFL, 0);
             if (val >= 0) {
                 fcntl(dev->fd, F_SETFL, val | O_NONBLOCK);
             }
         }
         else {
             tcflush(dev->fd, TCIOFLUSH);
             close(dev->fd);
             dev->fd = -1;
         }
     }
     else {
         if (errno == EINTR)
             goto TRY_OPEN_AGAIN;
         syslog(LOG_LOCAL1 | LOG_DEBUG,
                 "(%s) open_dev errno=%d %s",
                 dev->name,
                 errno,
                 strerror(errno));
     }

     return dev->fd;
}




         ---Mike


--------------------------------------------------------------------
Mike Tancsa,                                      tel +1 519 651 3400
Sentex Communications,                            mike at sentex.net
Providing Internet since 1994                    www.sentex.net
Cambridge, Ontario Canada                         www.sentex.net/mike



More information about the freebsd-stable mailing list