From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8182 invoked by alias); 23 Jan 2008 22:03:56 -0000 Received: (qmail 8171 invoked by uid 22791); 23 Jan 2008 22:03:56 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Jan 2008 22:03:31 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JHngp-00052l-5P for ecos-discuss@sources.redhat.com; Wed, 23 Jan 2008 22:03:23 +0000 Received: from c-76-17-159-23.hsd1.mn.comcast.net ([76.17.159.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Jan 2008 22:03:23 +0000 Received: from grante by c-76-17-159-23.hsd1.mn.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 23 Jan 2008 22:03:23 +0000 To: ecos-discuss@sources.redhat.com From: Grant Edwards Date: Wed, 23 Jan 2008 22:03:00 -0000 Message-ID: References: User-Agent: slrn/0.9.8.1 (Linux) X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] Re: Half Duplex RS485 X-SW-Source: 2008-01/txt/msg00145.txt.bz2 On 2008-01-23, Laurie Gellatly wrote: >>I imagine that RTS is shutting off too soon. The problem is >>that pc_serial_stop_xmit() is called when the driver has no >>more data to send _to_ the UART. That's not when you need to >>shut off RTS. You need to shut off RTS when the UART is done >>sending data and both the FIFO and shift register are empty. >> >>You're probably shutting off RTS while the UART still has data >>in the tx FIFO and the tx shift register. > > Funny thing is that it appears that the first part of the > transmission is lost. Ah. If you look at io/serial.c, you can see that the serial_write() function calls start_xmit() _after_ it's done filling up the UART's tx fifo (the UART will start sending when the first byte is written to the tx fifo). RTS needs to be asserted before any data is written to the tx fifo. That means that start_xmit() is being called too late: the first byte is already on it's way out of the UART before start_xmit() is called. If your protocol allows it, adding an extra "idle" byte to the beginning of the message will probably fix that. Off the top of my head, here are a couple other options: 1) Add code to the low-level driver's putc() method that asserts RTS _before_ it transfers the byte to the UART tx fifo. 2) Add another driver hook that is called by serial_write() before it fills the tx fifo. 3) Always leave the UART in a mode where the transmit logic is disabled until it's enabled by a call to start_xmit(). IOW, when the last bit it in a transmission has been sent not only do you de-assert RTS, you also shut off the UART's transmit hw so that the next time somebody fills up the tx fifo nothing goes out until start_xmit() is called. Number 1) is probably the simplest. > Grant, do you know if the LPC series have 'broken' UARTS? > Specifically LPC2212 and LPC2103? U0TSR looks promising as an > indication of when the bits 'have left the building' - is it > accurate or do I need to add a time delay? I don't know -- I've never worked with the LPC parts. The vast majority of the the parts I've used have been OK (many don't provide an interrupt, but at least the status bit worked correctly when polled). IIRC, the ones that I had problems with were a UART in one of Motorola's old uControllers (don't remember which one, but it was from about 10-15 years ago) and a couple different PC motherboard chipsets. At one point I modified the Linux PC UART driver to support half-duplex operation, but it never worked reliably, so I just gave up and bought serial cards that had UARTs which supported half-duplex mode. Now that I think about it, I also built a little 9-pin pass-through dongle with a one-shot in it that controlled RTS. It worked pretty well also (for the one baud rate it was designed for), but since the first bit was usually mangled, it only worked on protocols where the messages had training preambles. -- Grant Edwards grante Yow! We are now enjoying at total mutual interaction in visi.com an imaginary hot tub ... -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss