第二章 高效数据类型选择：定点数与浮点数选择、位域与联合体的妙用、枚举与宏定义的最佳实践
2.1 定点数与浮点数：ADAS中的“算力账”
做ADAS的朋友都知道，咱们的芯片资源金贵得很。浮点运算虽然精度高，但功耗和面积都扛不住。我刚开始做车道线检测时，就吃过这个亏——全用float算，结果MCU直接过热降频。
说白了，定点数就是用整数来模拟小数。比如你要表示0.5，用Q15格式就是16384（2^15）。为什么这么干？因为整数运算比浮点快一个数量级，而且硬件乘法器更省资源。
核心原则：能用定点就别用浮点。但要注意动态范围——我见过有人把Q15用在-100到100的数值上，结果精度全丢了。
举个例子，在AEB（自动紧急制动）算法中，计算碰撞时间TTC时：
// 浮点版本
float ttc = distance / relative_velocity;
// 定点版本（Q16格式）
int32_t ttc_q16 = (distance_q16 << 16) / relative_velocity_q16;你看，定点版本省去了FPU的调用开销。我在项目中实测过，同样的TTC计算，定点版本快了3倍以上。
我的习惯：先评估数值范围，再选Q格式。比如距离0-200米，速度0-100km/h，用Q12就够了。留点余量，别卡太死。
2.2 位域与联合体：把内存榨干的艺术
嵌入式系统里，寄存器就是命根子。位域这东西，说白了就是让编译器帮你做移位和掩码操作。我早期做CAN报文解析时，手写移位代码写到吐，后来用了位域，代码量直接砍半。
typedef struct {
uint32_t speed : 12; // 车速，0-4095
uint32_t accel : 10; // 加速度，-512到511
uint32_t brake : 1; // 刹车状态
uint32_t reserved : 9; // 保留位
} VehicleStatus_t;嗯，这里要注意：位域的顺序是编译器相关的。我在不同MCU上踩过坑——同样的位域定义，在ARM和RISC-V上解析结果完全相反。所以跨平台项目，我建议还是用联合体+手动移位。
联合体才是真正的“一鱼多吃”。比如你要解析一个32位的CAN报文，里面既有整包数据，又有各个字段：
typedef union {
uint32_t raw; // 原始报文
struct {
uint32_t id : 11;
uint32_t dlc : 4;
uint32_t data : 8;
uint32_t checksum : 8;
uint32_t rtr : 1;
} fields;
} CanMessage_t;这样你既可以用msg.raw直接发送，又可以用msg.fields.id读取具体字段。我曾经在毫米波雷达驱动里用这个技巧，把报文解析时间从50us降到了12us。
避坑指南：我曾经在联合体里放了一个uint32_t和一个struct，结果struct里有个位域跨了字节边界——不同编译器处理方式不同，导致数据错位。后来我强制加了__attribute__((packed))才搞定。
2.3 枚举与宏定义：代码可读性的分水岭
你想想看，一个ADAS系统里有多少状态？车道保持、自适应巡航、紧急制动...如果全用数字0、1、2表示，三个月后你自己都看不懂。枚举就是干这个的。
typedef enum {
LANE_KEEP_OFF = 0,
LANE_KEEP_ACTIVE,
LANE_KEEP_WARNING,
LANE_KEEP_INTERVENTION,
LANE_KEEP_FAILURE
} LaneKeepState_t;我个人习惯，枚举值一定要显式赋值。为什么？因为有时候你会插入新状态，如果不显式赋值，后面的值全变了，整个系统的状态机就崩了。
宏定义呢，我把它当“配置开关”用。比如调试时打开日志，发布时关掉：
#define DEBUG_ENABLE 1
#if DEBUG_ENABLE
#define LOG_INFO(fmt, ...) printf("[INFO] " fmt "\n", ##__VA_ARGS__)
#else
#define LOG_INFO(fmt, ...) // 空定义，编译器会优化掉
#endif但宏定义有个坑——它没有类型检查。我见过有人把#define MAX_SPEED 120用在浮点比较里，结果因为隐式类型转换出了bug。所以现在我的原则是：能用枚举就用枚举，宏定义只做条件编译和常量定义。
最佳实践：枚举用于状态机和错误码，宏定义用于配置开关和编译选项。别混用，别滥用。
2.4 实战对比：三种方案的性能差异
我拿一个实际项目的数据说话——在Cortex-M4上跑AEB算法中的碰撞检测模块：
| 方案 | 代码量（行） | 执行时间（us） | 内存占用（字节） |
|---|---|---|---|
| 全浮点 | 45 | 128 | 64 |
| 定点+位域 | 62 | 41 | 28 |
| 定点+联合体 | 58 | 38 | 24 |
你看，定点方案虽然代码多了点，但执行时间只有浮点的三分之一，内存也省了一半多。在ADAS这种实时性要求高的场景里，这点代码量的增加完全值得。
我的建议：别一上来就优化。先写个浮点版本验证算法，确认逻辑正确后，再定点化。我见过太多人一开始就搞定点，结果算法调不通，debug到崩溃。
最后说一句，数据类型选择没有银弹。你得根据实际场景权衡——精度、速度、内存、可维护性，哪个都不能少。但记住一点：在嵌入式ADAS里，确定性比高性能更重要。一个每次都能在1ms内算完的定点算法，比一个有时0.5ms有时2ms的浮点算法靠谱得多。