4、数据类型优化：定点数与浮点数选择、位域与联合体使用、内存对齐

说到电机控制代码的优化，数据类型这块儿，我敢说至少有一半的性能问题都出在这里。你想想看，一个浮点运算在Cortex-M4上可能要几十个周期，而定点运算呢？几个周期就搞定了。这差距，可不是一星半点。

今天咱们就聊聊数据类型的那些事儿。我会结合自己踩过的坑，把定点数、浮点数、位域、联合体、内存对齐这些知识点掰开了讲清楚。

4.1 定点数与浮点数：性能与精度的博弈

先问个问题：你的电机控制代码里，是不是到处都是float？我以前也这样，直到有一次项目交付前发现CPU负载太高，一查，好家伙，浮点运算占了将近40%的时间。

为什么会这样？说白了，浮点运算单元（FPU）虽然快，但跟定点运算比，还是有差距的。尤其是在没有FPU的芯片上，那简直是灾难。

4.1.1 什么时候用浮点？什么时候用定点？

我个人习惯这样判断：

  • 有FPU的芯片（比如Cortex-M4/M7）：大部分场景直接用float，开发效率高，精度也够。但要注意，频繁的浮点运算还是会拖慢速度。
  • 没有FPU的芯片（比如Cortex-M0/M3）：尽量用定点数。除非是偶尔的标定参数计算，否则别碰浮点。
  • 实时性要求极高的环路：比如电流环、速度环，我建议全部用定点数。哪怕有FPU，定点数也能省下几个微秒。

核心原则：能用整数解决的问题，就别用浮点。电机控制中的大部分量——电流、电压、角度、速度——都可以用定点数表示。

4.1.2 定点数的实现技巧

定点数说白了就是「假装有小数点」。比如你要表示一个范围在-1.0到1.0之间的量，可以用Q15格式（16位有符号整数，小数点在第15位后面）。

举个例子：

// Q15格式：1.0 表示为 0x7FFF，-1.0 表示为 0x8001
// 0.5 表示为 0x4000

int16_t q15_mul(int16_t a, int16_t b) {
    // 两个Q15数相乘，结果要右移15位
    return (int16_t)(((int32_t)a * (int32_t)b) >> 15);
}

// 实际使用：电流环PI控制器
int16_t current_pi_q15(int16_t err, int16_t kp, int16_t ki) {
    static int16_t integral = 0;
    int16_t output;
    
    // 比例项
    int16_t p_out = q15_mul(kp, err);
    
    // 积分项（注意防饱和）
    integral += q15_mul(ki, err);
    if (integral > 0x7FFF) integral = 0x7FFF;
    if (integral < 0x8001) integral = 0x8001;
    
    output = p_out + integral;
    return output;
}

嗯，这里要注意：定点数乘法后一定要做移位，不然结果就错了。我在项目中遇到过有人忘了移位，结果电流环直接飞车，吓得我赶紧加了断言检查。

小技巧：定义几个宏，把定点数的加减乘除封装起来，代码可读性会好很多。比如：

#define Q15_MUL(a, b) ((int16_t)(((int32_t)(a) * (int32_t)(b)) >> 15))
#define Q15_TO_FLOAT(a) ((float)(a) / 32768.0f)
#define FLOAT_TO_Q15(f) ((int16_t)((f) * 32768.0f))

4.1.3 浮点数的优化技巧

如果非要用浮点，也有优化的空间：

  • 用单精度float，别用double：double在大多数MCU上都是软件模拟的，慢得离谱。
  • 减少类型转换：int转float、float转int都会消耗额外周期。
  • 用fast math库：很多编译器提供了-ffast-math选项，会牺牲一点点精度换取速度。

警告：使用-ffast-math时，要特别注意它可能会改变浮点运算的顺序，导致结果不一致。我在一次电机参数辨识中吃过这个亏，算出来的电感值差了5%。从那以后，我只有在确定不影响功能的情况下才开这个选项。

4.2 位域与联合体：让数据更紧凑

电机控制中，经常要处理各种状态标志、配置位。比如：电机是正转还是反转？有没有过流？编码器有没有故障？这些信息用位域来存，既省内存又方便。

4.2.1 位域的使用场景

我个人习惯把状态信息打包成一个uint16_t或uint32_t，然后用位域来访问：

// 电机状态结构体
typedef struct {
    uint16_t direction : 1;    // 0:正转, 1:反转
    uint16_t overcurrent : 1;  // 过流标志
    uint16_t encoder_fault : 1;// 编码器故障
    uint16_t speed_mode : 2;   // 速度模式: 00-开环, 01-闭环, 10-转矩
    uint16_t reserved : 11;    // 保留位
} MotorStatus_t;

// 使用示例
MotorStatus_t status = {0};
status.direction = 1;  // 反转
status.overcurrent = 0; // 无过流

// 检查状态
if (status.encoder_fault) {
    // 处理编码器故障
}

你看，这样写代码是不是很直观？而且只用了2个字节。如果不用位域，你可能要用4个甚至8个字节来存这些标志。

注意：位域的顺序和内存布局是编译器相关的。如果你需要跨平台或者跟硬件寄存器打交道，最好用联合体来保证布局可控。

4.2.2 联合体：灵活的数据访问

联合体在电机控制中最大的用处，就是让你可以用不同的方式访问同一块内存。比如：

// 用联合体实现字节和整数的互转
typedef union {
    uint16_t value;
    uint8_t bytes[2];
} Uint16Bytes_t;

// 用联合体解析CAN报文
typedef union {
    uint32_t raw;           // 原始32位数据
    struct {
        uint16_t current;   // 电流值
        uint16_t speed;     // 速度值
    } fields;
} CanData_t;

// 使用示例
CanData_t can_data;
can_data.raw = 0x12345678;
// 现在 can_data.fields.current = 0x5678
//     can_data.fields.speed = 0x1234

我曾经用联合体来解析编码器数据，省去了大量的移位和掩码操作。代码跑起来快了不少，而且不容易出错。

避坑指南：联合体的大小取决于最大的成员。如果你把一个大数组和一个结构体放在同一个联合体里，要小心内存占用。我曾经把1024字节的数组和几个小结构体放一起，结果联合体占了1024字节，白白浪费了内存。

4.3 内存对齐：看不见的性能杀手

内存对齐这事儿，很多人觉得无所谓。但你知道吗？不对齐的内存访问，在ARM芯片上可能会触发异常，或者导致性能骤降。

4.3.1 为什么需要对齐？

ARM Cortex-M系列要求：

  • 16位数据（halfword）必须对齐到2字节边界
  • 32位数据（word）必须对齐到4字节边界
  • 64位数据（doubleword）必须对齐到8字节边界

如果不满足这些条件，轻则性能下降（CPU要分多次读取），重则触发HardFault异常。我在调试一个电机驱动板时，就遇到过因为结构体没对齐导致随机死机的问题。查了三天，最后发现是一个uint32_t变量没对齐到4字节。

4.3.2 如何保证对齐？

有几种方法：

// 方法1：调整结构体成员顺序
// 不好的写法（浪费空间）
typedef struct {
    uint8_t a;      // 1字节
    uint32_t b;     // 4字节，需要从偏移4开始
    uint16_t c;     // 2字节
} BadStruct_t;      // 总大小：12字节（有填充）

// 好的写法（紧凑）
typedef struct {
    uint32_t b;     // 4字节
    uint16_t c;     // 2字节
    uint8_t a;      // 1字节
} GoodStruct_t;     // 总大小：8字节（无填充）

// 方法2：使用编译器属性
typedef struct __attribute__((packed)) {
    uint8_t a;
    uint32_t b;
    uint16_t c;
} PackedStruct_t;   // 总大小：7字节（但访问b可能很慢）

警告：使用__attribute__((packed))虽然能省空间，但会导致未对齐的成员访问变慢。在性能敏感的代码中（比如电流环），我建议不要用packed，而是手动调整成员顺序。

4.3.3 对齐的实用技巧

我总结了几条经验：

  • 大成员放前面：把uint32_t、float这些大类型放在结构体开头。
  • 小成员放后面：uint8_t、bool这些放最后。
  • 用sizeof检查：写代码时加个断言，确保结构体大小符合预期。
  • DMA缓冲区要对齐：如果要用DMA传输数据，缓冲区地址必须对齐到4字节或8字节。
// 检查结构体对齐的断言
typedef struct {
    uint32_t speed;
    uint16_t current;
    uint8_t status;
} MotorData_t;

// 编译时检查
_Static_assert(sizeof(MotorData_t) == 8, "MotorData_t size mismatch!");
_Static_assert(offsetof(MotorData_t, speed) % 4 == 0, "speed not aligned!");

嗯，说到断言，我建议在开发阶段尽量多用。它能帮你尽早发现问题，而不是等到现场调试时才抓狂。

小结

今天聊的这几个点，其实都是「细节决定成败」的体现。定点数还是浮点数？用不用位域？结构体怎么排？这些问题看似不起眼，但累积起来，可能就是10%甚至20%的性能差距。

我个人建议：在项目初期就定好数据类型的使用规范。比如：电流环全部用Q15定点数，状态标志用位域，结构体成员按大小排序。这样后期优化起来会轻松很多。

下一章，咱们聊聊「循环展开与循环优化」，看看怎么让那些跑得慢的循环飞起来。

← 上一章 📖 返回目录 下一章 →