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