McGregor80 wrote:In my understanding hardware flow control was automatic (no software/kernel involving) setting and clearing the RTS line which should be connected to DE pin in RS485 converter chip. When data is being sent RTS should be high, otherwise low.
There is hardware control of RTS in addition to kernel control. The hardware can de-assert RTS if its receive FIFO is full. In practice this is unlikely to happen because when the FIFO is half full an interrupt is generated and the kernel initiates a PIO or DMA to empty it. Also note that both the hardware and kernel agree that RTS means "you can send to me", not "I want to send".
edit: In fact, it may simply be that once the kernel buffer is full it allows the hardware FIFO to fill too. So actually it is always the hardware that ultimately de-asserts RTS, at least on devices that support it.
That is not an accurate description of RTS/CTS signalling, either as specified by RS232, or as implemented by PCs of the last 30 years. But it does not affect his main point about avoiding winmodems.
As that page says: "The RTS Control function has to be written into the application program and is not an operating system function which you can configure […] Do not confuse RTS Control with the more common operating mode of the RTS signal which is hardware flow control and which is unsuitable for controlling an RS232-RS485 converter."
This form of RTS control is not the same as the form originally written in RS232, either. There, the DTE would assert RTS and then wait for CTS before transmitting. This allowed time for the two modems to agree on the direction of transmission. These half-duplex RS485 chips do not negotiate with each other and provide a CTS signal. So it is always the responsibility of the high-level protocol to ensure that the two ends do not transmit at the same time. (Or can recover if they do.)