June-7th-2019, 03:02 PM
Hello Lukas,
we have investigated your point and examined the BCM UART1 registers in-deep as stated yesterday in the post. To cut a long story short: the AUTO_RTS behaviour is not like we need it and we have no soltution.
When enabling the AUTO_RTS function the chip asserts indeed the RTS signal automatically (as we would need it) when you start sending BUT it does not de-assert it after sending is finished. The signal remains asserted and lets the RS-485 driver remain in transmit mode forever. For real RS-485 circuits when using the two additional signals RTS/CTS this behaviour is ok, cause then the RTS signal is de-asserted when the remote partner starts to send and fills the receive data queue ... but for the RS-485 circuitry as we use it today this is a no go.
The next things we looked at in detail were the other UART1 registers and search for a possibility to detect - with a special driver to be developed - when the transmit shift register is sending our the very last bit of a data stream to use it as a trigger to de-assert the RTS chip in the driver , in an interrupt routine for example. But unfortunately there is not any register in BCM CPU where such a bit or indication exists. So this was also a dead end here.
So neither the AUTO_RTS is usable for us nor a special driver that could do this handling in software instead of the hardware. I am sorry to say that we have no solution for you at this time. I agree that the handling of the RS485 interface is difficult if you have no possibility to change the program that uses the serial port for your use case
Armin
we have investigated your point and examined the BCM UART1 registers in-deep as stated yesterday in the post. To cut a long story short: the AUTO_RTS behaviour is not like we need it and we have no soltution.
When enabling the AUTO_RTS function the chip asserts indeed the RTS signal automatically (as we would need it) when you start sending BUT it does not de-assert it after sending is finished. The signal remains asserted and lets the RS-485 driver remain in transmit mode forever. For real RS-485 circuits when using the two additional signals RTS/CTS this behaviour is ok, cause then the RTS signal is de-asserted when the remote partner starts to send and fills the receive data queue ... but for the RS-485 circuitry as we use it today this is a no go.
The next things we looked at in detail were the other UART1 registers and search for a possibility to detect - with a special driver to be developed - when the transmit shift register is sending our the very last bit of a data stream to use it as a trigger to de-assert the RTS chip in the driver , in an interrupt routine for example. But unfortunately there is not any register in BCM CPU where such a bit or indication exists. So this was also a dead end here.
So neither the AUTO_RTS is usable for us nor a special driver that could do this handling in software instead of the hardware. I am sorry to say that we have no solution for you at this time. I agree that the handling of the RS485 interface is difficult if you have no possibility to change the program that uses the serial port for your use case
Armin
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
