Serial commands queuing

Hi, i have arduino mega that connected device to Serial1
It takes commands from Serial1 and toggle pins high or low based on this commands

My concern is, what if there are 1 commands took longer than the second command that came in?
In another way is there a queuing system code that could be useful for not missing any command at anytime?

It's a serial interface, commands are inherently queued.

Yes, you could create your command codes so that there are separate "set" and "latch" commands. You would send all the "set" commands first, buffer them in the receiver, and only execute them when receiving a "latch" command.

There is a 64 byte long FIFO BUFFer associated with Serial1 UART Port. Data/commands that are coming over Serial1 Port are automatically stored/queued in this BUFFer from which the user can always read them. The following conceptual level diagram (drawn for UNO) may help to visualize the FIFO BUFFer reality associated with UART Port.

uartblk.png

uartblk.png

GolamMostafa:
There is a 64 byte long FIFO BUFFer associated with Serial1 UART Port. Data/commands that are coming over Serial1 Port are automatically stored/queued in this BUFFer from which the user can always read them. The following conceptual level diagram (drawn for UNO) may help to visualize the FIFO BUFFer reality associated with UART Port.

uartblk.png

Actually it is the first project using the serial communications so i have this concern

But the code will be simple, i'll control about 20 digital pins using commands sent from serial 1-20 on/off

And maybe a command sent every 1 second to the arduino and report back the state of the pin

So will the hardware handle (FIFO) if i sent multiple commands
On1
On2
Off1
On3
.....
Command every say 1 or 0.5 second

And i tried with 9600 baud rate to test but didn't try this scenario yet

So as you say it should be handled untill unprocessed 64 commands/bytes without needed to worry

@Golam, the serial input buffer has no bearing on this question. The FIFO is emptied by requests from a serial read. There might be no buffer at all and the OP question would remain the same.

KareemWaheed:
Actually it is the first project using the serial communications so i have this concern

But the code will be simple, i'll control about 20 digital pins using commands sent from serial 1-20 on/off

And maybe a command sent every 1 second to the arduino and report back the state of the pin

So will the hardware handle (FIFO) if i sent multiple commands
On1
On2
Off1
On3
.....
Command every say 1 or 0.5 second

And i tried with 9600 baud rate to test but didn't try this scenario yet

So as you say it should be handled untill unprocessed 64 commands/bytes without needed to worry

If your command structure is 3/4 characters like On1, On2, Off1..., then the FIFO BUFFer will queue/hold only 64/4 = 16 commands before the BUFF undergoes overflow.

aarg:
@Golam, the serial input buffer has no bearing on this question. The FIFO is emptied by requests from a serial read. There might be no buffer at all and the OP question would remain the same.

It is possible that the OP's questions/queries are not always understood by the readers to the exact level of OP's understanding.

The Arduino is incredibly fast compared to serial data transfers. Even more so if you're using such a glacial baud rate. You should have no problem at all processing commands unless you do something silly like using delay.

GolamMostafa:
It is possible that the OP's questions/queries are not always understood by the readers to the exact level of OP's understanding.

Oh, I see now. Reply #8 raises an important point, that you have to process the commands reasonably fast.

wildbill:
The Arduino is incredibly fast compared to serial data transfers. Even more so if you're using such a glacial baud rate. You should have no problem at all processing commands unless you do something silly like using delay.

Yes i hear you in that delay part

But in code in the loop part should not be a delay like after or before reading from serial or anywhere, as the code is high/low different pins

Then you're worrying about a problem that doesn't exist.

The problem that I see, is that the serial port / buffer has no understanding of the content, it’s simply a ‘wire’ between the pin and your sketch, which purely by good fortune can stack up a number of characters before overflowing.

In good style, it’s preferred to NOT use the hardware receive buffer to queue your separate messages because it can be overrun very quickly, it’s only there because characters may arrive before you’ve had time to accept and process them.

What you should do, is ,’accept’ the incoming stream of characters into a buffer of your own, the you parse that buffer between delimiters (e.g. CR or LF), or in real-time o pn specific characters... then process each ‘command’ as it is pulled out of the buffer.

This can often be optimised using char* pointers and a sliding buffer that becomes essentially ‘endless’, able to receive new characters forever.

@GolumMostafa’s diagram is useful to understand what’s in the chip’s datasheet, but is no help to parsing a sequence of buffered commands.
In fact continuously de-queueing and parsing multiple serial messages is a relatively complex process for a beginner.
Also consider what you will do with too many characters, incomplete messages, timeout etc.