带类型转换的宏在C预处理器条件判断中编译失败的原因及解决方法

Let's break down why your code is throwing errors, then look at cleaner alternatives beyond the one you already found.

The Root Cause: Preprocessor Doesn't Understand C Types #

The C preprocessor runs before the compiler, and it only knows how to handle integer constant expressions—it has zero understanding of C type syntax like (double)1 or (uint8_t*)0x004000000.

When you write:

#define v1 (double)1
#define VAL (v1)
#if VAL == v1

The preprocessor expands this to:

#if (double)1 == (double)1

It sees (double) as an unknown token, not a type cast. Since it expects a binary operator (like +, -, or ==) between valid integer constants, it throws the "missing binary operator" error you saw.

The same problem hits your UART code: UART1 is a pointer type cast, which the preprocessor can't parse in a #if condition.

Solutions to Fix Your HAL Macro Setup #

1. Use Integer IDs for UART Selection (Clean and Scalable) #

Instead of comparing pointer addresses directly, assign unique integer IDs to each UART, then compare those IDs in the preprocessor. This keeps your type-safe UART definitions intact while letting the preprocessor do its job:

// Step 1: Define unique integer IDs for each UART
#define UART_ID_1 1
#define UART_ID_2 2

// Step 2: Select your target UART using its ID
#define SELECTED_UART UART_ID_1

// Step 3: Map the ID to your actual UART address and pin
#if SELECTED_UART == UART_ID_1
    #define UART ((uint8_t*)0x004000000)
    #define PIN_TX 9
#elif SELECTED_UART == UART_ID_2
    #define UART ((uint8_t*)0x004000008)
    #define PIN_TX 2
#else
    #warning "UART not correctly defined"
#endif

This works because the preprocessor can easily compare integers, and your final UART macro still gets the type-cast address you need for runtime code.

2. Your Existing "USE_UARTX" Switch (Worth Keeping!) #

The solution you already found—using #define USE_UART1 as a toggle—is actually one of the most readable approaches for embedded HAL code. While it adds an extra macro, it's explicit: anyone reading the code can immediately see which UART is enabled. You can even make it cleaner with helper macros if you have many UARTs:

// Enable one UART here
#define USE_UART1
// #define USE_UART2

#if defined(USE_UART1)
    #define UART ((uint8_t*)0x004000000)
    #define PIN_TX 9
#elif defined(USE_UART2)
    #define UART ((uint8_t*)0x004000008)
    #define PIN_TX 2
#else
    #warning "UART not correctly defined"
#endif

This is a standard pattern in embedded code (you'll see it in ST's HAL library too!) because it's easy to maintain and debug.

3. Avoid String Comparisons (Not Recommended) #

You could technically use stringization to compare UART names, but this is clunky and error-prone. For example:

#define UART_NAME "UART1"
#if __STRING(UART) == "UART1"

But this breaks if UART1 is defined as a type-cast address (since __STRING(UART) would expand to "(uint8_t*)0x004000000"), so it's not a reliable solution here.

Key Takeaway #

Always remember: the preprocessor is a text processor, not a C compiler. It can't handle type casts, floating-point numbers, or pointer types in #if conditions. Stick to integer constants or defined() checks for preprocessor logic, and leave type-specific syntax for the actual compilation phase.

内容的提问来源于stack exchange，提问作者clem steredenn