Queing a Message From Within a Queue Handler (not functioning)

Kernel
1

groger57 wrote on Monday, July 18, 2016:

Hi,

I have a touch screen handler application. I want 2 queues to handle both incoming messages for screen touches, and a queue handler for outgoing messages back to the screen.

Separately, they both function with no problem. The queue for updating the screen can take messages using
xQueueSendToBack, and it updates the screen OK.
The queue for receiving messages works OK and receives messages from the screen. Right now, it just enumerates the message from the screen using the receive value. It’s set up like this:

void QueueProcessScreenCmds( void *pvParameters )
{
static uint8_t rxValue = 0;
BaseType_t xStatus;

QueueHandle_t xQueue = (QueueHandle_t) pvParameters;

  for(;;)
  { 
    xStatus = xQueueReceive( screenProcessQueue, &rxValue, rxQueue_RATE );                
    
    if( xStatus == pdPASS )
    {
        if( rxValue == THIS )
        {
        //do something with this
        }
    }
}

The problem is this - if I want to use the queue to “send” an update to the screen, it breaks. For example, if I want to send something to the queue in the "if rxValue == " condition, like this:
xQueueSendToBack(xQueue, PR2, portMAX_DELAY );

It does not work. However, I can use that same call from a “regular” task I have created and it will function OK there.
What would be the reason I cannot send to the other queue from that task function? Or is there just a better way to do this?

Thanks,
Gary

2

groger57 wrote on Tuesday, July 19, 2016:

Hi !
Can anyone give me some help on this, or is there another website I can post this kind of a question if it’s not “appropriate” here?

3

rtel wrote on Tuesday, July 19, 2016:

It does not work

First, you really need to be more specific, as everybody reading this is left guessing what “does not work” means. It could mean:

  • The queue send function returns without posting to the queue.
  • The queue send function never returns.
  • There is a hard fault.
  • There is some other kind of crash.
  • The tick interrupt stops.
  • The task stops running, but other tasks still run.
  • You get stuck in a loop somewhere.
  • etc.

Second, possible answers will no doubt be dependent on the architecture you are using:

So for now, all that can be done is to provide a generic answer, like - do you have stack overflow detection turned on, do you have configASSERT() defined, etc. Links to such items being available from the following page: FreeRTOS - Open Source RTOS Kernel for small embedded systems

4

groger57 wrote on Tuesday, July 19, 2016:

Thanks…got it. An example of sending to “Queue B” while executing in “Queue A” would be nice to find, which is essentially what I am trying to do. Should be easy enough, but…
I’ll try setting up configASSERT with disbled interrupts macro and see where it breaks. Using that macro, is the only way to get it to stop on the configASSERT by putting a breakpoint there?

5

edwards3 wrote on Tuesday, July 19, 2016:

An example of sending to “Queue B” while executing in “Queue A” would be nice to find

I dont understand your question. You can not execute in a queue, you execute in a task. Tasks can use any number of queues.

6

groger57 wrote on Tuesday, July 19, 2016:

Thank you for taking the time to help me out.

A bit of silliness on my part indeed. After looking at the code it was doomed to failure from the first byte. (choke at first byte…)
I gave further thought to the process and it makes more sense to have a single task that runs every “x” milliseconds and checks for incoming messages at the UART. From there, it will dispatch the message to a processing queue for screen updates - in the order it was received as I’m using a single queue item. From there I could send to multiple queues if necessary.