2、内存管理基础：嵌入式内存布局、堆与栈的区别、内存对齐原则

各位同学，咱们今天聊点实在的。做蓝牙驱动开发，说白了就是在跟内存打交道。你写的每一行代码，最终都要落到内存里跑。我见过太多新手，上来就 malloc，结果系统跑着跑着就崩了。嗯，咱们今天就把内存这块地基打牢。

2.1 嵌入式内存布局：你的代码到底住在哪？

先说说嵌入式设备的内存长什么样。你想想看，一个蓝牙芯片，比如 Nordic 的 nRF52840，它的内存空间是固定的。我习惯把嵌入式内存想象成一栋楼，每层都有不同的用途。

典型的嵌入式内存布局是这样的：

+------------------+ 高地址
|    栈 (Stack)     | 向下增长
|        ↓         |
|        ↑         |
|    堆 (Heap)      | 向上增长
+------------------+
|  全局/静态区      |
+------------------+
|  代码区 (Text)    |
+------------------+ 低地址

我在项目中遇到过一个问题：蓝牙协议栈跑着跑着就死机了。查了半天，原来是栈溢出了，把堆里的数据给踩了。这种问题最难查，因为错误不会立刻暴露。

关键点：嵌入式系统的内存是有限的，通常只有几十到几百 KB。你没法像 PC 那样随意分配。每个字节都要精打细算。

具体来说，各个区域的作用：

  • 代码区（Text）：存放你的程序指令。只读的，别想改它。
  • 全局/静态区：全局变量、static 变量都在这。程序启动时就分配好了，直到结束才释放。
  • 堆（Heap）：动态分配的内存，比如 malloc、calloc 出来的。需要手动管理。
  • 栈（Stack）：函数调用、局部变量、中断现场都在这。自动分配自动释放。

2.2 堆与栈的区别：别搞混了，后果很严重

说实话，堆和栈的区别，是面试常考题，也是实际开发中的坑。我刚开始做蓝牙驱动时，就犯过糊涂。

对比项 栈（Stack） 堆（Heap）
分配方式 自动分配/释放 手动分配/释放
速度 极快（一条指令） 较慢（需要查找空闲块）
大小 固定，通常几 KB 可配置，通常几十 KB
碎片问题 无碎片 容易产生碎片
生命周期 函数结束即释放 直到手动释放
典型用途 局部变量、函数参数 大块数据、动态结构体

为什么会这样？说白了，栈就是 LIFO（后进先出）的结构。你调用一个函数，就把局部变量压栈；函数返回，自动弹栈。干净利落。

堆就不一样了。你 malloc 一块内存，系统得去空闲链表里找一块合适的。释放时还得把这块内存还回去。时间长了，就会产生碎片——就像硬盘碎片一样，明明总空间够，但就是分配不出连续的大块内存。

我的建议：在蓝牙驱动中，能用栈就别用堆。比如处理一个蓝牙数据包，如果包大小是固定的（比如 255 字节），直接在栈上分配数组就行。别图省事去 malloc。

我曾经在一个 BLE 项目中，用 malloc 分配了一个 1KB 的缓冲区来接收通知数据。结果设备运行 3 天后，malloc 返回 NULL 了。查到最后，就是堆碎片导致的。后来改成栈上分配，问题解决。

2.3 内存对齐原则：别让 CPU 白干活

内存对齐，这个词听起来有点玄乎。其实说白了，就是数据在内存里的摆放位置要符合一定的规则。

大多数 CPU 访问对齐的数据时，效率最高。比如一个 4 字节的 int，如果它的地址是 4 的倍数，CPU 一次就能读完。如果地址不对齐，CPU 可能需要读两次，再把结果拼起来——白白浪费了时钟周期。

我习惯用这个规则：

  • 1 字节数据：任何地址都可以
  • 2 字节数据：地址必须是 2 的倍数
  • 4 字节数据：地址必须是 4 的倍数
  • 8 字节数据：地址必须是 8 的倍数

看个例子：

// 假设结构体定义如下
struct ble_packet {
    uint8_t  type;      // 1 字节
    uint16_t length;    // 2 字节
    uint32_t data;      // 4 字节
};

// 实际内存布局（带对齐）
// 地址 0: type (1 字节)
// 地址 1: 填充 (1 字节) ← 为了对齐 length
// 地址 2: length (2 字节)
// 地址 4: data (4 字节)
// 总大小: 8 字节

// 如果不做对齐，length 可能放在地址 1，CPU 访问时就要多花时间

注意：在蓝牙协议栈中，很多数据包结构体是直接从空中收到的数据映射过来的。如果对齐方式不对，轻则性能下降，重则直接触发硬件异常（比如 ARM 的 HardFault）。

我曾经在调试一个蓝牙 HID 设备时，发现按键响应时快时慢。用逻辑分析仪抓包，数据没问题。最后发现是结构体成员没对齐，导致 CPU 在访问某些字段时多花了几个时钟周期。在实时性要求高的场景下，这种延迟是不能接受的。

怎么保证对齐？我一般用两种方法：

  1. 编译器属性：用 __attribute__((packed)) 取消对齐（节省空间，但牺牲性能）
  2. 手动填充：在结构体里加 padding 字节，保证每个成员都自然对齐

看代码：

// 方法1：取消对齐（适合网络协议解析）
struct __attribute__((packed)) ble_packet_raw {
    uint8_t  type;
    uint16_t length;
    uint32_t data;
};  // 大小 = 7 字节，但访问 data 可能慢

// 方法2：手动对齐（推荐用于内部数据结构）
struct ble_packet_aligned {
    uint8_t  type;
    uint8_t  padding;  // 手动填充
    uint16_t length;
    uint32_t data;
};  // 大小 = 8 字节，访问效率高

我的习惯：在蓝牙驱动内部，能用对齐结构体就用对齐的。只有在解析空中数据包时，才用 packed 结构体。这样既保证了性能，又兼容了协议格式。

嗯，内存管理这块，说白了就是三个字：别浪费，别踩踏，别对齐错。你把这三点记住了，蓝牙驱动开发就成功了一半。下一节咱们聊聊动态内存分配的具体策略，包括怎么避免碎片、怎么用内存池。到时候我会拿一个实际的蓝牙协议栈例子来拆解。

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