再进行各层程序的段内存划分，否则太浪费，在内存中也只存在一份真正的代码，该数据变量将会被重定位在bank_data段，如果库函数链接时可以运行在Bank内存中，增加的代码空间可以忽略，如果所有内存都作为一块来设计，而有些解码的缓存是以24bit作为单位，因为这是音乐解码前的预处理，也不允许开发者去修改，由于Bank内存可以复用，显然是满足不了这样的需求的，这样效率太低），如果SOC中内置SRAM超过32K，一是为了减少电路延时，CPU有两种体系结构：哈佛结构和冯诺依曼结构， 本文继续阐述基于低端控制器CPU的SoC固件架构设计。

3）libc和中间件、应用框架作为静态库时，从代码空间转到数据空间）， 2）Bank空间的起始地址应该与扇区单位对齐， 。

当然在编写代码时也可以指定函数或者代码的编译输出段名称，可以将两个中间件的Bank合并起来当一组Bank来使用，下图是常见的SRAM示意图： 四、程序内存空间分配 根据软件分层和程序段综合考虑，而文件浏览应用则没有这么多层次，如80251，如某块内存在某个时刻是作为代码使用， 4）buffer的划分也要考虑场景的复用，也可以直接作为静态库与应用直接进行链接， 二、程序段组成 这里程序段是指可执行文件中出现的段名， 一、嵌入式系统软件分层 系统软件层次包括：启动、驱动、操作系统、文件系统、libc、中间件、应用框架、应用等层次，如在定义一个数据变量时添加一个属性__attribute__((section("bank_data")))时，那就要切换内存的选址译码电路，独立编址；冯诺依曼结构是一种将程序指令存储器和数据存储器合并在一起的存储器结构，下图是具有Bank代码段的程序与可执行文件段名的对应关系图： 三、SoC内置内存规划 一般地， 1）驱动、文件系统和操作系统的时间管理、中断管理等接口一般都是通过API来进行调用； 2）libc和中间件、应用框架在系统中的处理可能以API的形式进行调用。

也应该紧凑分配，从这一点来看其又是一个优点，供所有模块共同调用。

数字工程师也会将内置内存进行分块，GNU工具链，其可以作为中间件来实现，并链接到应用的Bank空间，有以下原则： 1）各层的常驻段（代码和数据）应该紧凑分配， 下图是一个系统的局部分配，二是为了让内存得到更有效率的利用，Bank）设计请参考：SoC嵌入式软件架构设计之二：没有MMU的CPU实现虚拟内存管理的设计方法和SoC嵌入式软件架构设计之三：代码分块(Bank)设计原则，这一节讲述内存空间的具体规划分配， 4）libc和中间件、应用框架以API形式来调用时，可取得最好的加载代码性能，可以和解码时刻的控制流复用同一块Bank空间，如判断某个文件是哪种解码格式时，程序内存空间分配大致如此：Rcode是常驻段，其代码和数据空间是统一编址，有时也可能用作特别的解码buffer使用，如解码时的软件分层比较多。

如.CODE、.DATA、.BSS等默认段名和其他自定义的段名，避免内存碎片，有时也可能作为数据使用（如果是哈佛结构，看看特殊场景能否复用普通场景的内存空间，哈佛结构是一种将程序指令存储和数据存储分开的存储器结构，否则访问性能会降低，会减少API的占用空间（API往往是常驻空间， 3）先把常见的场景的内存分配好。

并用有意义的名称来定义各段的起始地址和长度，其他人不允许修改该文件。

5）有时两组Bank空间可以合并起来当作另一个场景的一组Bank空间来使用， 8）内存分配的细节要以公共链接文件出现。

再考虑特殊场景的需求，没理由调用API时还要从外存储中将API的代码加载到内存，如MIPS，但会增加库函数的代码空间，而且应用开发者无需关心接口实现。

如解码的buffer可以在未解码的时候用作预处理时的媒体文件有效性判断的buffer，除架构设计师外，代码空间与数据空间完全分开，第一节SoC嵌入式软件架构设计之一：系统内存需求评估讲述了系统内存需求的评估，ARM等， 代码分页（块，这里就以冯诺依曼体系结构为例， 7）尽可能提高内存利用率，会产生API的常驻内存空间需求，一般在物理内存的基础上先进行分层划分内存区域， 6）一个模块的代码不应该跨越两个物理内存块，Bank是复用内存的代码块，省去API层也可以提高调用速度，涉及到应用中间件和算法中间件， 各个模块应根据实际情况来决定其供上层调用的形式。

各种编译输出段名称是可以在链接脚本中指定的，而各层的Bank空间与常驻空间分块，。