做了这么久的DSP开发如果你还停留在“程序烧进Flash能跑就行”的阶段那我建议你一定要试试把关键代码挪到RAM里跑一次。不用多就找一个高频中断里的控制算法或者一段每次循环都要跑的FOC变换改完以后再量一下执行时间那种从几百纳秒掉到几十纳秒的落差感真的会让你上瘾。TMS320F28377D这颗双核C2000系列DSP主频拉到200MHzFlash取指却要插等待周期。本来算力就够猛结果大部分时间都在等Flash响应这跟买了跑车却一直在市区堵着没什么区别。这篇文章就围绕F28377D的RAM运行程序这件事展开从CMD文件怎么配置、代码段怎么搬进RAM、启动复制怎么做再到双核场景下内存布局怎么优化把整个链路完整走一遍。不管是做电机控制、电源数字控制还是搞并网逆变器、实时信号处理只要你的算法里存在“跑得越快越好”的循环这篇内容都值得你花十分钟看完。1. 为什么程序在Flash里跑不快而RAM里能“飞”先把最核心的问题说透F28377D的CPU主频是200MHzFlash的读取速度却远远跟不上这个节奏。为了在低成本下实现大容量非易失存储这颗芯片的片内Flash在读取路径上做了等待周期wait state处理。也就是说CPU每次从Flash取指令都要插入若干个等待时钟周期芯片越新、Flash容量越大、主频越高等待周期往往越多。不要小看这几个周期的开销一条指令多等3到5个周期循环体一跑就是几万次、几十万次累积下来的性能损失非常可观。1.1 Flash取指的等待周期才是真瓶颈很多人调代码时喜欢用CCS里的profile功能去测量函数执行时间结果发现同样的代码有时候快有时候慢百思不得其解。其实很简单代码在Flash里跑取指有等待周期代码在RAM里跑零等待CPU全速执行。同一个函数RAM执行可能比Flash执行快3到5倍这完全取决于Flash配置的等待状态数和代码的流水线命中情况。我见过一个做数字电源的同行把PID调节器放在Flash里执行开关频率100kHz每个PWM周期进一次中断中断里做了三环控制加一堆保护逻辑。他说怎么优化都觉得时间不够用后来我让他把中断里三个关键函数全部搬进RAM结果整个ISR的执行时间直接砍掉了将近60%。从那以后他的板子再也没出现过“时间不够”的抱怨。这里有个容易忽略的点不仅是取指令慢如果代码里的常量表很大Flash读取常量同样要等。所以做内存布局优化的时候不光要考虑代码段还要考虑频繁访问的常量表。像FFT的旋转因子表、查表法用到的正弦表这些如果放在Flash里每次查表都有等待周期搬到RAM以后查表速度也是质的提升。1.2 哪些代码值得搬进RAM哪些留在Flash并不是所有代码都需要搬进RAM。RAM资源再大也是有限的F28377D虽然片上RAM有几百KB的规模但双核一分、数据缓冲区一占真正能拿来放代码的空间并不宽裕。我的经验是分三档来看第一档必须搬。高频中断服务函数、实时性要求极高的控制算法核心、查表密集型的处理函数、FFT蝶形运算这类每秒钟要跑几万次的热点代码优先放RAM。第二档可以搬。初始化代码、通信协议解析、配置寄存器之类的低频代码其实留在Flash里跑就行。反正就跑一次插入几百个等待周期也无所谓。第三档千万不要搬。体积巨大但调用频率极低的功能模块比如自检程序、Bootloader升级程序、很少触发的故障诊断逻辑这些放在Flash里能省出大量RAM给数据和堆栈使用。说白了RAM运行程序解决的是“热点路径加速”的问题不是让你把整个工程都塞进RAM。工程里动辄几十KB的代码真要全部搬进RAM内存布局优化就变成内存空间争夺战了。1.3 用GPIO翻转法快速量化性能收益在开始做RAM运行改造之前建议先量化一下当前程序的执行周期这样优化完才有对比数据。最土也最有效的方法是GPIO翻转测量法在待测函数的入口处把某个GPIO拉高出口处拉低然后用示波器看高电平持续的时间。这个方法比在CCS里打断点、看cycle计数器要真实得多因为它是实际运行在目标板上的数据包含了中断抢占、总线占用等真实因素。拿一个200MHz的MCU来说GPIO引脚一个翻转周期一般是几十纳秒测一个执行时间在微秒级别的函数精度足够。实测时要注意把GPIO翻转本身的开销减去也就是先测一个空的翻转函数耗时再做差值。我之前踩过这个坑测出来的数据偏大后来减去空翻转时间才拿到真实的执行周期。做性能优化没有精确测量做支撑很多决策都是靠猜。2. CMD文件RAM运行程序的地基很多新手拿到工程模板看着那一堆.cmd文件完全不敢动生怕改一行代码就链接报错。其实CMD文件没有想象中那么神秘它本质上是给链接器看的“内存分配图纸”。F28377D这类C2000芯片使用TI的链接器CMD文件通过两条核心伪指令告诉链接器芯片上有哪些可用的内存区域MEMORY以及编译生成的段SECTIONS分别放在哪块区域。理解了这个逻辑RAM运行程序就不再是玄学而是纯粹的工程配置问题。2.1 一条CMD里的两条伪指令MEMORY和SECTIONSMEMORY伪指令定义的是“物理内存池”。每一行都描述一块独立的存储区域关键是origin起始地址和length长度这两个参数确保它们和芯片手册里的内存映射完全一致。写错地址轻则链接报错重则程序跑飞。SECTIONS伪指令定义的是“逻辑段映射”。编译器生成的目标文件里包含很多有名有姓的段比如.text可执行代码、.const常量、.data已初始化全局变量、.bss未初始化全局变量、.stack系统堆栈、.cinitC语言全局变量初始化表。SECTIONS就是把这些段一个个指定到MEMORY定义的存储区域里。RAM运行程序的核心操作就是改SECTIONS里的映射关系把.text或者自定义的代码段从Flash区域挪到RAM区域。但这里藏着一个大坑上电瞬间RAM是空的代码搬过去之前必须有一段“搬运工”代码先把Flash里的内容复制到RAM。这段搬运代码本身必须在Flash里执行否则程序就没法启动了。2.2 看懂F28377D的内存地图F28377D的内存布局和普通MCU不太一样它是双核架构内存被划分成三大块。第一块是CPU1和CPU2各自的局部RAMLocal RAM。每个核都有自己的M0/M1各1KB以及LS0到LS5每块2KB等区域这些RAM只能被对应的CPU核访问访问速度最快适合放中断向量表、实时性要求最高的代码和栈。第二块是共享RAMGlobal RAM简称GS。F28377D有GS0到GS15共16块每块4KB总容量64KB。这些RAM可以通过MEMCFG寄存器配置归属要么给CPU1要么给CPU2还可以配置成双方共享但要小心访问冲突。这个区域是双核协作时数据交换和信息共享的场所也是内存布局优化最需要花心思的地方。第三块是MSG RAM消息RAM专门用于双核之间的IPC通信配合IPC中断实现核间消息传递。真正常用的只有几十个字用来放邮箱、标志位、命令字。做内存布局优化脑子里始终要绷着一根弦自己用的数据放到自己核的局部RAM双核协作的数据才放到GS RAM而且一定要明确归属权。否则一个核往GS RAM里写数据另一个核不知情也去写最后数据错乱得莫名其妙排查起来非常痛苦。2.3 一个思路清晰的RAM运行CMD示例下面是一个简化版的CMD写法展示了如何把代码段和数据段从Flash映射到RAM。实际工程中还有Flash启动模式和RAM启动模式的区别这里按最常用的Flash启动后搬运到RAM运行的场景来写。MEMORY { RAMLS0 : origin 0x008000, length 0x000800 RAMLS1 : origin 0x008800, length 0x000800 RAMLS2 : origin 0x009000, length 0x000800 RAMLS3 : origin 0x009800, length 0x000800 RAMLS4 : origin 0x00A000, length 0x000800 RAMLS5 : origin 0x00A800, length 0x000800 RAMGS0 : origin 0x00C000, length 0x001000 RAMGS1 : origin 0x00D000, length 0x001000 } SECTIONS { .text : RAMLS0 | RAMLS1 | RAMLS2 | RAMLS3 | RAMLS4 | RAMLS5 .cinit : RAMLS0 | RAMLS1 .stack : RAMGS0 .data : RAMGS1 .bss : RAMGS1 }这里的.text用了符号表示把代码段分割后依次填充到RAMLS0到RAMLS5这6块区域里。如果一段代码超过单块RAM的容量链接器会自动分割非常方便。.stack放在GS0是考虑到中断嵌套和函数调用可能对栈空间有较大需求4KB容量更从容。需要特别说明的是如果在这个CMD文件里只改了SECTIONS映射、没有写启动复制代码那烧进Flash之后程序大概率跑飞。因为CPU一上电就去Flash执行遇到从RAM地址取指的跳转指令时对应RAM里还没有任何代码PC直接跳到非法地址。这个坑我当年踩得特别深后续章节会详细讲解启动复制的完整写法。3. 三步把函数请进RAM从ramfunc段到启动复制现在进入重头戏怎么把函数真正放到RAM里去执行。TI的C2000编译器提供了好几种方法我按推荐优先级来介绍你可以根据自己的工程结构选择最顺手的一种。3.1 方法一链接器选项--ramfuncon最省事TI的编译器包括CCS里集成的TI CGT提供了一个非常直接的链接器选项--ramfuncon。加上这个选项以后链接器会自动把所有函数代码.text段的加载地址放在Flash运行地址放在RAM并在启动阶段自动完成复制。在CCS工程里右键项目属性进入Build - C2000 Linker - Advanced Options找到--ramfuncon勾上就行。用命令行编译的话在链接命令里加上这个参数也一样。这个选项的优点是省心适合第一次做RAM运行改造的人。缺点是不加区分所有函数都会被搬进RAM包括那些低频的初始化函数RAM占用偏大。如果你的工程规模不大RAM资源充足直接用这个选项最简单。不过要注意--ramfuncon对应的是“全量搬运”思路它依赖编译器自动生成一段启动复制代码到cinit流程里。如果链接后RAM空间不够编译器会报“段超出范围”的错那时再用SECTIONS手动拆分也不迟。3.2 方法二__ramfunc__关键字精准投放只希望部分关键函数放进RAM时可以用TI编译器提供的__ramfunc__关键字。在函数定义前加上这个修饰符编译器就会把该函数单独放到.text的ramfunc子段中再结合CMD文件的段映射让它只在RAM中执行。__ramfunc__ void FOC_Update(void) { // 高频执行的核心控制代码 }这种方式精准、灵活但有个隐藏成本你需要保证那些从Flash复制到RAM的代码启动时确实被复制过去了。__ramfunc__本身不负责复制复制动作要么靠编译器自动生成的初始化流程要么靠你手动写复制代码。在TI的很多官方工程里你会看到这样的组合在程序开头调用memcpy函数把定义在Flash里的ramfunc段复制到RAM对应区域。同时配合#pragma和链接器生成的符号手动完成搬运工作。这个方法在DSP/BIOS或SYS/BIOS工程里尤其常见因为RTOS环境下的启动顺序更复杂很多时候不能依赖默认复制流程。3.3 方法三手动建段与启动复制完全掌控这个方法最灵活也最透明是我个人最推荐的方式。步骤如下第一步在源文件里用一个段声明把需要放进RAM的函数圈起来。C2000的TI编译器支持直接用#pragma把一个函数放到指定段。#pragma CODE_SECTION(fast_loop, .ramfuncs) void fast_loop(void) { // 高频算法 }第二步在CMD文件的SECTIONS里增加对.ramfuncs的映射SECTIONS { .ramfuncs : LOAD FLASH_RAMFUNC, RUN RAMLS4 | RAMLS5, LOAD_START(_ramfuncsLoadStart), LOAD_END(_ramfuncsLoadEnd), RUN_START(_ramfuncsRunStart) }这里的LOAD和RUN是两个地址概念LOAD地址是代码在Flash中的存放位置RUN地址是代码实际执行时的RAM位置。链接器会帮你生成三个符号分别表示待搬运代码的Flash起始地址、结束地址、RAM目标起始地址。第三步写一段搬运代码放在main函数最前面extern uint16_t ramfuncsLoadStart; extern uint16_t ramfuncsLoadEnd; extern uint16_t ramfuncsRunStart; void copy_ramfuncs(void) { uint16_t *src ramfuncsLoadStart; uint16_t *dst ramfuncsRunStart; uint16_t length (uint16_t)ramfuncsLoadEnd - (uint16_t)ramfuncsLoadStart; while (length--) { *dst *src; } }这段代码本身留在Flash里执行先把Flash中的.ramfuncs内容逐字复制到RAM复制完成后main里再调用fast_loop时实际取指地址就在RAM了。这里的指针类型定义为uint16_t是有讲究的因为C2000的内存最小可寻址单元就是16位字用uint16_t做指针单位长度计算才不会出错。如果你按字节指针来搬地址会翻倍复制出来的东西全错。3.4 上电第一现场为什么需要一段“搬运工”代码很多读者可能还是好奇RAM比Flash快为什么不让程序直接从RAM启动非得先跑一段Flash里的搬运代码因为RAM是易失性存储掉电内容就丢了。芯片上电复位的瞬间RAM里全是随机值只有Flash里的程序是可靠的。CPU的启动流程必然是从Flash或Boot ROM开始执行然后把需要高速运行的代码搬到RAM再跳转到RAM里执行。这个过程和电脑开机时BIOS先从ROM加载、再把操作系统搬运到内存运行的道理一模一样。DSP里的那段搬运代码本质上就是一个微型加载器。理解了这一层你就能明白为什么CMD文件里LOAD地址和RUN地址必须分开写也能理解为什么搬完代码之后不能立刻把Flash里的代码擦掉重写因为如果复位后Flash里已经空了搬什么都搬不出来。4. 双核内存布局优化实操F28377D最有魅力的地方是双核架构但这也是内存布局最需要花心思的地方。两个核同时跑共享RAM的管理稍有不慎就会出现数据错乱、性能下降甚至死锁。这个章节聊一下双核场景下RAM运行程序的内存布局优化。4.1 双核内存地图局部RAM、共享RAM和MSG RAM怎么配合F28377D的两个核每个核都有自己的局部RAM访问延迟最低这是摆放敏感代码和数据的第一选择。但局部RAM容量有限所以共享RAMGS的分配策略至关重要。GS0到GS15这16块RAM每一块都可以单独配置归属权。通过MEMCFG寄存器你可以把GS0到GS7配置给CPU1把GS8到GS15配置给CPU2也可以把某一块配成可读写共享。做双核协作项目时我的经验是遵循一条黄金法则能放局部RAM就不放共享RAM共享RAM只放必须跨核交互的数据。比如两个核都要读传感器原始数据那传感器数据缓冲区放在共享RAM合理如果某份数据只属于CPU1的内部处理链路那就坚决放到CPU1的局部RAM里这样CPU2无论如何都不会踩到它省去很多同步和保护逻辑。MSG RAM则是专门为核间消息设计的里面有发送寄存器和接收寄存器配合IPC中断使用。适合传递短小精悍的指令和状态不适合大数据搬运。大数据搬运应该走DMA加共享RAM而不是靠核间中断逐个字传。4.2 数据摆位高频变量、中断栈、巨型缓冲区的归属原则做内存布局优化时我会按这个优先级给数据“分房”最高优先级给高频访问的全局变量。这些变量如果放在共享RAM里两个核抢总线会引入额外的仲裁延迟所以一定要放在本核局部RAM。次高优先级给中断服务程序的栈空间。F28377D进入中断后会用系统栈保存现场如果栈放在外部接口或共享RAM中断响应延迟会增大。把栈放在本核的局部高速RAM里中断响应速度才有保障。再次给大块缓冲区。比如ADC采样缓冲、通信收发缓冲这类数据容量大但对访问延迟不敏感可以放在共享RAM里。通过DMA搬运还能减轻CPU负担。要注意缓冲区对齐DMA传输对地址对齐有要求一般建议32位甚至64位对齐。最后给查表用的常量表。FFT的旋转因子、正弦表这类数据量不大但访存密集的常量放在局部RAM能显著提速。但要注意RAM空间有限不要因为放置大表导致栈空间缩水。4.3 优化实例一个FFT算法在双核上的内存划分假设你现在要在F28377D上做一个实时FFT频谱分析输入1024点ADC采样数据要求两个核协同处理。先看一个不太合理的初始布局ADC采样缓冲区放在CPU1的局部RAMFFT旋转因子表放在CPU2的局部RAM输出结果放在共享RAM。这样CPU1要处理数据时旋转因子表在CPU2的RAM里跨核访问性能极差而且访问自己的局部RAM时还要担心数据安全性。优化后的布局应该是这样ADC采样缓冲区放在共享RAMGS0CPU1和CPU2都能通过DMA访问旋转因子表复制两份分别放到CPU1和CPU2各自的局部RAM这样每个核跑FFT时查表都不需要跨核中间计算结果放在本核的局部RAM只有最终频谱结果放到共享RAMGS1方便上位机读取。这个例子看起来很简单但实际做布局时你会发现自己需要反复权衡旋转因子表复制两份会多占一份RAM但换来的性能提升非常明显。在双核性能敏感型应用里用空间换时间往往是最划算的选择。4.4 内存保护配置别忽略C2000系列有内存保护单元可以配置某些内存区域只被特定主设备访问。GS RAM可以通过MEMCFG配置归属权配合相应的保护寄存器让不该访问这个区域的核在尝试访问时直接触发异常。很多人在双核调试时遇到的现象是CPU1正常运行CPU2跑飞或者程序在某个地址上执行时突然弹出一个“Access violation”异常。这种问题十有八九是内存保护配置没做好某个核踩了不该踩的区域。调试双核内存问题我的建议是先把保护全部打开这样越界访问会立刻暴露出来等程序稳定了再根据性能需求适当放宽某些区域。千万不要从头到尾都关着保护跑那样等于蒙着眼睛开车出了问题只能靠猜。我自己的开发流程里上电第一件事就是写RAM自检参考的正是热词里那个memtest的思路。为什么这么重视因为我吃过亏有一块板子新贴回来代码编译链接全部正常一上电就跑飞查了半天找不到原因。后来用示波器和调试器挨个地址读写才发现是NAND Flash附近一块RAM的地址线有弱短路属于PCB制造缺陷。从那以后我在自己的项目模板里固化了一个RAM自检函数在main函数初始化阶段跑一遍专门检测RAM地址线是否有粘滞位stuck bits。自检思路不复杂先对RAM的每个地址写入规律数据再读回校验比如依次写入0x5555和0xAAAA这类交替数据然后交换地址线组合再写再读就能定位到哪一根地址线有问题。实际产品里这个自检虽然不会每次都跑但开发调试阶段开着帮我挡掉过很多硬件问题。这里也给刚开始接触F28377D的读者提个醒CMD文件这个东西和你平时在Windows命令行里双击执行的.cmd批处理脚本完全是两码事。在论坛上搜问题的时候如果看到“win11无法运行cmd文件”或者“cmd怎么运行py文件”这种内容那就是Windows系统脚本的求助帖和DSP一点关系没有。别搞混了前者是给用户敲命令用的批处理后者是给TI链接器看的内存分布图。5. 常见问题与排查技巧实录这部分内容都是我自己或者身边同事在F28377D平台上真实踩过的坑整理成速查表希望对你有帮助。问题现象根本原因排查方法程序烧进Flash后上电跑飞仿真却能跑缺少启动复制代码代码在RAM里是空的检查CMD的LOAD/RUN地址确认复制函数执行函数执行时间没变快代码段实际还在Flash里执行用map文件确认.text段落在哪块内存链接时提示段超出范围分配给RAM段的代码或数据量超出RAM容量减少搬入RAM的函数或者把数据搬到GS RAM双核交互时共享数据偶尔被篡改GS RAM归属权没有正确配置检查MEMCFG确保每个核只写自己拥有的区域中断里跑得好好的主循环里却出现问题栈溢出检查栈段是否放到了不合适的RAM区域增大栈容量复制后函数指针乱跳复制长度计算错误字节和字搞混确认使用uint16_t指针长度按字计算查表数据偶尔出值不对常量表被放在未被复制的RAM区域把常量表段放到正确的FLASH映射并增加复制逻辑5.1 上电跑飞问题为什么仿真却正常这是RAM运行程序新手最常遇到的怪现象在CCS里连接仿真器下载完程序后单步运行一切正常但只要目标板断电重新上电程序就飞了。原因非常简单仿真下载时调试器会把代码直接从PC端写到RAM里程序员肉眼看到的是“RAM里有代码”所以能跑。断电后RAM清空上电时没有任何东西帮你把Flash里的代码复制过来自然就跑飞了。解决办法就是前面讲到的启动复制代码。如果你用的是--ramfuncon一定要确认编译器自动生成的复制表代码真的被包含在了启动流程里如果你手动写的CMD加COPY函数一定要确认COPY函数本身能在上电第一时间被执行而且它自己所在的段必须在Flash里不能被搬走。5.2 查map文件定位段最终落在哪里我调试CMD问题最多的手段就是打开编译后生成的.map文件搜索对应段名看它最终放在哪个内存区域。比如你给.text配的RUN地址是RAMLS4但在map文件里看到.text还在Flash区域说明你的CMD映射没生效或者被某个默认的linker.cmd文件覆盖了。CCS工程里经常有多个CMD文件同时参与链接顺序不一样优先级也不一样。有时候你自己写的CMD没问题但工程模板里还有一个2806x_RAM_lnk.cmd没删掉两个CMD打架结果就是莫名其妙的地址错乱。我的习惯是链接完成后第一件事打开.map文件搜一下.text和.ramfuncs确认LOAD地址在Flash、RUN地址在RAM然后再跑性能测试。不检查这一步后面所有的优化都可能在白费力气。5.3 内存对齐问题别在没对齐的缓冲区上跑DMAF28377D的DMA模块对源地址、目的地址、传输字宽都有对齐要求。如果你把一个全局数组定义在共享RAM里没有做任何对齐声明直接把这个数组地址交给DMA很有可能触发对齐错误或者数据错位。解决方法是定义缓冲区时加上对齐属性。TI编译器支持#pragma DATA_ALIGN(buffer, 128)把buffer对齐到128位边界。这样DMA访问就能以最高的效率搬运数据也能避免很多奇奇怪怪的“数据莫名少几个字节”问题。此外F28377D的某些外设是32位数据总线RAM访问以128位为最优单位。对齐到128位边界能让CPU访问RAM时一次读满32位甚至更多未对齐的访问会拆分两次总线操作速度减半。如果做了RAM运行优化却发现性能提升不明显不妨检查一下数据段的对齐情况可能卡在这里。5.4 关于RAM地址总线的自检小技巧前面提过我在工程模板里放了一个上电自检函数现在把核心思路展开说。为了提高效率我不会对全部RAM做遍历只对关键区域做简化检测。#define RAM_START 0x008000 #define RAM_END 0x00AFFF #define RAM_PATTERN_A 0x5555 #define RAM_PATTERN_B 0xAAAA void ram_addrstress_test(void) { uint16_t *p; volatile uint16_t val; for (p (uint16_t *)RAM_START; p (uint16_t *)RAM_END; p) { *p RAM_PATTERN_A; } for (p (uint16_t *)RAM_START; p (uint16_t *)RAM_END; p) { val *p; if (val ! RAM_PATTERN_A) { while (1); } } }写完A模式后紧接着写B模式再读回如果某个地址读回来的值和写进去的不一致基本可以断定该地址线的写/读路径有问题。这个自检成本很低几十微秒就能跑完调试阶段放在main函数开头正式产品里可以根据需求关掉。它救过我几次尤其是在手工焊接、打样回来的板子上。5.5 给初学者的几条避坑建议如果这篇文章你看完了准备在自己的项目里试试RAM运行程序我给你几条实际经验第一动手之前先备份工程把原始CMD和源码复制一份出来。改CMD文件这件事改错了链接报错还好说最怕的是编译正常、运行跑飞没有备份你会很痛苦。第二加MEMCFG和GPIO翻转测量工具。RAM改造前先测一次基线数据改造完再测一次目标明确优化效果一目了然。第三用__ramfunc__做试点只搬一两个高频函数跑通了再慢慢扩大范围。不要一上来就--ramfuncon全量搬家出了事根本不知道从哪里排查。第四双核项目一定要从头就规划好内存归属。别等到两个核把共享RAM写成一锅粥才想起来做保护。内存保护和服务器的用户权限一样提前配好后面才会省心。我在实际调试双核程序时最大的体会就是内存布局这东西本质上就是一套“谁的数据放谁家、谁的任务用谁的资源”的管理办法。代码能不能在RAM里飞起来一半靠编译器选项一半靠你对自己工程里那些段和数据的使用习惯是否门儿清。最后再分享一个小技巧。调试RAM运行程序时不用每次都烧Flash可以设置CCS的启动模式让程序直接从RAM启动。这样每次修改代码后下载到RAM里就能立刻跑省去擦写Flash的等待时间。尤其是在反复调整函数边界、频繁测量执行时间的阶段RAM启动模式能帮你节省大量迭代时间。当然等优化结束、准备发布固件时再切回Flash启动模式做最终验证。自己动手把两个高频中断函数从Flash搬到RAM再量一下GPIO翻转时间那时候你再回头看这篇文章很多东西会有新的理解。
