UART Driver only reading 16 bytes at a time

[VR314]

We are using the Linux UART driver to receive command hex packets from our spacecraft bus. We have confirmation that the bus is sending packets of length 17+ (depending on the command), and we can see that the UART driver is receiving them in buffers limited to size 16 bytes. We need the entire packet to be read into one buffer, since that is what our deframing logic expects to see. For example, for a 17-byte packet, we are seeing one buffer of the first 16 bytes, and a second buffer being passed on the next port call with the remaining one byte. We want to know why the buffer size is being capped to 16 bytes and if this can be changed.

In the LinuxUARTDriver, we are passing m_allocationSize as 24 into the open function in instances.fpp:

const bool status_comm = commUARTDriver.open("UART_LOCATION_HERE", Drv::LinuxUartDriver::UartBaudRate::BAUD_115K, Drv::LinuxUartDriver::UartFlowControl::NO_FLOW, Drv::LinuxUartDriver::UartParity::PARITY_NONE, 24);

In this section of the code, these are the values we are observing using debug statements, in the serialTaskEntry function, LinuxUARTDriver.cpp:348):

while (!comp->m_quitReadThread) {
       Fw::Buffer buff = comp->allocate_out(0, comp->m_allocationSize);
       // VALUES AT THIS POINT
       // buff.size() = 5000 (why?)
       // buff.data = a pointer address


       // OMITTED SECTION: On failed allocation, error and deallocate

      int stat = 0;

      while ((stat == 0) && !comp->m_quitReadThread) {
          stat = ::read(comp->m_fd, buff.getData(), buff.getSize());
      }
      
       // VALUES AT THIS POINT: 
       // stat = 16

One behavior we can't seem to understand is that the allocated buffer has size 5000, even though the allocate port call is only trying to allocate 24 bytes. However, we're not sure if this is really relevant to the problem. The main problem is that the read function is only reading 16 bytes at a time, but since it is an OS call it's difficult to understand why that's happening.

[timcanham]

This is very likely a function of the buffer in the underlying hardware. It isn't uncommon for the OS call to receive the data in chunks like this. In general, you can't count on the underlying hardware to deliver it to you in chunks that exactly match your packet size, so you have to sync with your packets with another method like a sync value or just counting bytes.