RE: [ECOS] Re: Half Duplex RS485

["Laurie Gellatly" <laurie dot gellatly at netic dot com>]

Grant,

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

Possibly part of my problem stems from having two serial lines.
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.

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?

Thanks again. 			...Laurie:{)

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