📚 课程目录第3章 Flash与RAM访问优化

第三章 Flash与RAM访问优化：零等待周期配置、ART加速器原理、代码/数据在RAM中运行、分散加载文件实战

各位做STM32F407开发的朋友，咱们今天聊点实在的——怎么让代码跑得更快。很多人觉得F407主频168MHz已经够快了，但实际项目里，Flash访问速度往往成了瓶颈。我见过不少工程师，明明代码逻辑没问题，可系统就是卡顿，查了半天才发现是Flash等待周期没配好。嗯，咱们今天就把它彻底讲透。

3.1 零等待周期配置——别让Flash拖后腿

先说说最基础的问题：为什么需要配置等待周期？

STM32F407的Flash最高能跑到168MHz，但Flash本身的速度没那么快。你想想看，CPU在168MHz下跑，一个周期才6ns左右，而Flash读取需要的时间更长。如果不加等待周期，CPU读到的数据就是错的。

等待周期的配置其实很简单，就在FLASH_ACR寄存器里。我个人习惯用HAL库的宏定义，但咱们也得知道底层怎么配。

/* 配置Flash等待周期 */
/* 系统时钟168MHz时，需要5个等待周期 */
FLASH->ACR = FLASH_ACR_LATENCY_5WS |   /* 5个等待周期 */
             FLASH_ACR_PRFTEN |         /* 开启预取缓冲 */
             FLASH_ACR_ICEN |           /* 开启指令缓存 */
             FLASH_ACR_DCEN;            /* 开启数据缓存 */

关键点：等待周期不是越多越好，也不是越少越好。配少了系统不稳定，配多了性能下降。F407在不同频率下的推荐配置如下：

系统时钟频率	等待周期数	备注
0-30MHz	0	零等待，性能最佳
30-60MHz	1	轻度延迟
60-90MHz	2	中等延迟
90-120MHz	3	较高延迟
120-150MHz	4	高延迟
150-168MHz	5	最高延迟，但必须

我曾经踩过的坑：有一次做电机控制项目，系统时钟配到168MHz，但等待周期只设了4。结果电机偶尔会抖动一下，查了两天才发现是Flash读取错误导致的。从那以后，我每次配时钟都会再三确认等待周期。

3.2 ART加速器原理——F407的秘密武器

ART加速器，全称是Adaptive Real-Time Memory Accelerator。说白了，它就是STM32F407内部的一个智能缓存系统。你想想看，CPU要读Flash里的指令，如果每次都去Flash里取，那等待周期就白配了。ART加速器的作用就是：把最近用过的指令和数据缓存起来，下次要用的时候直接从缓存拿，不用再去Flash里读。

ART加速器包含三个部分：

指令缓存（ICache）：缓存最近执行的指令，减少Flash读取次数
数据缓存（DCache）：缓存最近访问的数据，提高数据读取速度
预取缓冲（Prefetch Buffer）：提前把下一条指令取出来，减少等待

我建议你在所有项目里都开启ART加速器。开启方法就是上面代码里的那三个标志位。不过要注意，开启后功耗会稍微增加一点，但对于性能提升来说，这点功耗完全可以接受。

小技巧：如果你的代码里有很多循环或者频繁调用的函数，ART加速器的效果会特别明显。我做过测试，开启ART后，某些循环代码的执行速度能提升30%以上。

咱们用一张图来看看ART加速器的工作原理：

3.3 代码/数据在RAM中运行——极致性能的追求

ART加速器虽然好，但毕竟还是从Flash读数据。如果你追求极致性能，可以把关键代码和数据放到RAM里运行。RAM的访问速度比Flash快得多，而且不需要等待周期。

什么时候需要把代码放到RAM里？我总结了几种场景：

中断服务函数：需要快速响应的中断，比如定时器中断、外部中断
实时性要求高的算法：比如PID控制、FFT计算
频繁调用的函数：比如通信协议栈里的核心函数
关键数据：比如系统状态变量、缓冲区

注意：F407的SRAM只有192KB（112KB + 64KB + 16KB），别把整个程序都塞进去。我建议只放最关键的代码，其他代码还是老老实实待在Flash里。

把代码放到RAM里运行，有两种方式：

手动复制：在启动代码里把指定函数复制到RAM，然后跳转执行
分散加载：通过链接脚本（分散加载文件）自动完成

我个人强烈推荐第二种方式，省心又可靠。咱们接下来就讲这个。

3.4 分散加载文件实战——让链接器帮你干活

分散加载文件，说白了就是告诉链接器：哪些代码放Flash，哪些代码放RAM。在Keil MDK里，这个文件叫.sct（Scatter File）。

咱们先看一个最简单的分散加载文件：

; 默认的分散加载文件（简化版）
LR_IROM1 0x08000000 0x00100000  {    ; 加载区：Flash，起始0x08000000，大小1MB
  ER_IROM1 0x08000000 0x00100000  {  ; 执行区：Flash
    *.o (RESET, +First)              ; 中断向量表
    *(InRoot$$Sections)              ; 根区
    .ANY (+RO)                       ; 所有只读代码和数据
  }
  RW_IRAM1 0x20000000 0x0001C000  {  ; 执行区：SRAM，起始0x20000000，大小112KB
    .ANY (+RW +ZI)                   ; 所有读写数据和零初始化数据
  }
}

这个文件的意思是：代码从Flash启动，运行时也在Flash里执行；数据放在SRAM里。但如果我们想把某个函数放到RAM里执行，就需要修改这个文件。

实战步骤来了：

在代码里声明函数属性：用__attribute__((section(".RAM_FUNC")))标记要放到RAM的函数
修改分散加载文件：在SRAM区域里添加对应的段
在启动代码里复制：把Flash里的函数代码复制到RAM里

咱们看个完整的例子：

/* 在代码里声明 */
#define RAM_FUNC __attribute__((section(".RAM_FUNC")))

RAM_FUNC void critical_function(void)
{
    /* 这里放你的关键代码 */
    for(int i = 0; i < 1000; i++)
    {
        /* 做一些实时性要求高的操作 */
    }
}

对应的分散加载文件：

; 修改后的分散加载文件
LR_IROM1 0x08000000 0x00100000  {
  ER_IROM1 0x08000000 0x00100000  {
    *.o (RESET, +First)
    *(InRoot$$Sections)
    .ANY (+RO)
    *(.RAM_FUNC)                   ; 把RAM_FUNC段也放在Flash里（加载区）
  }
  RW_IRAM1 0x20000000 0x0001C000  {
    .ANY (+RW +ZI)
    *(.RAM_FUNC)                   ; 运行时放在RAM里（执行区）
  }
}

避坑指南：我曾经犯过一个错误——只改了分散加载文件，忘了在启动代码里做复制。结果程序一运行就死机，因为CPU跳转到RAM地址时，那里还是空的。记住，分散加载文件只是告诉链接器怎么安排，实际的复制工作需要在启动代码里完成。

启动代码里的复制逻辑（简化版）：

; 在启动文件里添加
LDR R0, =|Load$$RAM_FUNC$$Base|    ; Flash里的源地址
LDR R1, =|Image$$RAM_FUNC$$Base|   ; RAM里的目标地址
LDR R2, =|Image$$RAM_FUNC$$Length| ; 长度

RAM_FUNC_COPY:
  CMP R1, R2
  BCC COPY_LOOP
  B COPY_DONE

COPY_LOOP:
  LDR R3, [R0], #4
  STR R3, [R1], #4
  CMP R1, R2
  BCC COPY_LOOP

COPY_DONE:

性能对比：我做过实际测试，把PID控制算法放到RAM里运行后，执行时间从原来的12μs降到了4μs，提升了整整3倍。对于电机控制这种需要高频更新的场景，这个提升非常可观。

最后说一句，分散加载文件虽然看起来复杂，但掌握了之后，你会发现它其实是个很强大的工具。你可以灵活地控制每个函数、每个数据段的存放位置，真正做到性能调优的精细化。