ISO Example for reading/writing uart/rs-232
thilo at tjps.eu
Wed Dec 16 15:07:38 CET 2015
On Tuesday 15 December 2015 23:08:39 you wrote:
> 1. When the registered callback fires with the EV_WRITE flag set on the
> third argument, does that mean the port associated with the file descriptor
> is ready to be written to
Correct. However, this "write ready event" is not necessarily triggered
directly by the level on the CTS line. There are buffers in between, on OS
level and even on your UART in hardware. I don't know how it's implemented on
Linux but I can imagine a "write ready" event could be triggered if some buffer
has space to take up new data, even though there's still data in the send
queue. Currently, there's no good way to check on the send status of your
serial device. Linux has the TIOCSERGETLSR ioctl, which will tell you the
status of your hardware send queue, but this is not implemented for all serial
hardwares and it certainly is not portable.
Consequently, a write ready event is no guarantee, that you will be able to
write all of your data. You need to check the return value of write() for how
much has been added to the socket's send buffer.
> 2. And when the callback fires with a EV_READ flag set - it would be
> synonymous with a call back registered from a sigaction structure with the
> O_ASYNC flag set on the file descriptor?
As Marc said, it tells your program that a call to read() should not block on
that file descriptor.
Signal handlers can be called at any point in program flow of your main
process, so there are similar issues as you do have with threads.
And that is truly the beauty of an event library like libev: You can do away
with both those crutches to implement non-blocking I/O, without worrying about
OS specific backends.
More information about the libev