Is it possible to Receive Queue (xQueueReceive) inside periodic task


I am supposed to Receive can massages through interrupt and then send the msg to other task using queue :

xCanRxQueue = xQueueCreate(10, sizeof(can_frame_struct));

xQueueSendFromISR(xCanRxQueue, (void *)&can_rx_frame, (TickType_t)0);

But I do not want to trigger the task contains xQueueReceive () immediately(Event based task), but instead i want to make a periodic task that check the queue every specific period of time :

So for example if I made something like that:

    TickType_t xLastWakeTime;
    const TickType_t xPeriod = pdMS_TO_TICKS(_25_MS_);
    xLastWakeTime = xTaskGetTickCount();

    for (;;)
         while ( xQueueReceive(xCanRxQueue,  &can_frame, 0) != errQUEUE_EMPTY)
                 // Read data that can_frame points to 
        vTaskDelayUntil(&xLastWakeTime, xPeriod);

will that be correct , or is there any better ways to handle Queues in periodic tasks ?


That is perfectly fine. You could also peek the queue or use a timeouting receive.

Edit: Using vTaskDelayUntil instead of vTaskDelay bears the risk that if your processing of the message takes longer than your configured delay, that task may starve lower pri tasks when lots of messages arrive.

Many thanks for your feedback.

So you mean that when using vTaskDelayUntil and if the time needed to process the data is almost the same as the delay, task will block other low prio tasks ? right?

I am only using vTaskDelayUntil because i want to have periodic tasks that comes within fixed range, means if i have 25 ms task i want it to always have same gap between task calls (25ms).

But in case of, vTaskDelay , if a task delayed for some time, so the vTaskDelay will add a new delay (ex: if task delayed 2 ms, next time will start at 2+25 = 27, but i want to start always after 25 ms ) . Is my assumption make sense ? or i understand that wrong ?

well, yes, I believe. vTaskDelay will always add a constant delay to the time needed for receiving and processing your message. vTaskDelayUntil wlll attempt to put a bound on the total turnaround for the entire loop. There are pros and cons to either approach, as usual.

If, however, the turnaround for receiving and processing is longer than your expected schedule time, there is nothing vTaskDelayUntil can do about it.