[ECOS] Re: Half Duplex RS485

Grant Edwards grante@visi.com
Wed Jan 23 23:44:00 GMT 2008


On 2008-01-23, Laurie Gellatly <laurie.gellatly@netic.com> wrote:

>>> 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.


> Did not see that xmit happened after the FIFO was filled. I
> have to flip a bit before the transmit and clear it when done.
> So I'm thinking that setting the bit before the cyg_io_write
> in application code would be OK and clear it (after waiting
> for TEMT plus maybe a small delay) in xmit_stop might work for
> me. I always write a complete message so as long as stop_xmit
> happens fairly soon after the last bit has gone then I'll be
> ready to receive the response.

stop_xmit doesn't happen after the last bit is gone.  It
happens a long, long time before that.

stop_xmit() is called when the last byte has been transferred
from the serial driver's buffer into the UART's tx fifo.  At
the point in time when stop_xmit() is called, there's still up
to an entire fifo's worth (somewhere from 8 to 4K bytes
depending on the UART) of transmit data still waiting to be
sent.  It could happen many seconds before the last bit has
gone.  At 9600 baud with a 1K tx fifo, it would get called
about one second before the last bit is gone (assuming the tx
message didn't fit entirely within the tx fifo).

Despite it's name, stop_xmit() has nothing to do with the UART
stopping transmission.  It is called to shut off the tx
interrupt that requests additional tx data from the serial
driver's transmit buffer.  It is called when the upper level
serial driver has no more bytes to send.  The UART might still
have plenty of bytes waiting to be sent.  stop_xmit() is not
all that useful in determining when the UART has finished
sending bits down the wire.  There's no point in polling for tx
empty until stop_xmit() has been called, but there can be a
very long time between stop_xmit() and the transmission being
completed.  You need to be prepared to poll for an entire tx
fifo's worth of time.

> Possibly part of my problem stems from having two serial
> lines.

I wouldn't think so.  The ports should operate independently.
If they don't, then I'd say the low-level driver is broken.

> One for 485 and the other for 232. The 232 serial line uses
> ppp_chat to conduct a simple exchange. When you include the
> ppp package it forces you to have flow control on ALL serial
> lines and I don't want that on the 485 line.

It sounds to me like the PPP package is broken if it's mucking
about with serial ports on which you're not using PPP.

> Looks like I'll have to try to carve out ppp_chat and make it 
> into its own package without the flow control requirement 
> unless you have a better alternative?

I've never looked at the PPP stuff, and I don't know how flow
control works in the standard serial driver.  In my serial
driver, flow control is configurable on a per-port basis at run
time by the application and is implemented by either the UART
itself or by the low-level driver in the case of UARTs that
don't do flow control in hardware.

-- 
Grant Edwards                   grante             Yow! PEGGY FLEMMING is
                                  at               stealing BASKET BALLS to
                               visi.com            feed the babies in VERMONT.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



More information about the Ecos-discuss mailing list