RE: [ECOS] Re: Half Duplex RS485

[wangcui <iucgnaw@msn.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 3670 bytes --]


Just FYI, the LPC2XXX's UART0 is not fully functional. So when the 16x5x serial driver check FIFO(in serial_config_port()), it will fail, thus FIFO is disabled for UART0. But UART1 works fine.

To resolve it, I have to modified 16x5x driver code, force enable FIFO for UART0 and UART1.

> From: laurie.gellatly@netic.com
> To: grante@visi.com; ecos-discuss@sources.redhat.com
> Date: Thu, 24 Jan 2008 08:12:17 +1100
> Subject: RE: [ECOS] Re: Half Duplex RS485
>
> Wang/Grant, thanks for the replies.
>
>>> My project has RS485 half duplex driven by UART0 of an
>>> LPC2112. At present I've modified pc_serial_start_xmit and
>>> pc_serial_stop_xmit to change a pin state so that the same
>>> wires can be used for transmit and receive.
>>>
>>> This does not see to work when the FIFO is enabled.
>>
>>Then you probably did it wrong. :)
>>
>>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.
>
>>> Has anyone else done RS485 half duplex?
>>
>>Many, many times.
>>
>>> Did you modify these routines or write your own?
>>
>>I usually pick a UART that supports half-duplex operation, and
>>then just enabled that feature in the UART. [I use a custom
>>eCos serial driver that supports quite a few more advanced UART
>>features than the standard driver (e.g. flow control,
>>half-duplex, inter-byte timeouts, 9-bit modes, FIFO control,
>>etc.).
>>
>>If you don't have a proper UART, you need to enable the tx
>>shift register empty interrupt and use that to trigger code
>>that de-asserts RTS. If you're using a broken UART that
>>doesn't have a tx shift register empty interrupt, then you'll
>>have to poll for the tx shift register empty status. If you're
>>using a really broken UART that doesn't have a _working_
>>shift-register empty status[1], then you may have to start a
>>timer that will wake you up at the point in time where RTS
>>needs to be changed.
>>
>>> Did you get the FIFO to work?
>>
>>When there was one, yes.
>>
>>
>>[1] There are broken UARTs (including a few PC chipsets) whose
>> shift-register empty bit gets set _before_ the stop bit has
>> been sent. In that case, you may need to use some sort of
>> time-delay to wait until after the stop bit has been sent
>> to toggle RTS. On a properly implimented RS-485 bus, there
>> should be pull-up and pull-down resisters so that the bus
>> idles in the mark state (same value as a stop bit), but to
>> be on the safe side you should leave the bus driver on
>> until after the stop bit has been sent.
>
> 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?
>
> Really appreciate the help. ...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
>

_________________________________________________________________
ÌìÁ¹ÁË£¬ÌíÒÂÁË£¬ÐĶ¯ÁË£¬¡°Æß¼þ¡±ÁË 
http://get.live.cn

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