Quality RTOS & Embedded Software

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


signedness compiler warnings (WinAVR)

Posted by JMR on June 16, 2008

I like the new interface for the sendFromISR functions it makes it possible to figure out if a queue is full or not (always useful if you're trying not to loose data :) )
When migrating my project to the latest and greatest I noticed a compiler warning (it's trivial but if no one tells you how will you know about it?)

In the documentation for the new type interface of the *sendFromISR functions you show the 3rd parameter to be portBASE_TYPE however gcc complains about pointer signedness difference for these functions. This is normal as the function prototypes are specified with signed portBASE_TYPE. To eliminate the warning the programmer simply needs to specify the variable he's used for the third parameter as a signed portBASE_TYPE...

Either is fine as far as I'm concerned maybe a quick fix-up of either would avoid others the same wonderment...

What's the reason for the specific signed portBASE_TYPE argument? Is it really useful to have it as signed? Just a thought...


RE: signedness compiler warnings (WinAVR)

Posted by Richard on June 16, 2008
The signed/unsigned qualifier is a portability issue when using 8 bit devices - some of which will have chars signed by default, and others unsigned. Its a pain. I think this actually changed between WinAVR versions. Are you using the latest version, or an older version?

If you are using a 16 or 32bit device then the base type is always signed by default, so the extra qualifiers are there just to keep the 8bit compilers happy - not doing a good job in this case!


RE: signedness compiler warnings (WinAVR)

Posted by JMR on June 17, 2008
I'm using the 20071227 version I haven't updated to the June of this year one yet and not sure if I will as there are no improvements/fixes for my platform (ATMega640).

My thinking about the signed/unsigned on 8bit platforms is that since it varies from compiler to compiler why not just let the compiler do its job. In the majority of cases we don't care whether a char is signed or unsigned. Since you define a new data type portBASE_TYPE then why not make that a signed char or unsigned char?

Now this is a minor point, and an easily "fixed" one for the user, but I think that this would improve newcomers' first impressions of FreeRTOS. Me? I'm a convert :) I really do like the RTOS and it's simplicity. Yes there are areas that could do with improving but hey so are on my car, house, job, life in general :)
Keep up the great work... I'll be there to check the AVR Mega side of things.

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

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

Latest News

FreeRTOS v10.2.0 is available for immediate download. MIT licensed, and including RISC-V and ARMv8-M (Cortex-M33) demos.

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

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


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Cadence Tensilica Cortes

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers





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