From owner-freebsd-stable@FreeBSD.ORG Wed Nov 26 02:19:18 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E39B106564A for ; Wed, 26 Nov 2008 02:19:18 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 128A18FC1A for ; Wed, 26 Nov 2008 02:19:17 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id mAQ2JFfV029957; Tue, 25 Nov 2008 21:19:16 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.8/8.13.3) with ESMTP id mAQ2JFEL065881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Nov 2008 21:19:15 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200811260219.mAQ2JFEL065881@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 25 Nov 2008 21:19:09 -0500 To: freebsd-stable@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Subject: sio vs uart vs ucomm problems / differences X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2008 02:19:18 -0000 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: 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: 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@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike