Another problem with SIO_RTS_ENCAPSULATION

I am using the BSP capability to “frame” my serial transmit data with RTS. [I note that this was nominally a chip hardware feature of early Net/50 chips, which seems to have been removed from the manuals]. The way in which this is done seems a little odd. Initially RTS is made active before sending the first character, which is basically fine (although I would have preferred to see some settling delay). Then the UART is put into loopback mode, and the software keeps track of the number of characters transmitted and received - when the count of characters outstanding reaches zero, RTS is deactivated. Because this is run off the receive interrupt, it is a relatively long time before the software realises that all data has been sent - about 3ms at 9600 baud. While the UART is in loopback it of course ignores receive data, so misses the start of the next incoming data message. I can see that the implementation method may have some merit in a half-duplex multi-drop system, but there are many other applications where a much faster RTS is called for. Is there any reason why the code does not use the TXBC status interrupt, which signals that the transmit buffer is completely empty? Steve

I’ve encoured the same problem. I’ve tried to use the TXBC flag, but it didn’t work (the flag stays low). Can it be a silicium problem ? Currently I use a software loop to wait the end of transmition and switch RTS (an ugly solution …).

Jepp, there seems to be an undocumented hardware bug. please refer to the uart-specific topics in the NET+50 forums (“Serial channel “Transmit Buffer Closed” never occurs”). -stefan