说实话第一次在货架前看到 APS6404L-SQH-SN 的时候我差点以为它就是一颗普通的 SPI NOR Flash——SOIC-8 封装、8 个引脚长得跟 W25Q64 亲兄弟似的。但后来查手册才发现这颗芯片看着像 Flash内核其实是 DRAM容量 64Mbit 也就是 8MB专门用来给 MCU 当外挂大内存用。过去一年我在三个项目里都用它兜底从 LVGL 界面、音频缓冲到协议栈缓冲体验下来值得单独写一篇。这篇文章适合正在做以下事情的开发者MCU 自带 SRAM 捉襟见肘、想低成本给 STM32 / GD32 / ESP32 之类芯片扩内存、或者被PSRAM 到底能不能当普通 RAM 用这类问题困扰的朋友。我会把芯片原理、硬件接线、驱动移植、实测性能和踩坑记录一次讲透尽量做到你照着抄就能跑通。1. 先聊聊这 8MB 到底解决什么问题1.1 MCU 自带内存的硬上限从几十 KB 到几百 KB 的真实处境很多 MCU 项目做到一半真正拦住需求的不是 Flash 空间而是 RAM。举个最直观的例子跑一个 320x240 RGB565 的 LVGL 界面单帧显存就需要 3202402 153600 字节也就是 150KB这还只是 framebuffer没算控件、字体缓存和图片解码用的内存。而主流 STM32F103 的 SRAM 只有 20KB 到 64KB想靠片内资源跑图形界面连把整帧显示缓冲塞进去都费劲。再比如做音频应用采样率 16kHz、16bit 单声道一秒数据就是 32KB一个 10 秒的循环播放缓冲就要 320KB。如果同时还要跑 RTOS、文件系统、网络协议栈每样都要几 KB 到几十 KB片内 SRAM 往往分完任务栈之后就不剩什么了。这类需求不是靠编译器优化能解决的唯一的出路就是外挂内存。而外挂内存里SRAM 贵、SDRAM 引脚多、SPI Flash 不能随意当 RAM 用APS6404 这种 PSRAM 就正好站在性价比和易用性的交叉点上。1.2 哪些应用会一口气吃掉几百 KB 到几 MB我统计过自己用 PSRAM 的几类场景基本上分四类图形界面LVGL / GUI 引擎的 framebuffer、图层缓冲、图片解码 RGB 缓冲。一个 800x480 RGB565 的图层就是 750KB没有外部 RAM 根本玩不转。音频类录音缓存、播放双缓冲、蓝牙音频的 AAC / LDAC 解码中间缓冲。解码器本身就要堆几十到几百 KB 临时缓冲。网络与文件HTTP 响应处理、mongoose 这类 Web 库的请求缓冲、FTP / OTA 固件接收缓冲。你从网络下载一个 8MB 的升级包哪怕只做边收边写也需要一个足够大的滑动窗口缓冲。数据记录与运算传感器采样环形缓冲、电机控制里的参数矩阵、状态机历史数据、轻量级 AI 模型用的中间张量。以上任意一种场景只要叠加在一起片内 SRAM 都是不够的。有一段时间我需要在一颗主频 480MHz 的 MCU 上跑 VNC 远程桌面协议远端画面 1024x600 RGB565光帧缓冲就得 1.2MB全放 PSRAM 才能把性能做起来。没有 APS6404 这类芯片项目只能砍功能。1.3 给 MCU 扩内存的主流方案对比SRAM、SDRAM、PSRAM 谁合适扩内存的方案其实不止 PSRAM 一种我在选型时把这些方案都摆出来比过方案典型容量接口复杂度单价适用场景并行 SRAM如 IS62WV51216512KB-4MB需要 20-30 根 IO布线复杂中高对延迟敏感、不在乎引脚资源串行 SRAMSPI SRAM128KB-1MB简单4-6 根线中等小容量补充性价比一般SDRAM如 W9825G6KH16MB-64MBDDR 布线、时序复杂、需要控制器低大容量缓存但 MCU 大多没有控制器PSRAM如 APS6404512KB-8MB简单SPI/QPI低容量够大、引脚少、MCU 直接外挂并行 SRAM 的实时性好但是 32 引脚芯片一上去MCU 的引脚资源直接告急。SDRAM 容量大但多数 MCU 没有内置 SDRAM 控制器只能靠软件模拟或者干脆不支持成本不低。APS6404 这类 PSRAM 的优势在于接口就是 SPI/QPI随便什么 MCU只要能输出 SPI 时序就能驱动容量又做到 8MB足够覆盖绝大多数嵌入式应用价格放在那儿比同容量并行 SRAM 便宜一个数量级。它不能替代片内 SRAM 做极高速核心栈但这些对吞吐要求不那么变态的场景就是它的主场。2. APS6404 的特殊体质DRAM 内核SPI 之门2.1 型号逐段拆解APS6404L-SQH-SN 里的每个字母在说什么先照着芯片上的丝印把型号拆开方便你日后选型和采购APSAP Memory 的系列前缀。6404产品家族表示 64Mbit PSRAM即 8MB 容量。这个数字是固定容量标记不是随意的产品编号。L表示低功耗Low Power同时也对应 3.3V 供电版本。如果你看到型号里是 N 之类后缀要留意是不是 1.8V 版本电压搞错直接烧芯片。SQH封装与速度等级的组合这里指 SOIC-8 宽体封装。这类芯片还有 XQH、BGA 等封装选项SN 后缀一般代表卷带包装形式跟功能无关。同一颗 APS6404不管什么封装内部逻辑都是一样的 64Mbit PSRAM 内核区别只在于引脚数和包装形式。挑选的时候最需要关心的是电压版本和封装能不能在你的板子上贴片。2.2 命令集与 SPI Flash 的异同随机读写才是核心差异我知道很多同学第一次接触 PSRAM 会犯一个错误直接把 SPI Flash 的驱动改编过去以为命令差不多。这个思路有一半对另一半是坑。APS6404 的命令集确实和常见 SPI NOR Flash 有很多相似之处有读命令、有写命令、有读 ID 命令、有复位命令。但它和 Flash 最本质的区别是——写入不需要擦除。Flash 写数据之前必须按块/扇区将旧数据擦成 0xFF否则无法直接覆写这一擦就要几毫秒到几十毫秒和 RAM 的随写随用完全是两个概念。PSRAM 是随机存取器件你可以直接对任意字节地址执行写操作不需要任何擦除流程。同时它也支持连续突发读写。这样的特性决定了几个实际行为你可以把变量、结构体、对象数组直接放在 PSRAM 地址空间里指针操作照常用。写数据不会因为擦除等待而卡顿。读取可以任意跳转地址不像 Flash 按页和扇区组织得那么拘束。但要注意PSRAM 的底层是 DRAM 单元靠电容存储电荷所以必须周期性刷新。APS6404 内部集成了自刷新逻辑正常工作时不需要 MCU 参与刷新这是它和裸 DRAM 芯片最大的区别也是能通过 SPI 接口驱动它的前提。2.3 内部刷新机制对 MCU 侧时序的隐式要求虽然自刷新三个字听起来很省心但设计时仍然有几个隐性要求第一PSRAM 内部的刷新会让读写操作偶尔多等一个周期你实现驱动时不能假设每次读写的延迟都完全固定。对绝大多数系统来说这个额外等待时间是微秒甚至纳秒级的不会造成问题。第二进入深睡眠Deep Power Down模式之后内部自刷新会停止DRAM 内容全部丢失。退出深睡眠后不能假设原来的数据还在必须把整个内存当作未知内容处理。我在低功耗项目里通常的做法是休眠前主动将关键变量从 PSRAM 搬回内部 SRAM或者干脆只把可重建的缓存放 PSRAM。第三上电之后建议执行标准的复位序列确保内部状态机处于已知状态。这就像电脑开机要先复位外设一样跳过可能偶尔正常但你在量产时就会遇到神秘的初始化失败。3. 硬件连接与第一块样板SOIC-8 的接法、电容与电平3.1 引脚图与最小系统连接四线和 QPI 模式下的走线差异APS6404L-SQH-SN 的 SOIC-8 封装只有 8 个引脚布局和 SPI Flash 几乎一致常看 Flash 接线的工程师会觉得非常眼熟。典型接法如下引脚号名称功能接法1CS#片选接 MCU GPIO低有效2SCLK时钟接 MCU SPI 时钟3SI / SIO0数据输入 / 双向数据 0接 MCU MOSIQPI 模式为双向4SIO2双向数据 2QPI 模式使用接 MCU 普通 GPIO 或复用 IO5VSS地接 GND6SO / SIO1数据输出 / 双向数据 1接 MCU MISOQPI 模式为双向7SIO3双向数据 3QPI 模式使用接 MCU 普通 GPIO 或复用 IO8VDD电源接 3.3V如果只用标准 SPI 模式第 4 脚和第 7 脚可以不接悬空即可。但是如果你后面想切到 QPI 模式四个 IO 同时收发必须把 SIO2、SIO3 都连到 MCU 上并且这两个引脚要支持双向 IO不能只用普通输出。从布线角度看标准 SPI 模式对时序要求不算苛刻几根线随便连都能跑。但一旦把时钟拉到 80MHz 甚至更高SCLK 和 SIO 线的走线就应该尽量短、等长、少打过孔并且避免靠近电机驱动、电源开关这类高噪声源。我在一块四层板上把三颗 PSRAM 排成一行时钟线统一走了 3mm 等长线实测高频读取稳定很多。3.2 电源与去耦一颗 100nF 的讲究很多人外挂 PSRAM 只关注信号线电源处理得过且过结果系统高频读写时偶发数据错误查半天才发现是电源毛刺。DRAM 内核在突发读写时电流变化非常快如果 VDD 旁路电容不够电压塌陷就会直接导致内部逻辑错误。我的标准做法是VDD 引脚附近并一颗 100nF 陶瓷电容再在板级电源入口处并一颗 4.7uF 到 10uF 的钽电容或者陶瓷电容。100nF 负责高频瞬态响应大电容负责平均电流补偿。电源走线尽量宽不要用细线绕很远。另外注意 APS6404L 是 3.3V 版本如果你的 MCU IO 电平是 1.8V或者 PSRAM 被接在 1.8V 电源域要么换 1.8V 版本要么加电平转换芯片。我曾经把 3.3V 版本接到 2.8V 供电的 MCU 上芯片能工作但偶尔读 ID 失败后来细查才发现是电压长时间低于 3.0V 下限导致的。3.3 常见 MCU 平台的接线差异STM32、GD32、ESP32 与 RP2040 的侧重点不同 MCU 驱动 APS6404 的侧重点不一样我分别说下STM32 系列如果你选的型号带 QUADSPI可以直接用 QUADSPI 外设接 PSRAM速度最快还能做 Memory-Mapped 映射。如果没有 QUADSPI就用普通 SPI 两个 GPIO 模拟 SIO2/SIO3跑 QPI 模式时手动控制方向。GD32 的参考 STM32 移植很顺手但注意它的 SPI 时钟极性寄存器和 STM32 在细节上有差异照抄驱动前先确认时序参数。ESP32 系列ESP32 原生支持外挂 PSRAM芯片型号通常叫 ESP32-WROVER 模组里面已经接了 APS6404 之类的芯片。如果你自己设计板子直接使用 ESP-IDF 的 SPIRAM 支持把 Kconfig 里的 SPIRAM 打开然后把 malloc 策略配置为允许使用 PSRAM 即可。这里最大的坑是 GPIO 冲突PSRAM 的时钟线和某些模组的 Strapping Pin 可能有冲突最好对照手册仔细选引脚。RP2040树莓派 Pico 虽然片内只有 264KB SRAM但它有丰富的 PIO 控制器完全可以用 PIO 程序模拟 QPI 时序。我见过有人用 PIO 把 APS6404 跑到 60MHz 以上但实现复杂度比普通 SPI 高很多非必要不建议新手折腾。从硬件设计的角度看务必要关注 MCU 复位和启动期间的 GPIO 状态。如果复位期间 CS# 引脚是悬空或者被拉低PSRAM 可能会收到莫名其妙的命令片选信号进入不可预期状态。我的做法是在 CS# 上接一个 10kΩ 上拉电阻到 3.3V保证 MCU 初始化完成之前片选一直处于高电平。4. 驱动从零移植初始化序列、单线 SPI 与 QPI 切换4.1 驱动骨架设计把 SPI 收发抽象成三个函数写 PSRAM 驱动前我先把底层 SPI 收发抽象成三个基础函数这样换平台只改这三个函数上层读写逻辑完全不变。抽象层级大致这样psram_spi_byte_out(uint8_t val)发送一个字节不做接收。psram_spi_byte_in(void)发送空字节并读取一个字节。psram_spi_transfer(uint8_t val)同时发送和接收一个字节半双工场景下很常用。这三个函数可以在硬件 SPI、软件模拟 SPI 或者 DMA 环境下分别实现驱动主体只关心命令和地址的组合。为了兼容 QPI 模式我还会再加一个抽象如果启用四线模式那么每次收发都以半个字节为单位也就是 4 个 bit。一个 8 位命令需要连续调用两次 4-bit 传输。但这里有一个实现细节在标准 SPI 模式下一个字节的收发是 8 个时钟而 QPI 模式下一条命令是 8 个 bit 但每个时钟周期传输 4 bit所以一条命令只占 2 个时钟周期。有些 MCU 的 SPI 外设不支持这种半字节粒度传输那就需要改成 GPIO 手动翻转或者用每个时钟周期操作一个 nibble 的 PIO/DMA 方案。4.2 上电复位与 ID 校验先把活着这件事确认掉APS6404 上电后内部状态并不是完全确定的我的驱动初始化序列第一件事就是复位static void psram_reset(void) { psram_cs_low(); psram_spi_byte_out(0x66); // Reset Enable psram_cs_high(); psram_spi_delay_us(10); psram_cs_low(); psram_spi_byte_out(0x99); // Reset Memory psram_cs_high(); psram_spi_delay_us(150); // 等待复位完成建议比数据手册典型值留余量 }复位之后我会读 Device ID确认接线和芯片状态都正确。APS6404 的 Read ID 命令是 0x9F后面跟 3 个空字节读回两个字节。正常情况能读到制造商 ID 和芯片 ID 的组合。有些平台读到全 0xFF 或者全 0x00那几乎是硬件问题——供电、焊接、引脚方向先查这些再查软件。我习惯在驱动初始化里加上一个显式的 ID 校验失败处理不然硬件接反的时候你会在内存崩溃里浪费半天时间。4.3 从标准 SPI 切到 QPI模式和后续指令的规则陷阱初始化阶段我们用的是标准 1-bit SPI 模式因为 MCU 默认的 SPI 外设只能按字节收发切 QPI 是在复位和 ID 确认之后才做的。切换 QPI 的具体命令号建议以你手上实际芯片批次的手册为准。我要讲的是这个切换过程中的规则陷阱一旦进入了 QPI 模式后续发出的所有指令都要按 4-bit 方式传输包括读 ID、复位、深睡眠退出一个都不能漏。很多同学切完模式之后继续用 1-bit 方式发命令等于在和芯片鸡同鸭讲然后整颗内存表现成能读能写但数据错乱或者干脆没反应。所以 QPI 驱动里所有命令发送函数必须做分流或者干脆封装一个当前模式宽度的全局变量让每个收发函数都根据这个变量决定是按 1 字节还是按 2 个 nibble 来驱动。这样其他地方不需要关心模式状态只需要保证初始化完成前把全局变量设好。还有一个容易被忽略的点切换 QPI 模式之后CS# 的电平时序要求会更严格。有些命令在 QPI 模式下需要额外的 dummy 周期或等待周期手册里的时序图一定要对照着看别只凭经验猜。4.4 读写接口实现突发长度、对齐和 DMA 友好的设计PSRAM 的基本读写命令和 Flash 非常像读命令后面跟 24 位地址然后连续读数据写命令后面跟 24 位地址然后连续写数据。区别还是那句老话——写不需要擦除。一个简单的随机读函数长这样void psram_read(uint32_t addr, uint8_t *buf, uint32_t len) { if (psram_mode PSRAM_MODE_QPI) { psram_cs_low(); psram_qpi_cmd_write(0x0B); // QPI 模式下的高速读命令 psram_qpi_addr_write(addr); // 24 位地址 psram_qpi_dummy_read(); // dummy 周期 for (uint32_t i 0; i len; i) { buf[i] psram_qpi_byte_read(); } psram_cs_high(); } else { psram_cs_low(); psram_spi_byte_out(0x03); // 标准读命令 psram_spi_byte_out((addr 16) 0xFF); psram_spi_byte_out((addr 8) 0xFF); psram_spi_byte_out(addr 0xFF); for (uint32_t i 0; i len; i) { buf[i] psram_spi_byte_in(); } psram_cs_high(); } }地址是 24 位因为 8MB 空间需要 23 位地址线官方规格把 24 位地址统一处理最高位在标准模式下补 0切 QPI 之后按手册走。如果数据量很大我建议用 DMA 来搬运而不是 CPU 一字节一字节地读。此时要注意缓冲区地址对齐DMA 接收缓冲通常要求 4 字节对齐如果不对齐DMA 可能触发总线错误或者性能陡降。我通常用__attribute__((aligned(4)))或者memalign来申请。另外突发长度也是一个影响性能的参数。APS6404 支持设置突发长度比如 32 字节、64 字节或连续模式。连续模式下可以一次性读完整个 8MB但是跨越某个内部页面边界时不同批次芯片的行为略有差异。我一般选择混合突发写 固定 64 字节读这种组合既保证单次传输足够大又不容易在跨页处出问题。突发配置命令在初始化时执行一次即可后续读写都是线性地址。5. 实测数据不说谎带宽、延迟和 DMA 配合5.1 测试方法别用感觉用逻辑分析仪和定时器我给 PSRAM 做性能评估时不会只靠感觉挺快来下结论而是把测试做成分离变量固定一块 256KB 的缓冲分别用 1-bit SPI 模式和 QPI 模式做顺序读、顺序写、随机 32 字节读、随机单字节读然后用逻辑分析仪抓 SCLK 和 CS# 波形同时用 MCU 内部定时器记录总耗时。逻辑分析仪的作用不是测数据内容而是看 CS# 的占空比。理想情况下你希望 CS# 保持低电平的时间尽量长因为每一次 CS# 拉高再拉低都要付出命令地址的传输开销。随机单字节读的时候CS# 可能在总时间里的占比很小大部分时间都花在命令地址dummy这些固定开销上。定时器测总耗时的好处是很直观而且可以用同一份代码在不同主频、不同 SPI 分频下反复测形成一条时钟频率 vs 实际吞吐的曲线。5.2 SPI 模式与 QPI 模式的实测吞吐对比我这里给出一组基于 40MHz 时钟和 80MHz 时钟的典型数字不同板子略有差异但趋势很稳定场景SPI 模式 40MHzQPI 模式 80MHz顺序读大块约 4.5-5 MB/s约 28-32 MB/s顺序写大块约 3.5-4.5 MB/s约 15-18 MB/s随机 32 字节读约 2.5 MB/s约 8-10 MB/s随机单字节读约 0.8 MB/s 以下约 2-3 MB/s你看QPI 模式下顺序读的吞吐可以做到比标准 SPI 模式快 6 倍左右这是因为每个时钟周期传输 4 位同时时钟频率还可以提得更高。顺序写的性能比读要差这是 PSRAM 内部写时序决定的做设计时要留出余量别按读速度估算写性能。随机单字节读是性能最差的场景因为每一次操作都要完整走一遍命令地址的开销。如果应用里有大量这种零碎访问模式比如通过指针链表遍历把这块内存当普通 RAM 用那性能堪忧。所以我通常会建议应用层对大块缓冲做顺序访问或者把 PSRAM 定位成大数据缓冲而不是替换片内 SRAM。5.3 CPU 占用对比轮询、DMA 与外部存储的交互只用 CPU 轮询读写 PSRAM 时CPU 会全程占满因为在数据搬运完成前代码都卡在 SPI 发送循环里。特别是 8MB 级别的大块传输如果每秒要搬几百 KB 到几 MBCPU 基本没时间干别的事情。改成 DMA 模式之后CPU 只需要发起一次传输然后等待完成中断中间可以去跑任务调度、处理传感器数据或者刷新网络协议栈。整个系统吞吐和响应速度都会上一个台阶。不过 DMA 也有新的坑如果你的 MCU 有两个内核或者多个外设共享 DMA 控制器PSRAM 的大块读写可能会抢占其他外设的 DMA 请求导致音频断流或者网络丢包。这时候我通常把 PSRAM 的 DMA 通道优先级调低一点或者对 PSRAM 访问做分片搬运——一次最多搬 16KB搬完主动让出总线再搬下一段实测对实时性更友好。还有一个小提醒如果你的 MCU 支持缓存Cortex-M7 内核对 QSPI 映射空间可能有 cache启用缓存后读性能会好看很多但写数据之后要小心 cache 不一致——需要手动 clean 或者 invalidate。很多读正常、写完之后读旧数据的诡异问题都是这里造成的。6. 实战踩坑记录这块芯片最容易翻车的五个场景6.1 坑一上电后不读 ID 直接写偶发数据错乱这个问题我帮一个客户排查过整整两天。现象是板子 90% 时间工作正常但低温或者上电瞬间偶发内存数据错乱表现为界面花屏。对方的代码里直接省略了初始化上电后就把 PSRAM 当普通数组往里面写。根因就是芯片上电状态未确定。虽然 PSRAM 内部会自动初始化但 DRAM 的存储单元在电压建立过程中如果不执行标准复位序列个别扇区可能出现不可预期的逻辑状态。正确的做法就是我前面写的先发 0x66 0x99 复位等待至少 150us再读 ID 校验。这个 150us 是从手册典型值加了一倍余量不要压缩到临界值。不要偷懒跳过这步。量产时你会发现 2% 的板子复位不干净排查起来远比多写三行代码痛苦。6.2 坑二CS 拉低后 SCLK 反相 / 抖动引发时序灾难第二次踩坑是在一个软件模拟 SPI 的实现里。我为了让代码简洁先拉低 CS#再去配置 GPIO 方向、拉高 SCLK结果发现 PSRAM 偶尔读出来的数据会错位。原因是软件模拟 SPI 时CS# 拉低到第一个有效 SCLK 上升沿之间需要满足芯片手册要求的建立时间。我在 GPIOC 操作里插入了不必要的延时或者顺序颠倒导致 SCLK 在 CS# 拉低后出现了几个无用的毛刺时钟PSRAM 把这些毛刺当成了命令位整个命令流自然错位了。用硬件 SPI 外设时这个坑基本不存在因为 CS# 由外设控制时序有保障。用 GPIO 模拟时务必遵循先准备好数据线电平再拉低 CS#再开始产生时钟结束传输时先撤时钟再拉高 CS#这个顺序。如果实在手忙脚乱最稳妥的方案是直接启用硬件 SPI别自己模拟。6.3 坑三低功耗唤醒时间被低估低功耗项目里我用深睡眠模式来省电进入深睡眠后电流能降到个位数 uA这对电池供电很友好。但我第一次做低功耗切换时唤醒后直接继续用 PSRAM结果数据全乱了。查了手册才发现从深睡眠回到正常模式需要一定的唤醒时间而且唤醒过程中 PSRAM 内部重新初始化 DRAM 阵列存储的内容直接丢失。所以正确的策略是睡眠前丢弃 PSRAM 内容把它当成临时缓存用完就走唤醒后必须重新执行初始化序列并且重建所有放在 PSRAM 里的缓存数据。如果是靠外部中断唤醒的系统建议在 RTOS 的恢复 hook 里把 PSRAM 初始化放在最高优先级因为后面每个任务都可能访问它一旦没初始化完成就开始读写整个系统会陷入难排查的随机错误。6.4 坑四malloc 大块内存的地址对齐与跨页边界问题用 C 语言的malloc从 PSRAM 堆里分配内存时看起来一切正常但实际暗藏两个问题。第一是地址对齐。默认的malloc可能返回 8 字节对齐的地址但你要把这块内存作为 DMA 缓冲、FIFO 缓冲或者图形 framebuffer 时往往需要更高对齐比如 16 或 32 字节。我踩过 DMA 缓冲地址没对齐导致的外设总线错误后面统一用aligned_alloc或者自定义的 32 字节对齐分配器。第二是复合结构与跨页行为。如果你分配一个大数组跨越了 PSRAM 内部页边界在高频读写下一次 DMA 传输可能被切割成两个内部事务中间插入刷新周期导致瞬时延迟变大。对于实时性要求高的大块缓冲我建议按页大小对齐分段使用。比如内部页边界是 1KB你就把大缓冲切成 1KB 的分块每块独立管理互不影响。这个坑不影响正确性只影响达峰性能但在做高性能采集时差异非常明显。6.5 坑五与 SPI Flash 共用总线时的设备冲突有些低成本板子为了省引脚会把 PSRAM 和 SPI Flash 挂在同一条 SPI 总线上用不同的 CS# 来区分。这个思路本身没问题但注意两个细节。一是 MISO 线上的高阻态。PSRAM 在 CS# 拉高之后就释放数据线Flash 同理但如果有一个器件在设计上对 MISO 的上拉电平敏感而另一个器件残留了下拉驱动总线会出现短暂冲突。最好在 MISO 上接一颗 4.7kΩ 上拉电阻保证两个器件都不驱动时总线电平稳定。二是时钟频率不能按单器件的最大能力来设。有些 SPI Flash 在 100MHz 下非常稳定但 PSRAM 在这个频率下时序裕量不足有些又反过来。既然共用了总线只能取双方都稳定的公共频率例如 80MHz 或 66MHz别盲目拉高。性能虽然少了一点但换来的是长期稳定性。如果项目允许我更建议给 PSRAM 独立一组 SPI 接口尤其是频繁读写 PSRAM 的图形和音频应用。共用总线切换频繁时总线换主/换片选的开销会抵消掉一部分 QPI 模式带来的性能优势。7. 往项目里落地的建议调度策略、内存分区与扩展思路7.1 在 RTOS 环境里给 PSRAM 划定独立堆把整颗 PSRAM 全塞给系统默认的malloc是不太聪明的做法。我在工程里通常为 PSRAM 单独开一个堆空间由独立的内存管理模块负责和片内 SRAM 分开。最简单的做法是在 PSRAM 地址空间里划出一块固定区域#define PSRAM_BASE_ADDR 0x90000000 // 映射基地址按具体 MCU 调整 #define PSRAM_HEAP_SIZE (6 * 1024 * 1024) static uint8_t psram_heap[PSRAM_HEAP_SIZE] __attribute__((section(.psram_heap)));然后用一个专门的 heap 管理器比如 FreeRTOS 的 heap_4、或者移植一个简化版 TLSFTwo-Level Segregated Fit把这段内存变成可分配的堆。这样做的最大好处是片内 SRAM 留给任务栈和实时性要求高的数据PSRAM 堆只分配给那些大但可以容忍少量延迟的缓冲。另外如果使用 FreeRTOS 和 STM32 的 MPU记得给外部 PSRAM 区域配置正确的内存属性避免 cache 或总线访问权限问题。7.2 典型组合LVGL 显存、音频缓冲与 mongoose 协议栈共存一个非常典型的组合是MCU 内部 SRAM 跑 RTOS 核心任务外挂 8MB PSRAM 同时扛起图形、音频和网络。我最近的项目就这么分配LVGL 显存分配 3 个全屏 framebuffer800x480 RGB565每个 750KB三个共 2.2MB 左右。一个用于当前帧合成两个用于双缓冲切换。这样 UI 动效非常顺滑。音频缓冲16KB 输入录音环 32KB 播放环 64KB 解码中间缓冲共约 112KB。mongoose Web 库HTTP 请求解析缓冲、WebSocket 发送缓冲、固件升级接收窗口共约 256KB。剩余 3MB 左右作为通用文件缓存和临时运算空间。这个组合如果全放片内 SRAMCPU 根本不可能有剩余资源跑别的但放进 PSRAM 之后UI 刷新和网络服务可以并行跑不会再互相抢内存。有一点需要提醒mongoose 这类库跑在 MCU 上时代码段尽量还是放片内 Flash数据缓冲放 PSRAM 没问题但如果某个库内部大量用全局函数指针、链表遍历、频繁的小缓存分配要接受 PSRAM 随机小访问的延迟最好做一层缓冲抽象。7.3 下一步还能怎么玩内存映射、并行多颗与更深的优化思路如果你用的 MCU 带 QUADSPI 并支持 Memory-Mapped 映射可以把 APS6404 映射到 MCU 的地址空间里然后用指针直接访问。这等于给 MCU 加了一整块可按字节寻址的外部 RAM代码上几乎不用改。但注意映射模式的读性能和 QPI 直通模式略有差别而且写操作可能需要关闭 cache 或者执行 clean 操作。如果 8MB 还不够用可以用两片一样的 APS6404通过两个独立 CS# 接在同一个 QSPI 总线上地址译码后拼成 16MB。我在一个需要做两天波形记录的设备上就是这么干的代码上只需要按地址是不是高于 8MB 来切换 CS#其他逻辑完全不变。更深的优化思路包括结合 DMA 双缓冲实现无间断数据采集、利用 PSRAM 的突发模式配合图形控制器做连续刷屏、以及按块组织数据把随机访问变成顺序访问。每一次优化做完之后记得用定时器和逻辑分析仪量化对比只有数据真实改善了才是有效优化。我个人现在做项目时的习惯是收到需求后先估算峰值内存只要超过片内 SRAM 的 60%就直接默认加一颗 PSRAM。这样做的好处是后面加功能、加缓冲、加协议栈的时候不会再因为内存不够而砍需求开发节奏反而更快了。用一颗 APS6404L-SQH-SN 换来的设计裕量绝对值回票价。
)
