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.

[poonamdeoghare]

Hello everyone , I am trying to use the UART interface with Fprime, but I am struggling to invoke my send and receive call when I run the deployment. I created the input and output ports and created the connections also for the same. Do I have to attach them to the rategroup? ReadyUART call is getting invoked but recv and send are not working. can you suggest.

[LeStarch]

This would be best made into a separate discussion. It sounds like you are building your own UART driver. Let's break it into two parts:

1. Receive must be triggered. It is either a while (true) that always calls receive and then sends data out the recv port (this is how LinuxUartDriver works) or it is polled via a rate group (ZephyrUartDriver in the fprime-zephyr package works this way).
2. Send is called by user code, so if it is not being invoked, your user code is not sending data.

If you need more help, I'd recommend moving this to a new Discussion so it remains visible (this one has a selected answer).