直接赋值崩溃但memcpy()可行的原因验证及替代方案咨询

你的同事完全说对了，这就是典型的内存对齐问题导致的总线错误，我来给你拆解清楚，顺便解答你剩下的疑问：

1. 同事的判断是否正确？ #

完全正确！核心原因就是数据对齐不匹配。
你用的是Cortex-A7（ARMv7-A架构），这个架构的CPU在执行32位数据（比如float）的直接加载/存储指令时，要求地址必须是4字节对齐（也就是地址的最后两位二进制是00）。当你把pdata++后的地址强转成float*直接解引用赋值时，如果这个地址不是4字节对齐的，CPU会触发数据终止异常（Data Abort）——也就是你看到的应用崩溃。

而memcpy()的底层逻辑是逐字节读写，用的是单字节加载/存储指令（比如ARM的LDRB/STRB），这类指令完全不要求地址对齐，自然能绕过这个限制正常工作。

2. 为什么STM32/AVR等MCU没遇到这个问题？ #

这得看不同MCU的架构特性：

• STM32系列：大部分STM32用的是Cortex-M内核（M3/M4/M7居多），这些内核默认允许非对齐内存访问（只是非对齐访问会有性能损耗，但不会崩溃）。就算是Cortex-M0/M0+这类对对齐要求更严的内核，很多开发环境的默认配置会自动处理非对齐访问（比如编译器生成容错代码，或者硬件开启了非对齐支持），所以你感知不到崩溃。
• AVR系列：这是8位MCU，内部总线是8位的，不管访问什么宽度的数据，本质都是逐字节操作，根本不存在“对齐”的概念——自然不会有对齐错误。

3. 除了memcpy，还有哪些正确的实现方式？ #

当然有，推荐几个跨平台且安全的方案：

方式1：手动逐字节拷贝 #

和memcpy原理一致，就是手动实现字节级别的赋值：

if (*(const uint8_t*)pdata == PARAM_FP32 && n >= 5) {
    pdata++;
    const uint8_t* src_bytes = (const uint8_t*)pdata;
    uint8_t* dst_bytes = (uint8_t*)&my_variable;
    dst_bytes[0] = src_bytes[0];
    dst_bytes[1] = src_bytes[1];
    dst_bytes[2] = src_bytes[2];
    dst_bytes[3] = src_bytes[3];
}

这种方式完全不依赖编译器特性，跨平台性拉满。

方式2：用联合体做类型转换 #

利用联合体的内存重叠特性，先把字节数据存到数组里，再取出float值：

// 定义一个用于类型转换的联合体
union FloatByteConverter {
    float fp_val;
    uint8_t byte_arr[4];
};

// 回调函数内的实现
if (*(const uint8_t*)pdata == PARAM_FP32 && n >= 5) {
    pdata++;
    union FloatByteConverter conv;
    const uint8_t* src = (const uint8_t*)pdata;
    for (int i = 0; i < 4; i++) {
        conv.byte_arr[i] = src[i];
    }
    my_variable = conv.fp_val;
}

这种方式可读性不错，也是跨平台的安全方案。

方式3：编译器特定的非对齐修饰（不推荐跨平台） #

如果你的代码确定不会移植到其他编译器环境，可以用ARM GCC的__attribute__((packed))修饰指针，告诉编译器这个地址可能是非对齐的：

if (*(const uint8_t*)pdata == PARAM_FP32 && n >= 5) {
    pdata++;
    my_variable = *(const float __attribute__((packed)) *)pdata;
}

注意：这个方法是编译器依赖的，换Clang、IAR等编译器可能就失效了，所以非必要不建议用。

总结 #

同事的判断100%正确，核心就是Cortex-A7的非对齐访问限制。MCU里没遇到问题是因为架构本身的对齐规则不同。除了memcpy，手动逐字节拷贝和联合体都是靠谱的跨平台替代方案。

内容来源于stack exchange