Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Loading

Please discuss a change in queue.c

Posted by Nobody/Anonymous on February 14, 2005
Hi everybody,

I'm preparing a port to the C167 microcontroller (Infineon) to be published here. Now I encountered the following problem with the Keil IDE.

As I use the EC++ - Compiler supplied in the actual version of Keil's IDE there's a problem in queue.c. The line
<code>
typedef xQUEUE * xQueueHandle;
</code>
makes a different definition as given in queue.h
<code>
typedef void * xQueueHandle;
</code>

This is used to hide the xQUEUE-structure from the user. So far so good. The EC++ - Compiler now tries to find a overloaded function with the queue.h - definition. In queue.c there's only xQUEUE definition. A linker-error (unresolved symbol) is the result.

My suggestion : Let's change the definition of xQueueHandle in queue.c to void * too. When one does this, almost any occurence of the variable "pxQueue" in queue.c has to be changed to "((xQUEUE *)pxQueue)".

I did this and it solved all problems with queue.c and queue.h. Please discuss this suggestion. I offer you my version of the v2.6.0 queue.c with this changes (~50 items to change !).

Thanks, Daniel Braun
eMail : Guru79@web.de

RE: Please discuss a change in queue.c

Posted by Nobody/Anonymous on February 14, 2005
I presume this is a problem because you are using a C++ compiler rather than a C compiler.

Is it possible to designate the source files as C files with

extern "C"
{
}

around all the code in the file? Alternatively is there a way from the project file to request that these particular files should be compiled as C files?

RE: Please discuss a change in queue.c

Posted by Richard on February 14, 2005
I am not surprised this is a problem with a C++ compiler. In fact, I am surprised that none of the C compiler used have complained so far.

Do you find the same problem with the pxCurrentTCB variable? This is defined both as tskTCB* and void* within the tasks.c and port.c files respectively.

As you say, this will require a lot of changes and probably effects the semaphore macros also. There are two issues:

1) Readability. There is a lot of casting already. This is necessitated by the number of compilers used - each likes things slightly different. More casting will reduce readability, BUT a #define could be used to prevent this. eg

#define QUEUE ( ( xQUEUE *)pxQueue)

then just replace the pxQueue's within the function bodies with QUEUE.

2) As just mentioned, each compiler likes things a little differently. I would have to make sure that any changes are accepted by all the compilers.


Can the compiler be made to compiler files with a .c extension as C files, rather than C++?

Regards.


RE: Please discuss a change in queue.c

Posted by Nobody/Anonymous on February 14, 2005
Hi again,

1. if all C-functions defined so far have to be declared as extern C {..} one has to change the header queue.h (and others)

2. my proposal for casting should not affect other compilers - it should be possible to compile it with any C/C++ - Compiler.

3. I think Richard's method (1) can enhance readability to a level comparable to today's code.

4. I have now tested the modified queue.c (with standard queue.h) and found no problems.

Do you want the code to test it - where should I send it to ?

Regards, Daniel.

RE: Please discuss a change in queue.c

Posted by Richard on February 14, 2005
Hi Daniel,

Can you send it to the email address listed on the FreeRTOS.org site "contacts" page. I will check it out with the other compilers.

Thanks.


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


Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


Careers

FreeRTOS and other embedded software careers at AWS.



FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Renesas

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

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

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner