Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

Queue Behaviour that I Don't Quite Follow...?

Posted by groger57 on July 14, 2016

Hello:

I've created a queue send and receive function near-identical as per the example in the newest FreeRTOS guide, from page 157.

The only difference being that I have a structure defined and that's what I am passing in. The structure is 34 bytes, and I havea queue size of 5. When I send a structure pointer to xQueueSendToBack, the function xQueueReceive gets the pointer and structure correctly, as the debugger shows the contents.

Also in the program, I have a function I use to send data out the UART. After formatting a string, I call the function: USART_GetResponseStr( scrnBfr ); From the task that performs xQueueSendToBack, I can call this function with a formatted string and the function performs as expected, I get a graphic item on the target screen. However, when I use the same function call from xQueueReceive, (upon pdPASS TRUE) the function appears to break, and nothing gets to the screen.

uint16t USARTGetResponseStr( char *s ) { uint16_t getData = 0x0;

//send string out
OutString( s );

while(1) // poll response
{
    getData = USART_FetchChar();    
     if( getData == 0x3E )
    {
        //one more for 0xD
        getData = USART_FetchChar();    
         break;
    }      
 }

return getData;

}

By printing out the formatting string in xQueueReceive, it's identical to the same call in the task xQueueSendToBack. Can someone please provide some insight as to why this might happen? The only thing I could think of is the task size, it's set at 200. Adjusting it up made no differnce.

Thanks for any help you can provide! Gary


Queue Behaviour that I Don't Quite Follow...?

Posted by rtel on July 14, 2016

The code you posted doesn't show your use of the queue, but some notes:

1) Which architecture are you using? (which chip?)

2) Do you have stack overflow checking switch on? (configCHECKFORSTACK_OVERFLOW set to 2?) http://www.freertos.org/Stacks-and-stack-overflow-checking.html

3) Do you have configASSERT defined? http://www.freertos.org/a00110.html#configASSERT


Queue Behaviour that I Don't Quite Follow...?

Posted by groger57 on July 14, 2016

Hi, Sorry for not providing that info. Also, using FreeRTOS 8.2.0

1 - The target is an STM32F4 (cortex M4) 2 - configCHECKFORSTACK_OVERFLOW is set to 2 3 - It is defined. in FreeRTOSConfig.h

As mentioned, my use of the queue, if I understand correctly, is the same as the example in the manual, with the exception of the structure. I can post it here if needed.

What might I try next to debug it....a bit lost.. thanks.

Gary


Queue Behaviour that I Don't Quite Follow...?

Posted by groger57 on July 14, 2016

Hi,

For clarity, I am posting the queue related code here:

.#define QUEUE_LENGTH 3

//pxMessage has been malloc'd before here... uint16t QUEUEITEM_SIZE = sizeof( *pxMessage ); // == 34 bytes

static void prvTimeStampFunction( void *pvParameters ); static void QueueTxScreenFunction( void *pvParameters );

main() { QueueHandle_t xQueue;

xQueue = xQueueCreate( QUEUE_LENGTH, QUEUE_ITEM_SIZE );
xTaskCreate(QueueTxScreenFunction, "Tisk", 120, (void*)xQueue, 2, NULL);    

/* Create time stamp task. queue receive and process */
xTaskCreate( prvTimeStampFunction, "Task", 200, (void*)xQueue, 2, NULL );                

vTaskStartScheduler();             

while(1)
{
}    

}

static void prvTimeStampFunction( void *pvParameters ) { QueueHandlet xQueue; TickTypet xLastCheckTime = xTaskGetTickCount();

xQueue = (QueueHandle_t) pvParameters;    

for(;;)
{
    vTaskDelayUntil( &xLastCheckTime, 1000 );
    secCtr++;

        if( 0 == secCtr%5 )
        {
            //battlink1 is a malloc'd heap instance of the structure
            battLink1->currState = LED_RED;
            xQueueSendToBack( xQueue, battLink1, 10);
        }
}

}

void QueueTxScreenFunction( void *pvParameters ) { QueueHandlet xQueue = (QueueHandlet) pvParameters; sOBJ *pxMessage;

  for(;;)
{
    if( xQueueReceive  ( xQueue, pxMessage, portMAX_DELAY) == pdPASS)
    {
        sprintf(scrnBfr, "xi %i %i %i\r", pxMessage->currState, pxMessage->xLoc, pxMessage->yLoc);
        printf("got message, here's what queue is sending: %s\n", scrnBfr  );
        /* DOES NOT EXECUTE THIS */
        USART_GetResponseStr( scrnBfr);
    }
    else
    {
        //whatever else there is to do when something breaks...
    }    
} 

}


Queue Behaviour that I Don't Quite Follow...?

Posted by davedoors on July 15, 2016

The second parameter to xQueueReceive needs to be a pointer to a buffer that is at least 34 bytes big. You are passing an sOBJ variable. What is sOBJ? If it is a pointer it needs to point somewhere, if it is not a pointer then you need to pass &pxMessage to xQueueReceive.


Queue Behaviour that I Don't Quite Follow...?

Posted by groger57 on July 18, 2016

It is a pointer. sOBJ is a structure, and I MALLOC from the heap, like this: battLink1 = malloc( sizeof(sOBJ) ); What comes back after mallloc is a pointer, so why would you want to pass it by reference with an "&" ? In my code, I simple created pxMessage as an allocated instance of sOBJ. So is there a problem with that? According to documentation, I don't see one.

In any case,I have found out what the problem is. After breakpointing the code and stepping into it, I put a printf on the return data in the call to the UART send. After doing that, it started to work. Something bizzare with timing going on when using this perfectly good working function. Insteadf of printf'g something, I just used a junk buffer of 2 byes and sprintf'd a hex char into it. It seems to waste enough time to allow the function to work.

If I don't use FreeRTOS to pass around structure pointers as in this case of Queues, that code works perfectly fine and has for a few weeks.

Any suggestion as to why using a queue might cause the call to the UART send to behave this way? As below...

uint16t USARTGetResponseStr( char *s ) { uint16_t getData = 0x0; char junk[2];

//send string out
OutString( s );

while(1) // poll response
{
    getData = USART_FetchChar();    

** //must put this here, otherwise does not work with FreeRTOS //can be any value, as long as printf or sprintf is executed** sprintf(junk, "%x", 0xF);

    if( getData == 0x3E )
    {
        //one more for 0xD
        getData = USART_FetchChar();    
        break;
    }      
}

return getData;

}


Queue Behaviour that I Don't Quite Follow...?

Posted by davedoors on July 18, 2016

Does USART_FetchChar() just read a register, or do anything else as well? If it disables interrupts and you call it rapidly in a loop I suppose it could be an issue.


Queue Behaviour that I Don't Quite Follow...?

Posted by groger57 on July 18, 2016

More info.... I changed the call to the queue from this: xQueueSendToBack( xQueue, pxMessage, 10);

To this: xQueueSendToBack( xQueue, TempMTR, portMAX_DELAY);

And added this after each call to xQueueSendToBack: vTaskDelay(10);

And removed the sprintf in the UART function, it's clear a delay was needed and that's all it was doing.

Question is, why do I need a delay when the call to xQueueSendToBack uses "portMAX_DELAY" ? Doesn't that imply it will block until the message is popped from the queue?

Thanks again, Gary


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists