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

having queue problem in 5.0.0

Posted by Rich Painter on July 20, 2008
I am running 5.0.0, Microchip MPLAB 8.10, C30 3.10

I have 3 tasks: Task 1 is a 1 millisec period one that gathers data and places on a q, Task 2 does removes from this q with:
if(xQueueReceive(queue, &buf1p, portTICK_RATE_MS * 10) == pdTRUE {}

which effectively runs at a 10 millisec period, and Task 3 runs at a 2 second period can put on the q also with:
if(xQueueSendToFront(queue, &buf2p, 0) != pdTRUE){}

In addition, when I perform the queue send from the 2 second Task 3 I set a flag that indicates I have preformed this queuing. I also report in all uses of the sending and receiving queue API calls whether they succeed or fail.

The fast task, Task 1, even though runs at 1 ms period, it only produces and enqueues about 1 per second.

I never get any queue API failure indications. My flags indicate my entries are on the queue. Yet all of the enqueued entries done from the 2 second task never get received. New ones sent from Task 1 all appear.

Task priorities:
Task 1 = 6
Task 2 = 3
Task 3 = 2

I am using heap1.c and
#define configUSE_MUTEXES1
#define configUSE_CO_ROUTINES 0


Any ideas?

Also, in the MPLAB debugger, I examine the handle returned from the queue create and all it displays is a single hex number. I see that the handle typedef is a structure pointer, typedef xQUEUE * xQueueHandle, (I dont like this kind since it hides the fact that it is a pointer).

So, MPLAB won't show me the structure elements which I was hoping to see to prove (or not) that these entries are there.

Any suggestions on both examining this queue and why the entries are not receiving?

thanks,
rich

RE: having queue problem in 5.0.0

Posted by Dave on July 20, 2008
There are big problems with the C30 3.10 compiler. At least 3 bad bugs reported to date. Do you have the FreeRTOS work around from the Subversion repository? I dont know if it is related to your problem but you are never going to know if using that compiler version.

xQueueHandle is just that. A handle to a queue. It happens to be a pointer to a queue but this information is hidden from the user as is considered good data hiding practice.

RE: having queue problem in 5.0.0

Posted by Vinay Verma on July 21, 2008
I guess you can check out the structure elements by putting (*xQueueHandle) in the watch. Atleast in IAR workbench we can do that.

- You can (just for debugging sake) try assigning priority-8 to the task 3 for time being & check out if the problem still persists. This would ensure that Task-3 is getting enough time slice.

- There is also a possiblility of the Q getting full at the time when Task-3 fills it (this can be checked by debugging the "xQueueSendToFront" API when executed from the task-3).

I hope this helps you

Vinay

RE: having queue problem in 5.0.0

Posted by saiberion on July 21, 2008
As already suggested it might be a problem with the queue being full.
How big is your queue? From your explanation I would suggest to size it for at least 11 objects (to be safe maybe 15).
Also think about the timing. For me it seems the queue is filled faster than being emptied.

Btw: Task 2 does not run at 10 ms period. It will wait a maximum time of 10 ms on the queue if it is empty. As long the queue contains elements the receive function returns immediately.

RE: having queue problem in 5.0.0

Posted by Rich Painter on July 21, 2008
Thanks to all thus far...

Yes it is true the 10ms in the xQueueReceive() does not fix the period but that is controlled after the xQueueReceive() returns with an entry (or without).

The active queue entries always stay below 5 or 6. The queue is sized at 400 so this is not the problem.

Also, unless it is busted, since I'm checking the return value of ALL queue operations I will detect that an entry did not go on or come off.

Lastly, I had already tried casting the handle in the MPLAB watch and it didn't do anything. It seemed that the MPLAB choked on interpreting the cast.

So I'm still in the dark...

thanks,
rich

RE: having queue problem in 5.0.0

Posted by Vinay Verma on July 22, 2008
Hi Rich,

Problem is with the queue handle definition. The actual queue handle definition (i.e in queue.c) is private, not public (as in queue.h "typedef void * xQueueHandle;". The public definition is just a void pointer (as defined in the queue.h). So, if you want to check check it as a structure, first temporarily make the actual definition visible to your code. Define in your .c file, the following and include list.h:

typedef struct QueueDefinition
{
signed portCHAR *pcHead;/*< Points to the beginning of the queue storage area. */
signed portCHAR *pcTail;/*< Points to the byte at the end of the queue storage area. Once more byte is allocated than necessary to store the queue items, this is used as a marker. */

signed portCHAR *pcWriteTo;/*< Points to the free next place in the storage area. */
signed portCHAR *pcReadFrom;/*< Points to the last place that a queued item was read from. */

xList xTasksWaitingToSend;/*< List of tasks that are blocked waiting to post onto this queue. Stored in priority order. */
xList xTasksWaitingToReceive;/*< List of tasks that are blocked waiting to read from this queue. Stored in priority order. */

unsigned portBASE_TYPE uxMessagesWaiting;/*< The number of items currently in the queue. */
unsigned portBASE_TYPE uxLength;/*< The length of the queue defined as the number of items it will hold, not the number of bytes. */
unsigned portBASE_TYPE uxItemSize;/*< The size of each items that the queue will hold. */

signed portBASE_TYPE xRxLock;/*< Stores the number of items received from the queue (removed from the queue) while the queue was locked. Set to queueUNLOCKED when the queue is not locked. */
signed portBASE_TYPE xTxLock;/*< Stores the number of items transmitted to the queue (added to the queue) while the queue was locked. Set to queueUNLOCKED when the queue is not locked. */
} xQUEUE;

typedef xQUEUE * xQueueHandle; (The public definition is: typedef void * xQueueHandle;)


after this you would have access to the queue structure.

I hope this helps.

vinay


[ 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