How to Avoid Idle Signal on Ethernet Cable IEEE 802.3

The 14550 UART is a brain dead construction even for RS-485, not to mention Modbus RTU.

In that idiot design, you can get an interrupt, when the last byte is transferred _into_ the shift register. For any practical RS-485 purposes, the only interesting time is when the last transmitted message last stop bit has been actually sent.

For the idiotic 14550 chip the only way to detect this is by polling (busy looping) a HW register (no interrupt available), until that bit is actually sent.

While this might be acceptable for single thread executive like PC/MS-DOS, this is completely unacceptable in any multitasking environment.

Remember that the 8250 (base model for PC async serial interface) was made for RS-232 modem connections. It is not interesting when sending is done, only when more can be pushed to the pipeline.

The same applies even more to the newer versions with FIFOs.

One thing you have to remember about wireshark is that it has to be in the same domain as your endpoints: either on one of them, listening to the same interface used for communication, or on a network HUB. If you connect it to the network switch, it will only see the broadcast traffic. Sorry for being Cap't Obvious here but it's easy to forget this unless you work with it all the time---ask me how I know.

On a sunny day (Mon, 23 Sep 2013 23:00:21 +0300) it happened snipped-for-privacy@downunder.com wrote in :

I dunno exactly, but you could set a timer, and test the bit in that timer interrupt, that way the code can continue. Or test the bit the next time the scheduler was around. Slower, perhaps, but what is slow.. Preemptive?