having queue problem in 5.0.0

richpainter wrote on Sunday, 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_MUTEXES    1
#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?


davedoors wrote on Sunday, 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.

vinay1 wrote on Monday, 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


saiberion wrote on Monday, 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.

richpainter wrote on Monday, 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…


vinay1 wrote on Tuesday, 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. */

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

after this you would have access to the queue structure.

I hope this helps.