Handling a queue with arrays?

Hi guys,

for my project my main program will send different events to my Network Class. In that class i will transmit the data through another arduino to my computer. The communication works fine. But how should i handle my queue?

For example:

struct terra_request {
	byte transmitId;
	bool sent;
	char data[128];
};

terra_request myQueue[20];

But now i would need to always check for free spaces. I thought about initializing the array with zero and reset it to zero again if i delete an struct entry.

Is there somthing like List or Dictionary in C#?

Or how you guys handle something like that?

Greetings
Raphael

you could have a start and end index indicating if something is on queue (start != end) and the position of msg to send (start)

What type of "Arduino" Board?
20 * 128 = 2560 bytes just for your FIFO.

If the behavior is strictly first-in, first-out, then an array is fine. Just use sequential items in the array, and keep track of where the first one is, and either the last one or the number of items. Or, simple add an "active" flag to each item. If it is not strictly first-in, first-out, then a linked list would likely make book-keeping easier, as it allows the list to be re-ordered whenever needed.

Yea, READ and WRITE pointers into the struct array are all you need. You do need to manage them carefully since the condition READ == WRITE can mean either FIFO Full or FIFO Empty.

Also, if you make the FIFO size a power of 2, the pointer adjustment for wrap-around is an easy bitwise AND operation. Otherwise you need a comparison.

Ok i will do it by the start!=end logic. And I use an due so the memory is no problem.
And i need it because i want to cache some data if the network is shortly not available.

Ty guys

why the struct with a 128 byte data array? couldn't it simply be a much larger byte array without the transmit ID which it presumably part of the header of a msg and there should be no need for the "sent" flag. wouldn't such an approach use memory more efficiently?

the same start/end indices can be to track the position of the next msg. the first byte of the msg could be the size in the buffer that need not be sent.