Hi all, At Guido's request here are my thoughts: > Units this parameters are given. The crisv10.c driver gets the > delay_before_send in milliseconds and atmel_serial > delay_rts_after_send in bit-times (means depending on baud rate). RTS delays should be given in ms not in bit-times since they are not related to bit rate but to amplifiers and peer software response times. > But in the atmel_serial.c driver rthe Transmit Timeguard function of > the AT91 USART is used to implement this. The purpose of the Transmit > Timeguard function is to throttle transmission in case the receiving > device is able to receive/process incoming characters at line > speed. This means the USART will insert a gap between EACH transmitted > byte and not only the last of a frame. Atmel surely had its reasons > to implement such a function, but luckily nowadays such devices are Sounds to me like a "quick and dirty" implementation of the RTS toggling, to avoid the burden of setting timers etc. The interbyte gap is not needed. > An other point I don't understand is why ATMEL_US_TXEMPTY interrupt is > used when in RS485 mode insted of the normal ATMEL_US_TXRDY or > ATEM_US_ENDTX interrupts. In the RS485 mode the AT91 USART will > connect the RTS pin to the internal TXEMPTY signal to drive the RTS > until the last bit is shifted out. But this should not have any affect > on ow the drive will pump out the bytes to the USART's transmit hold > register? Well, you need to ascertain that the previous frame is all out AND the RTS has dropped before sending a new frame. Else the receiver might think it is the same long frame. Using TXEMPTY interrupt avoids setting an extra timer. However in the real life you are half-duplex and never send two frames in a row without waiting for an answer. Other than that I agree with your remark. > rare. But this function is not especially related to RS485. It is > also applicable in RS232 mode. So in my view it is not the True, it applies to some half-duplex RS232 radio modems too AFAIK. French regards, Jean-Pierre Tosoni -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
