Hi,

On Mon, 2009-08-31 at 15:45 +0400, Bob True wrote:
> Hello you
> 
> I want to build some function for RS485 realize.
> the algorithm of this function is next :
> 
> 1. Set bit of I/O register to 1 for enable of transmit RS485 driver
> 2. write something to port 
> 3. tcdrain() for transmission complete
> 4. Set bit of I/O register to 0 for disable of transmit RS485 driver
> 
> But problem is in incorrect tcdrain() working. Function does not provide of 
> waiting of data transmission process complete
> Can you give some comments, or some solution of this problem
> 
> Thank you
> _______________________________________________
> uClinux-dev mailing list
> uClinux-dev@uclinux.org
> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
> This message was resent by uclinux-dev@uclinux.org
> To unsubscribe see:
> http://mailman.uclinux.org/mailman/options/uclinux-dev


I'm not sure about Linux-specific issues, but this tends to be a common
problem with embedded U(S)ARTs.

A typical UART will have a flag/ISR for TX buffer full and one for TX
shift register empty.

You have to make sure that the TX shift register empty is used in your 
system call before the media is returned to RX.

Further, it's quite common for UARTs to assert the shift register empty
too EARLY - this can vary from ~ 1/2 bit time up to a whole bit time
between different MCU UARTs... ! Some are OK.
This can be a real pain.

I don't have experience with coldfire mcf5282 UARTs, but it might pay to
scope out when exactly the TX shift register empty flag asserts.
If that turns out to be a problem, then the only solution I'm aware of
is to use a timer to wait out an extra bit time before stopping TX on
your RS485 transceiver...
It also helps when using higher bit rates, as it accounts for possible
propagation or incorrect termination issues on the bus.

HTH.

-- 
Best regards,
Kris


_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Reply via email to