5

You can determine how much data is available to read from a serial port under linux using an ioctl. Is it possible to determine how much buffer space remains for the serial port when writing to it? Effectively I want to write a block of data to a serial port, succeeding only if it can all be offloaded in one go, or failing if it would have to be chunked. The writes and reads to the ports are non-blocking. I'm not expecting this to be the UARTs buffer, but the kernels memory buffer ahead of the UARTs buffer (I guess).

dsolimano
  • 8,870
  • 3
  • 48
  • 63
Joe
  • 7,378
  • 4
  • 37
  • 54
  • I *suspect* it comes down to the hardware tx/rx FIFO size, which is abstracted from you by the kernel... but does the kernel just hold it in an internal buffer when it's too much for the HW? That I do not know. – Mike Nov 01 '12 at 16:13
  • That's what I expect, so there must be some upper bound on that kernels internal buffer. A bound I was expecting to be able to retrieve. – Joe Nov 01 '12 at 16:19
  • It's likely worth re-evaluating the problem definition and considering alternative design options. Maybe an asynchronous IO scheme would be better. Or `open` w/`O_NONBLOCK`, look for `EAGAIN`. – Brian Cain Nov 02 '12 at 14:05
  • Effectively I'm trying to replicate the functionality send() offers for sockets, i.e. it all goes or none goes. I'm abstracting the physical transport away from the rest of the application. The whole system is already non-blocking, so I know that the write won't block, I just don't know if it will offload all the data I want to kernel space. – Joe Nov 02 '12 at 14:09
  • Ok, so try `O_NONBLOCK`. – Brian Cain Nov 02 '12 at 14:20
  • I don't understand - it is already ALL non-blocking. It IS O_NONBLOCK. But all that means is that I won't block, not that I can write the amount I want to write. Just using O_NONBLOCK means that the write can part-succeed, which is not a replication of sends() functionality with a socket. Spinning trying to write the rest then effectively makes the call blocking, so that's no good. Passing back the bytes written then breaks the abstraction. – Joe Nov 02 '12 at 14:23
  • NetBSD has FIONSPACE and FIONWRITE support for tty(4) devices (as well as sockets). I think they allow something like what you want. Keep in mind that the kernel side of a serial port device typically has two layers, the tty(4) lower driver, and a line discipline, typically termios(4). If you want a write to succeed in its entirety on a tty(4) device than you'll have to let it block. – Greg A. Woods Nov 17 '12 at 05:04

3 Answers3

6

You can determine the amount of write/output.

For read:

ioctl(device_handler, TIOCINQ, &bytes);

For write:

ioctl(device_handler, TIOCOUTQ, &bytes);

Size of FIFO buffer:

serial_struct serinfo;
memset(&serinfo, 0, sizeof(serinfo));
ioctl(device_handler, TIOCGSERIAL, &serinfo);
serinfo.xmit_fifo_size;

Regards, VA.

Vitalii Arteev
  • 61
  • 1
  • 2
0

The serial port is a character device not a block device. It has no buffer. Character devices ( such as Serial port, keyboard, mouse) only writes and reads a character not a word. For exame if you listen to a serial someone writes " have a nice day ", if you do not listen from the time he starts typing, you would not see the entire phrase. You would see only the characters typed when you listen

Bogdan-Stefan Mirea
  • 154
  • 3
  • But surely there's *some* buffering in there? There's the UARTs FIFOs at least. And what buffer is the FIONREAD ioctl looking at? – Joe Nov 05 '12 at 08:49
  • Yes, there is buffering, but as far as I know it could be accessible only in Kernel Mode. You have to load a module in the Kernel, to listen to the device drive – Bogdan-Stefan Mirea Nov 06 '12 at 11:05
  • It seems strange that I can find the kernel mode buffering size for reads with the FIONREAD ioctl but there's no parallel for writes. :-P – Joe Nov 07 '12 at 13:51
0

If you access serial port using file descriptor, you can use select for checking whenever the descriptor is ready for non-blocking write. I don't know whenever this works for serial ports. I used this for TCP sockets and it worked.

Vladimír Matěna
  • 81
  • 3