FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [February 2013 Threads] Global type checking errorsPosted by Friedrich Lobenstock on February 11, 2013 Hi Richard! When I don't disable "Global type checking" in the TASKING compiler I do get the following errors when building: E163: ["..\FreeRTOS_Source\queue.c" 1171/24] "uxQueueMessagesWaiting" redeclared with a different type I459: ["..\FreeRTOS_Source\include/queue.h" 796/24] previous declaration of "uxQueueMessagesWaiting"
E163: ["..\FreeRTOS_Source\queue.c" 1614/7] "vQueueAddToRegistry" redeclared with a different type I459: ["..\FreeRTOS_Source\include/queue.h" 1283/7] previous declaration of "vQueueAddToRegistry"
E163: ["..\FreeRTOS_Source\include/queue.h" 1293/6] "vQueueWaitForMessageRestricted" redeclared with a different type I459: ["..\FreeRTOS_Source\queue.c" 1660/7] previous declaration of "vQueueWaitForMessageRestricted"
E163: ["..\FreeRTOS_Source\queue.c" 555/15] "xQueueCreateCountingSemaphore" redeclared with a different type I459: ["..\FreeRTOS_Source\include/queue.h" 1244/14] previous declaration of "xQueueCreateCountingSemaphore"
E163: ["..\FreeRTOS_Source\queue.c" 324/14] "xQueueGenericCreate" redeclared with a different type I459: ["..\FreeRTOS_Source\include/queue.h" 1290/14] previous declaration of "xQueueGenericCreate"
E163: ["..\FreeRTOS_Source\include/queue.h" 1103/22] "xQueueGenericSendFromISR" redeclared with a different type I459: ["..\FreeRTOS_Source\queue.c" 906/22] previous declaration of "xQueueGenericSendFromISR"
E163: ["..\FreeRTOS_Source\queue.c" 466/16] "xQueueGiveMutexRecursive" redeclared with a different type I459: ["..\FreeRTOS_Source\include/queue.h" 1252/15] previous declaration of "xQueueGiveMutexRecursive"
To treat the following error E163: ["..\FreeRTOS_Source\portable\....\port.c" 102/35] "pxCurrentTCB" redeclared with a different type I459: ["..\FreeRTOS_Source\tasks.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
RE: Global type checking errorsPosted by Richard on February 11, 2013 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.
RE: Global type checking errorsPosted by Friedrich Lobenstock on February 11, 2013 Hi Richard! “ 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
RE: Global type checking errorsPosted by Richard on February 12, 2013 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.
RE: Global type checking errorsPosted by Richard on February 12, 2013 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.
RE: Global type checking errorsPosted by Friedrich Lobenstock on February 12, 2013 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
RE: Global type checking errorsPosted by Friedrich Lobenstock on February 13, 2013 Regarding changes to queue.c and queue.h, I can say job well done, all type checking errors are gone.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|