Hi Richard! When I don’t disable “Global type checking” in the TASKING compiler I do get
the following errors when building:

E163: ["..FreeRTOS_Sourcequeue.c" 1171/24] "uxQueueMessagesWaiting" redeclared with a different type
I459: ["..FreeRTOS_Sourceinclude/queue.h" 796/24] previous declaration of "uxQueueMessagesWaiting"
E163: ["..FreeRTOS_Sourcequeue.c" 1614/7] "vQueueAddToRegistry" redeclared with a different type
I459: ["..FreeRTOS_Sourceinclude/queue.h" 1283/7] previous declaration of "vQueueAddToRegistry"
E163: ["..FreeRTOS_Sourceinclude/queue.h" 1293/6] "vQueueWaitForMessageRestricted" redeclared with a different type
I459: ["..FreeRTOS_Sourcequeue.c" 1660/7] previous declaration of "vQueueWaitForMessageRestricted"
E163: ["..FreeRTOS_Sourcequeue.c" 555/15] "xQueueCreateCountingSemaphore" redeclared with a different type
I459: ["..FreeRTOS_Sourceinclude/queue.h" 1244/14] previous declaration of "xQueueCreateCountingSemaphore"
E163: ["..FreeRTOS_Sourcequeue.c" 324/14] "xQueueGenericCreate" redeclared with a different type
I459: ["..FreeRTOS_Sourceinclude/queue.h" 1290/14] previous declaration of "xQueueGenericCreate"
E163: ["..FreeRTOS_Sourceinclude/queue.h" 1103/22] "xQueueGenericSendFromISR" redeclared with a different type
I459: ["..FreeRTOS_Sourcequeue.c" 906/22] previous declaration of "xQueueGenericSendFromISR"
E163: ["..FreeRTOS_Sourcequeue.c" 466/16] "xQueueGiveMutexRecursive" redeclared with a different type
I459: ["..FreeRTOS_Sourceinclude/queue.h" 1252/15] previous declaration of "xQueueGiveMutexRecursive"

To treat the following error

E163: ["..FreeRTOS_Sourceportable....port.c" 102/35] "pxCurrentTCB" redeclared with a different type
I459: ["..FreeRTOS_Sourcetasks.c" 111/35] previous declaration of "pxCurrentTCB"

I’ve already submitted a patch. Now to the problems in queue.c: I think in queue.c, e.g., the “typedef xQUEUE * xQueueHandle;” should be
renamed “typedef xQUEUE * xKernelQueueHandle;”. Then queue.c can safely include queue.h and the queue handle can then be
treated as follows, using uxQueueMessagesWaiting( ) as example:

unsigned portBASE_TYPE uxQueueMessagesWaiting( const xQueueHandle pxQueue )
{
unsigned portBASE_TYPE uxReturn;
    configASSERT( pxQueue );
    taskENTER_CRITICAL();
        uxReturn = ((xKernelQueueHandle *)pxQueue)->uxMessagesWaiting;
    taskEXIT_CRITICAL();
    return uxReturn;
}

And functions returning a queue handle should be treated as follows:

xKernelQueueHandle xReturn = NULL;
....
    return (xQueueHandle)xReturn;

What do you think? Regards
Friedl

With regards to the TCB patch, that’s a no go I’m afraid.  I have updated the patch with the reason.  Not to say that a solution that avoids the warnings could not be used. Regards your queue suggestion. I was just looking at how this is done now.  The other alternative would be to just use (xQUEUE *) directly in the queue.c file without the additional typedef.  Either way, having the ability to include queue.h in queue.c would definitely be a bonus so there is definitely merit.  I am currently contemplating this one… Regards.

Hi Richard!

richardbarry
With regards to the TCB patch, that’s a no go I’m afraid. I have
updated the patch with the reason. Not to say that a solution that
avoids the warnings could not be used.

Did your really look at the patch? The definition of TCB is
“protected” by the definition of TASK_INCLUDED_FROM_KERNEL_FILE? See a text version of the patch for viewing in the browser: patch-TCB.patch.txt And of course supported ports would only be allowed to de-reference
the stackpointers which are referenced in the TCB. It’s up to you
to allow only such ports. And per default the definition of the TCB
is not available in the portlayer if TASK_INCLUDED_FROM_KERNEL_FILE
is not defined in port.c. BTW I’m referening to stackpointers – plural – because I’m currently
working on a dual stack port with the addional stack added to the
TCB and using the generalised stack checking functions. Regards
Friedl

I only looked at the patch in a text file and didn’t notice that.  I will look again, but it probably won’t be for a few hours yet as I want to ensure the code I have now is checked in first. Regards.

I have updated queue.c to make it consistent with task.c.  Now the handle is void* everywhere, queue.h is included in queue.c and local xQUEUE * pointers are used in the API functions as necessary (as tskTCB * pointers are in the task API functions).  Task.c used to use the same scheme as queue.c (two different task handle definitions) but was evidently updated without queue following on.  Agreed it is much better like this. Please grab the latest from SVN and make sure it is ok for your compiler. Regards.

Dear Richard! I’ll have to dissect your commit first to be able to reapply it onto my
currently not mainline code. If I am allowed to make a wish please create one commit for everything
that is related and another one for which is not. E.g., for every line in your last log message:

Added more files to the Rowley and IAR LM3S demos to test building the newer files and queue sets.
Made queue function prototypes consistent so xQueueHandle parameters are always xQueue, and xQUEUE * parameters pxQueue.
Likewise make the task API using px for pointers to TCBs, and just x for task handles.
Heap_x functions now automatically align the start of the heap without using the portDOUBLE union member.
Queue.c now includes queue.h.

It would be much easier to see which changes relate to the line saying
“Queue.c now includes queue.h.”, if the related changes would have been
one commit and the other lines a commit of their own. I know old habits die hard, but please at least consider it. It might make life
at little easier for distributed development. Thanks for your time and your support. Best regards
Friedl

Regarding changes to queue.c and queue.h, I can say job well done, all type checking errors are gone.