4. 数据类型与内存模型

嵌入式C++工程中，数据类型与内存模型不是“语言细节”，而是直接决定程序能否在目标板上正确运行的基础设施。同一段代码在x86主机上运行正常，烧录到ARM Cortex-M后却出现数据错乱、总线异常或启动失败，根源往往在于：类型宽度不确定、字节序假设错误、结构体对齐不一致、栈堆边界失控、链接脚本与存储区不匹配。本节从工程视角梳理这些关键点，并给出可落地的检查方法。

一、固定宽度类型：先消灭“int到底几字节”的不确定性

C++标准只规定 int 至少16位、long 至少32位，并未固定其宽度。在跨平台嵌入式项目中，若用 int 表示寄存器值、协议字段或Flash地址，就可能在不同编译器/架构下产生不同布局。工程上应优先使用 <cstdint> 提供的固定宽度类型：

#include <cstdint>

std::uint8_t  cmd;        // 命令码，恰好1字节
std::uint16_t crc;        // 校验值，恰好2字节
std::uint32_t addr;       // 地址，恰好4字节
std::int32_t  offset;     // 有符号偏移
std::uintptr_t handle;    // 可容纳指针的无符号整数

// 需要“至少”宽度时使用
std::uint_least16_t counter;
std::uint_fast32_t  tick;

选择原则：协议字段、寄存器映射、持久化数据、跨核共享结构必须使用固定宽度类型；仅用于循环计数、局部临时变量时，才可考虑 int 或 size_t。此外，std::byte 适合表达“原始字节”，比 unsigned char 语义更清晰。

二、字节序：多字节数据在内存中的排列顺序

字节序描述多字节标量在内存中的存放顺序。小端（Little-Endian）将最低有效字节放在低地址，大端（Big-Endian）相反。ARM Cortex-M默认小端，但网络协议通常采用大端，部分DSP或异构核可能不同。工程中不要用“强制转换指针”判断字节序，而应使用编译期或运行期安全检测：

constexpr bool is_little_endian() {
    return std::endian::native == std::endian::little; // C++20
}

// 不依赖C++20时的运行期检测
bool little() {
    const std::uint16_t v = 0x0102;
    const auto* p = reinterpret_cast<const std::uint8_t*>(&v);
    return p[0] == 0x02;
}

跨平台传输时，应显式做字节序转换，而不是依赖内存拷贝。例如将32位值写入网络缓冲区：

void put_u32_be(std::uint8_t* buf, std::uint32_t v) {
    buf[0] = static_cast<std::uint8_t>(v >> 24);
    buf[1] = static_cast<std::uint8_t>(v >> 16);
    buf[2] = static_cast<std::uint8_t>(v >> 8);
    buf[3] = static_cast<std::uint8_t>(v);
}

三、对齐与内存布局：结构体不是“字段简单相加”

编译器会为字段插入填充字节，使每个成员位于其对齐要求的地址上。结构体总大小也会被填充到最大成员对齐值的整数倍。这意味着结构体大小不等于各字段大小之和，直接按字节解析协议或寄存器映射极易出错。

优化布局的常用手段是按对齐从大到小排列字段，或使用 #pragma pack / __attribute__((packed)) 取消填充。但 packed 结构体访问未对齐字段可能触发硬件异常或性能下降，在Cortex-M0/M3等平台上尤其危险。更稳妥的做法是：协议解析使用显式字节读取函数，寄存器映射使用 volatile + 固定偏移，而不是直接强转结构体指针。

四、栈、堆与静态存储区：内存分区与链接脚本

嵌入式程序通常分为几个存储区：.text（代码与常量）、.data（已初始化全局/静态变量）、.bss（未初始化或零初始化全局/静态变量）、heap（动态分配）、stack（函数调用与局部变量）。链接脚本（linker script）负责把这些段映射到Flash和RAM的具体地址。

/* 典型STM32链接脚本片段 */
MEMORY
{
  FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 512K
  RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}

SECTIONS
{
  .text : { *(.text*) *(.rodata*) } > FLASH
  .data : { *(.data*) } > RAM AT> FLASH
  .bss  : { *(.bss*) *(COMMON) } > RAM
  _estack = ORIGIN(RAM) + LENGTH(RAM);
}

启动代码负责把 .data 从Flash拷贝到RAM，并把 .bss 清零。若链接脚本中 .data 的加载地址与运行地址配置错误，全局变量初值就会丢失。栈通常从RAM顶端向下增长，堆从低地址向上增长，二者相向而行。若堆栈相遇，就会发生难以定位的踩踏。工程上应通过链接脚本或启动文件设置栈顶符号，并在调试阶段用填充模式（如 0xDEADBEEF）检测栈使用峰值。

理解内存模型后，再看一个典型场景：某设备通过串口接收一帧数据，帧头为 0xAA55，后跟长度、命令、负载和CRC。若直接定义 struct Frame { uint16_t head; uint8_t len; uint8_t cmd; uint8_t payload[64]; uint16_t crc; } 并强转接收缓冲区，由于对齐填充，payload 的偏移可能不是预期的4，CRC位置也会错位。正确做法是定义固定偏移的解析函数，并用 static_assert 锁定关键类型宽度。这样即使更换编译器或优化等级，协议解析依然稳定。

最后强调：内存模型是嵌入式C++工程的“地基”。固定宽度类型解决“多大”，字节序解决“怎么排”，对齐解决“放哪里”，链接脚本解决“放在哪块存储区”。四者配合，才能让代码从主机仿真平稳迁移到真实硬件。