remon Posted June 20, 2016 Report Share Posted June 20, 2016 Hi, I'm trying to compile uGFX on a NXP Cortex M0+ microcontroller using freeRTOS, however when compiling I get the following error: Building file: ../src/gwin/gwin.c Invoking: MCU C Compiler arm-none-eabi-gcc -DDEBUG -D__CODE_RED -DCORE_M0PLUS -D__MTB_BUFFER_SIZE=256 -D__USE_ROMDIVIDE -D__USE_LPCOPEN -D__LPC11U6X__ -D__REDLIB__ -I"/home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/lpc_board_nxp_lpcxpresso_11u68/inc" -I"/home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/freertos/inc" -I"/home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/lpc_chip_11u6x/inc" -O0 -fno-common -g3 -Wall -c -fmessage-length=0 -fno-builtin -ffunction-sections -fdata-sections -mcpu=cortex-m0 -mthumb -specs=redlib.specs -MMD -MP -MF"src/gwin/gwin.d" -MT"src/gwin/gwin.o" -MT"src/gwin/gwin.d" -o "src/gwin/gwin.o" "../src/gwin/gwin.c" In file included from ../src/gwin/gwin.c:13:0: ../src/gwin/../../gfx.h:31:22: error: expected identifier before numeric constant #define FALSE 0 ^ /home/remon/Repositories/Heisenberg/firmware/heisenberg_v2/lpc_chip_11u6x/inc/lpc_types.h:50:15: note: in expansion of macro 'FALSE' typedef enum {FALSE = 0, TRUE = !FALSE} Bool; ^ make: *** [src/gwin/subdir.mk:80: src/gwin/gwin.o] Error 1 There seems to be an conflict between the FALSE define in the uGFX and the chip library, Any thoughts on how to solve this? Kind regards, Remon Link to comment Share on other sites More sharing options...
Joel Bodenmann Posted June 20, 2016 Report Share Posted June 20, 2016 This might be an issue with the inclusion order. µGFX only defines TRUE and FALSE if they haven't been defined so far. Snipped from gfx.h: /** * @brief Generic 'false' boolean constant. */ #if !defined(FALSE) || defined(__DOXYGEN__) #define FALSE 0 #endif /** * @brief Generic 'true' boolean constant. */ #if !defined(TRUE) || defined(__DOXYGEN__) #define TRUE -1 #endif You might/should include the "base system" before the uGFX stuff in your build tree. Issues like this won't happen in the future anymore. µGFX 3.0 will use prefixes for all types and definitions to avoid collisions like this. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now