uart vs sio differences ?

[Mike Tancsa]

Hi,

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.  (The same problems we are having happen 
as well on HEAD, so I am posting here).  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.  Not sure if thats an issue of the larger buffers of the 
16950 vs 16650? i.e. sio sees it as a plain old 16550 vs uart seeing 
it as a 16950

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.

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