B
BruceVx
Guest
This is an observation rather than a query, but I would appreciate feedback on anything I’ve got wrong. For many years my software work has involved comms with external devices, and for much of that time the connection method was RS232/serial. The target devices were generally programmed in low level languages, and the comms involved directly accessing the UART (16550 &al) registers. When the Win32 API came out, with serial ports treated like a ‘file’, I was surprised to find that when a thread handling serial read blocked, the serial write for that port also blocked. That makes no sense, given that the Tx and Rx lines on a UART are effectively independent aside from some common elements such as data rate. It seems to lead to some rather illogical requirements, such as having to assign low enough timeouts to port reads to allow writes to be actioned without undue delays, accordingly creating senseless thread CPU churn.
It’s been a great relief to move to USB – using the Cypress API – to find that the two directions on a USB port are truly independent. I can allow a receive thread on a host machine to block indefinitely, signal (and loop) when it receives data, and at the same time transmit data to the target freely.
I can see no logical reason why the serial API could not function as per USB. One thing I tried in desperation was to open a serial port twice, with two file handles, one for GENERIC_READ and one for GENERIC_WRITE. Unfortunately, Windows doesn’t allow that.
RS232 is almost certainly on the way out, so I guess it’s unlikely that anything will change on its behalf. Am I missing something fundamental here – ie. is it possible to block a serial port one way and leave the other way open? And is the current file-focussed API design a reflection of a misinterpretation of how the hardware works?
bv
Continue reading...
It’s been a great relief to move to USB – using the Cypress API – to find that the two directions on a USB port are truly independent. I can allow a receive thread on a host machine to block indefinitely, signal (and loop) when it receives data, and at the same time transmit data to the target freely.
I can see no logical reason why the serial API could not function as per USB. One thing I tried in desperation was to open a serial port twice, with two file handles, one for GENERIC_READ and one for GENERIC_WRITE. Unfortunately, Windows doesn’t allow that.
RS232 is almost certainly on the way out, so I guess it’s unlikely that anything will change on its behalf. Am I missing something fundamental here – ie. is it possible to block a serial port one way and leave the other way open? And is the current file-focussed API design a reflection of a misinterpretation of how the hardware works?
bv
Continue reading...