What best way to pass large or unknown amounts of data between tasks

cancel
Showing results for 
Search instead for 
Did you mean: 

What best way to pass large or unknown amounts of data between tasks

Jump to solution
238 Views
DaveTonyCook
Contributor IV

Hi,

I have an application that requests data sets from a remote target via serial coms.  The data sets returned can be of any size from a few bytes to a Kbyte.  The receiving task reads in the data set one byte at a time storing the data in a 2k circular buffer. This process continues until the frame delimiter is reached. The circular buffer has wrap around detection. The read uses the MQX serial driver in interrupt mode Non-Blocking and returns 1 byte per call if there is one available.

My current solution.

The circular buffer is a 2K static array that has file scope.  I have provided a global accessor function that will return a pointer to this buffer and can be called from any task.  The buffer also has a semaphore to lock access whilst being written to or read from.

Once a requested data set has been received the receive task informs the control task that a data set frame has been received and is ready for unpacking and processing. The control task calls a function that pends on an event with a time out. When the receive task post this event the control task calls the accessor function to get a pointer to the circular buffer holding the received data.

This approach works well however being new to MQX I feel I might be missing a more elegant solution?

If using an MQX message queue which message queue would be the best to use to solve this problem?

Also, whats the best / most efficient way of dealing with unknown data set size, can you dynamically set the size of the message queue?

Thanks for your help

1 Solution
121 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi Dave:

 

I think your circular buffer solution can match your requirement, it is a great solution.

If you need to consider message passing, I think you need to consider the number of message queues used, frequency of sending messages, and the various sizes of messages used. Base on this,  I recommend you to use full feature message passing, not light weight message passing.

There are two types of message pools available to you and one is called system pools.  When a task creates a system pool, all tasks in your application have access to it and any task can allocate a message from a system pool. You can have multiple system pool provided you have a variety of buffer sizes in your system if you wish,  so you aren't consuming a large block of memory to send a short message. All the system pool are linked together automatically by mqx ,  and when the task uses the _msg_alloc_system call, you returns a pointer to the minimum message buffer size that it needs, mqx will start with the smallest  buffer sized pool and  allocate a buffer from the first pool whose buffer is large enough. This is called allocation on the best fit basis which means you are not allocating a larger buffer to send a small message.

The other message pool is private pool,  it is not linked together

I recommend you use system memory pool

We have demo the following folder, but this demo is based on private message pool.

C:\Freescale\Freescale_MQX_4_2\mqx\examples\msg

Compare your circular buffer solution and message passing, the later have more receive options, such as timeout, peek etc.   It depends on your requirements, there is no general rule to follow.

Regards

Daniel

View solution in original post

1 Reply
122 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi Dave:

 

I think your circular buffer solution can match your requirement, it is a great solution.

If you need to consider message passing, I think you need to consider the number of message queues used, frequency of sending messages, and the various sizes of messages used. Base on this,  I recommend you to use full feature message passing, not light weight message passing.

There are two types of message pools available to you and one is called system pools.  When a task creates a system pool, all tasks in your application have access to it and any task can allocate a message from a system pool. You can have multiple system pool provided you have a variety of buffer sizes in your system if you wish,  so you aren't consuming a large block of memory to send a short message. All the system pool are linked together automatically by mqx ,  and when the task uses the _msg_alloc_system call, you returns a pointer to the minimum message buffer size that it needs, mqx will start with the smallest  buffer sized pool and  allocate a buffer from the first pool whose buffer is large enough. This is called allocation on the best fit basis which means you are not allocating a larger buffer to send a small message.

The other message pool is private pool,  it is not linked together

I recommend you use system memory pool

We have demo the following folder, but this demo is based on private message pool.

C:\Freescale\Freescale_MQX_4_2\mqx\examples\msg

Compare your circular buffer solution and message passing, the later have more receive options, such as timeout, peek etc.   It depends on your requirements, there is no general rule to follow.

Regards

Daniel

View solution in original post