Sharing a linked list

[v8dave]

Hi all,

I have an application with a number of tasks and 1 of the tasks is setup to handle the touch screen and dislay the graphics. One of the other tasks handles a wireless communications link.

The wireless task simply sends out requests to another device that sends back resonses. The task has a simple state machine that is used to keep track of what commands are being sent. When idle and no queued messages to send, it simply sends sensor data to the remote.

This wireless task also needs to send out different requests based on what the user has done via the touch screen so I have setup a linked list that gets populated with the commands and I need a way for the wireless task to check this linked list to see if it is ready to process new commands and once processed, it simply deletes this entry from the list.

The list not going to be big and probably no more than about 10-20 commands at any one time (one input on the touch screen generates 10 or more commands to request job data from the remote).

I had thought about a fixed array for this but this means I need to know the max commands at any one time.

The question I have regardless of what method I use for the list, is how to pass this information between tasks. The wireless task has to loop endlessly so there can be no pending for flags etc. I am looking at FIFO and QUEUE as 2 of the options and wondering if anyone has recommendations for the best way to handle this across tasks and which of these is the ideal way forward?

Thanks
Dave...

[Ridgeglider]

V8: On 1st blush, I'd go for the FIFO. When you post to it, you can copy a struct into the passed data very easily. That struct is a pretty flexible place to retain info and it's a copy of the original so the posting task can continue to alter the data moving forward. That said, in most of my apps, the data I pass via the fifo tends to be a consistent type of struct post to post. That got me thinking that you might prefere the queues. I have not used them too much but the pointer they pass could also clearly point to any data you want to access, and do it with perhaps with less overhead and more flexibility. More flexibility because the pointer could point to objects of different type each time, as long as you build a way to deteremine what's being pointed to. This might allow more flexibility in respondoing to different menus: MenuA means pass ptr to StructA, MenuB means pass ptr to StructB where perhaps the 1st item in all structs tells you what type it is. That pointer should probably also point to a snapshot of the calling task's data, not the original data. When you copy the original data, and when the OSQueue or Fifo accesses the data, remember that you will have to lock it if it's non-atomic. One reason to use the fifo is that it makes a copy of your data so if the source data is changing, it gets captured as soon as you post to the fifo. Just off the top of my head...

[tod]

Dave,
My initial reaction is to not copy such a list at all. Does the wireless task need to manage the touchscreen class? Can you just let the touchscreen class send out the data itself (it can call a public method on the wireless task to get the tcp socket). Just thinking out loud.


Tod

[Ridgeglider]

I agree with Tod 100% if all that's needed is to tranmit the info off the NB. However V8's last paragraph suggested a need to communicate between tasks on the NB, hence fifos or queues sound like they might be appropriate. That said, Tod's got this stuff pretty wired and i'd think carefully before ignoring his advice!

[v8dave]

Hi Tod and RG,

The wireless task is actual over a UART to a SIM20 module so there is no TCP. The display task is running much slower processing the touchscreen and the dispay update so I have this wireless task running on it's own handling that part of the system. All it has to do is send out the required commands to the remote. I don't pass anything to it other than what commands to send, basically a number from 1-20 as it handles the message packeting and reception into protected structures.

I have looked at the FIFO and QUEUE and I think that the queue is the best option as it receives a pointer to the linked list entry. After it processes the entry, it marks it as processed. This changing of the entry is handled with a semaphore to avoid the display task updating at the same time (it navigates down the list to find the end when it adds a new record and needs to know where the head is) The display task will then delete any marked entries when it comes to adding a new entry to the list.

I think this is the safest option or I could simply pass a pointer to the list into this task on creation and simply use a semaphore to access it?

Dave...

[v8dave]

Just a quick update.

I went with a semaphore for accessing the linked list. Because of the way the system works and the main task only needing to add to the list on user input, the speed was not important so I just set the semaphore when I want to add or read from the list.

So far it has been working faultlessly and memory management seems to be working fine. As this system is powered up and down as the client uses it during the day, this is not going to be such an issue anyway. It is not designed to run continuously.

Cheers for all your input.

Dave...