2. 嵌入式软件架构基础

说实话，C语言在嵌入式领域能活这么久，靠的就是两样东西：指针和内存控制。很多新手觉得指针难，其实不是指针本身难，而是你还没建立起内存的“空间感”。这一章，我就带你把这个空间感建立起来。

指针进阶：函数指针与回调机制

先聊函数指针。很多人一看到“函数指针”四个字就头大，觉得这是语法糖。其实不然。函数指针在嵌入式里，是解耦的利器。

我举个例子。你写一个驱动，要支持SPI Flash、W25Q64、GD25Q64好几款芯片。它们的读ID函数、擦除函数、写入函数，名字都不一样。难道每次换芯片都改一遍驱动代码？

当然不。用函数指针表就行了。

// 定义一个函数指针类型
typedef int (*flash_read_id_t)(void);
typedef int (*flash_erase_t)(uint32_t addr);
typedef int (*flash_write_t)(uint32_t addr, const uint8_t *data, uint32_t len);

// 定义一个驱动接口结构体
typedef struct {
    flash_read_id_t  read_id;
    flash_erase_t    erase_sector;
    flash_write_t    write_page;
} flash_ops_t;

// 为不同芯片实例化
const flash_ops_t w25q64_ops = {
    .read_id      = w25q64_read_id,
    .erase_sector = w25q64_erase_sector,
    .write_page   = w25q64_write_page,
};

const flash_ops_t gd25q64_ops = {
    .read_id      = gd25q64_read_id,
    .erase_sector = gd25q64_erase_sector,
    .write_page   = gd25q64_write_page,
};

// 使用时，只需要切换 ops 指针
void flash_init(const flash_ops_t *ops) {
    uint32_t id = ops->read_id();
    // ...
}

你看，上层代码根本不需要知道底层用的是哪款芯片。这就是面向接口编程在C语言里的落地方式。我在做一款工业网关时，用这个模式同时兼容了4种不同厂商的Flash芯片，驱动层一行代码都没改。

回调函数：让框架“通知”你

回调函数本质就是函数指针的一种应用。你注册一个函数进去，框架在特定事件发生时调用它。

典型的场景：定时器超时回调、按键按下回调、数据接收完成回调。

typedef void (*timer_callback_t)(void *arg);

typedef struct {
    uint32_t          period_ms;
    timer_callback_t  callback;
    void             *arg;
    uint8_t           is_running;
} soft_timer_t;

void soft_timer_start(soft_timer_t *tmr) {
    // 启动硬件定时器，每次中断检查是否超时
    // 超时则调用 tmr->callback(tmr->arg);
}

我的习惯：回调函数的参数里，一定要留一个 void *arg。为什么？因为你不知道用户想在回调里传什么数据进去。留个万能指针，让用户自己去强转。这是C语言里最常见的“扩展性预留”手法。

内存四区模型：理解程序的内存布局

搞嵌入式，不懂内存四区，就像开车不看仪表盘。你想想看，程序跑起来以后，内存到底是怎么划分的？

标准C程序的内存布局，从上到下分为四个区：

区域 存储内容 生命周期 典型问题
栈区 局部变量、函数参数、返回地址 函数调用期间 栈溢出、返回局部变量地址
堆区 malloc/free 动态分配的内存 手动控制，直到 free 内存泄漏、碎片化
全局区（静态区） 全局变量、static 变量、常量字符串 程序启动到结束 多线程竞争、未初始化
代码区 程序指令（只读） 程序运行期间 意外修改（MPU保护）

这里我重点说一个坑：千万不要返回局部变量的地址。

// 错误示范
int* get_value(void) {
    int a = 100;
    return &a;  // a 在栈上，函数返回后栈空间被回收
}

// 正确做法：要么用 static，要么用 malloc
int* get_value_safe(void) {
    static int a = 100;
    return &a;
}

int* get_value_heap(void) {
    int *p = (int*)malloc(sizeof(int));
    if (p) *p = 100;
    return p;
}

我曾经在一个项目里排查了整整两天，发现一个传感器数据偶尔会跳变。最后定位到，就是某个函数返回了局部变量的地址，栈被后续调用覆盖了。嗯，从那以后，我写函数返回值时，第一反应就是问自己：这个指针指向的内存，生命周期够不够长？

堆栈管理：嵌入式环境下的特殊考量

在PC上，堆和栈都很大，随便用。但在MCU上，RAM总共就几十K到几百K。你得精打细算。

栈大小怎么定？

我一般用两种方法：

  • 静态分析法：把每个函数的局部变量大小加起来，再考虑函数调用嵌套深度。但这种方法容易漏算，因为编译器可能会优化。
  • 动态填充法：启动时把栈区全部填充为0xAA或0xDEAD，运行一段时间后，检查栈空间有多少字节被改写了。没被改写的部分，就是栈的余量。
// 栈使用量检测
#define STACK_SIZE   2048
uint8_t stack_pool[STACK_SIZE];

void stack_monitor_init(void) {
    memset(stack_pool, 0xAA, STACK_SIZE);
}

uint32_t stack_used_peak(void) {
    uint32_t i;
    for (i = 0; i < STACK_SIZE; i++) {
        if (stack_pool[i] != 0xAA) break;
    }
    return STACK_SIZE - i;  // 剩余未使用的字节数
}

注意：在FreeRTOS等RTOS里，每个任务都有自己的独立栈。任务栈溢出是嵌入式开发里最常见的崩溃原因之一。我建议你在调试阶段，把 configCHECK_FOR_STACK_OVERFLOW 这个宏打开，让系统帮你检测。

堆管理：能用静态就别用动态

很多嵌入式项目干脆禁止使用 malloc。为什么？

  • 堆碎片化：频繁分配释放，会导致内存碎片，最后明明有空间却分配不出来。
  • 不确定性：malloc 的执行时间不固定，实时性要求高的场景不能用。
  • 泄漏风险：忘记 free 是家常便饭。

我的建议是：能用静态数组、静态分配解决的问题，就不要用堆。如果实在要用，比如协议栈需要动态分配缓冲区，那就用固定大小内存池代替通用堆。

// 简单的固定大小内存池
#define POOL_BLOCK_SIZE   64
#define POOL_BLOCK_COUNT  16

static uint8_t pool_mem[POOL_BLOCK_SIZE * POOL_BLOCK_COUNT];
static uint32_t pool_bitmap;  // 16位位图，标记哪些块被占用

void* pool_alloc(void) {
    for (int i = 0; i < POOL_BLOCK_COUNT; i++) {
        if (!(pool_bitmap & (1 << i))) {
            pool_bitmap |= (1 << i);
            return &pool_mem[i * POOL_BLOCK_SIZE];
        }
    }
    return NULL;  // 没有空闲块
}

void pool_free(void *ptr) {
    uint32_t offset = (uint32_t)((uint8_t*)ptr - pool_mem);
    int idx = offset / POOL_BLOCK_SIZE;
    pool_bitmap &= ~(1 << idx);
}

这种内存池，分配和释放都是O(1)复杂度，没有碎片，执行时间确定。我在一个CAN总线网关项目里用了这种方案，连续跑了三年没出过内存问题。

内存泄漏检测与防御性编程

内存泄漏在嵌入式里比在PC上更致命。PC上泄漏了，大不了重启应用。嵌入式设备可能部署在无人值守的野外，一跑就是几个月甚至几年。泄漏一点，慢慢就死了。

手动检测：包装 malloc/free

我习惯在调试阶段，把 malloc 和 free 包装一层，记录分配和释放的配对情况。

// 调试版内存分配器
#define MEM_LEAK_LOG_SIZE  256

typedef struct {
    void   *ptr;
    uint32_t size;
    const char *file;
    uint32_t line;
} mem_record_t;

static mem_record_t mem_log[MEM_LEAK_LOG_SIZE];
static uint32_t mem_log_count = 0;

void* debug_malloc(uint32_t size, const char *file, uint32_t line) {
    void *p = malloc(size);
    if (p && mem_log_count < MEM_LEAK_LOG_SIZE) {
        mem_log[mem_log_count].ptr  = p;
        mem_log[mem_log_count].size = size;
        mem_log[mem_log_count].file = file;
        mem_log[mem_log_count].line = line;
        mem_log_count++;
    }
    return p;
}

void debug_free(void *ptr) {
    // 在日志中查找并标记为已释放
    for (uint32_t i = 0; i < mem_log_count; i++) {
        if (mem_log[i].ptr == ptr) {
            mem_log[i].ptr = NULL;  // 标记释放
            break;
        }
    }
    free(ptr);
}

// 程序退出时，打印所有未释放的记录
void debug_mem_report(void) {
    for (uint32_t i = 0; i < mem_log_count; i++) {
        if (mem_log[i].ptr != NULL) {
            printf("LEAK: %p size=%u at %s:%u\n",
                   mem_log[i].ptr, mem_log[i].size,
                   mem_log[i].file, mem_log[i].line);
        }
    }
}

// 使用宏替换标准函数
#define malloc(s)    debug_malloc(s, __FILE__, __LINE__)
#define free(p)      debug_free(p)

核心思路：用宏把标准库函数替换成带日志的版本。这样你不需要改业务代码，就能拿到所有内存操作的记录。发布正式版时，把宏定义去掉就行。

防御性编程：写代码时就假设会出错

防御性编程不是事后补漏洞，而是写代码时就假设：输入可能非法、指针可能为空、内存可能不够。

我总结了几条铁律：

  • 指针使用前必判空：尤其是函数参数里的指针。
  • malloc 后必判返回值：不要假设分配一定成功。
  • 数组访问加边界检查：特别是在处理通信数据包时。
  • 结构体初始化用 memset 清零：防止未初始化的字段产生随机行为。
// 防御性编程示例
int process_packet(uint8_t *buf, uint32_t len) {
    // 1. 判空
    if (buf == NULL) return -1;

    // 2. 判长度
    if (len < sizeof(packet_header_t)) return -2;

    // 3. 强制类型转换后，检查对齐
    packet_header_t *hdr = (packet_header_t*)buf;
    if ((uint32_t)hdr % 4 != 0) return -3;  // 非对齐访问

    // 4. 处理数据时，再次检查边界
    uint32_t payload_len = hdr->payload_length;
    if (payload_len > MAX_PAYLOAD_SIZE) return -4;
    if (sizeof(packet_header_t) + payload_len > len) return -5;

    // 5. 安全处理
    // ...
    return 0;
}

你看，一个简单的数据包处理函数，我加了5道检查。有人觉得啰嗦，但我在实际项目中，这种检查至少帮我拦截过十几次因为通信干扰导致的野指针崩溃。

本章知识体系总览

下面这张图，把本章的核心知识点串在了一起。你可以把它当作一个快速索引，哪里忘了就回来看看。

嵌入式C语言高级特性与内存管理知识体系 嵌入式C语言高级特性与内存管理 · 知识体系 指针进阶 内存四区模型 堆栈管理 函数指针 回调机制 栈区 堆区 全局区 栈溢出检测 内存池替代 防御性编程：判空 · 判边界 · 判返回值 内存泄漏检测包装 栈使用量监控 核心原则 能用静态不用堆 · 指针必判空 · 边界必检查 · 释放必配对

这张图把本章的四个核心模块串在了一起：指针进阶、内存四区、堆栈管理、防御性编程。它们不是孤立的，而是层层递进的关系。你掌握了函数指针和回调，才能写出灵活的中间件；你理解了内存四区，才知道变量该放哪里；你学会了堆栈管理，才能避免运行时崩溃；最后，防御性编程是你守住底线的最后一道防线。

我的建议：学完这一章，回去把你以前写的代码翻出来，看看有没有返回局部变量地址的地方，有没有 malloc 后没判空的地方。改掉一个，就少一个坑。我自己就是这么过来的。

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