Home/ Questions/Q 240083
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T20:38:14+00:00

I am sending data from a linux application through serial port to an embedded

  • 0

I am sending data from a linux application through serial port to an embedded device.

In the current implementation a byte circular buffer is used in the firmware. (Nothing but an array with a read and write pointer)
As the bytes come in, it is written to the circular bufffer.

Now the PC application appears to be sending the data too fast for the firmware to handle. Bytes are missed resulting in the firmware returning WRONG_INPUT too mant times.

I think baud rate (115200) is not the issue. A more efficient data structure at the firmware side might help. Any suggestions on choice of data structure?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    A circular buffer is the best answer. It is the easiest way to model a hardware FIFO in pure software.

    The real issue is likely to be either the way you are collecting bytes from the UART to put in the buffer, or overflow of that buffer.

    At 115200 baud with the usual 1 start bit, 1 stop bit and 8 data bits, you can see as many as 11520 bytes per second arrive at that port. That gives you an average of just about 86.8 µs per byte to work with. In a PC, that will seem like a lot of time, but in a small microprocessor, it might not be all that many total instructions or in some cases very many I/O register accesses. If you overfill your buffer because bytes are arriving on average faster than you can consume them, then you will have errors.

    Some general advice:

    • Don’t do polled I/O.
    • Do use a Rx Ready interrupt.
    • Enable the receive FIFO, if available.
    • Empty the FIFO completely in the interrupt handler.
    • Make the ring buffer large enough.
    • Consider flow control.

    Sizing your ring buffer large enough to hold a complete message is important. If your protocol has known limits on the message size, then you can use the higher levels of your protocol to do flow control and survive without the pains of getting XON/XOFF flow to work right in all of the edge cases, or RTS/CTS to work as expected in both ends of the wire which can be nearly as hairy.

    If you can’t make the ring buffer that large, then you will need some kind of flow control.

    • 0