嵌入式MCU与MPU的区分和MCU开发中的三个误区

控制/MCU

1878人已加入

描述

目录

嵌入式MCU与MPU的区分

误区一:MCU的程序都是存储在片上Flash上,然后拷贝到RAM中执行的

误区二:工程编译生成的下载文件大小即为最终占用Flash的大小

误区三:用户应用工程的编译结果建议不能超过MCU片上Flash的80%

嵌入式MCU与MPU的区分

嵌入式系统中的处理器按照是否集成片上Flash和RAM可以分为MCU(Micro Control Unit—微控制器)和MPU(Micro Process Unit—微处理器)。典型的MCU如Freescale S08、S12和MPC56xx以及8051单片机等,而典型的MPU如基于ARM Cortex A系列内核的i.MX系列处理器:

本文中的观点针对仅针对嵌入式MCU,也就是我们常说的单片机。其为单芯片集成解决方案—片上集成了嵌入式系统工作所需的逻辑计算内核CPU,存储数据/代码的RAM,EEPROM和Flash,内部互联总线—Crossbar、AMBA(APB、AHB以及AXI bus),定时器资源(Timer)、中断控制器(INTC,通用输入输出接口(GPIO),模拟数字转换模块—ADC、DAC和ACMP,段码LCD控制器、TFT LCD控制器,步进电机驱动(SMC),通信接口/控制器—I2C、SPI、UART/SCI、CAN、SDIO/eMMC、以太网MAC等;当然,MPU中也会集成很多嵌入式系统工作所需的大部分片上外设,但因为其计算单元CPU内核运行速度非常快,所以其一般不会再片内集成系统工作所需的RAM和Flash存储器,而是集成SDR/DDR2/3/4等外部SRAM扩展接口和NAND/NOR Flash扩展接口,用户设计基于MPU的硬件系统时还需选择合适的SRAM和外部Flash才可以保证系统正常工作。

当然还有我们常说的CPU(Central Process Unit—中央处理器),常见PC上所使用的Intel的x86处理器,比如奔腾、至强、酷睿i3/i5/i7系列等,其片上只集成了中央计算内核单元CPU,少量的一级/二级/三级缓存以及GPU,但不包含中断控制器、定时器等,它需要通过主板进行扩展,更不包含存储器,需要用户在主板上外界DDR内存条和Flash硬盘。

按照内核的运行速度和片上集成外设资源的丰富程度以及功耗,MCU、MPU和CPU的对比分布如下:

误区一:MCU的程序都是存储在片上Flash上,然后拷贝到RAM中执行的

很多刚接触MCU的人受学校老师讲授计算机硬件和C语言课程时一些观点的影响,认为MCU中程序都是存储在片上Flash上,然后拷贝到RAM中执行的,这其实是错误。原因如下:

1.MCU的片上RAM资源和Flash存储器相比一般都比较小,其比例大概为1:16到1:5,其不可能将存储在Flash中的程序代码全部拷贝到片上RAM中;

以下为Freescale S12G系列、S12XE系列以及MPC574xB/C/D/G系列MCU的片上RAM和Flash存储器资源的对比:

2.在嵌入式MCU中内核CPU的工作频率一般为总线频率的两倍(S08和S12(X)系列MCU的内核CPU工作频率固定为总线工作频率的2倍)或者相等(PowerPC MPC560x系列),而挂到Flash的指令/数据总线宽度一般与CPU位宽的1~2倍,虽然Flash的访问频率比较低(几MHz到数十MHz,一般不超过100MHz),而嵌入式MCU内核CPU的运行频率也不高,在300MHz以内,所以总线每次可以从Flash取出2~4条指令(PS:当PowerPC e200内核使用VLE指令集时,大多数指令都为16位长度,若指令/数据总线宽度为64位宽,则一次可以读出4条VLE指令),从而弥补与内核CPU运行速度的差距,保证在硬件物理上实现在Flash取值执行嵌入式MCU程序是没有问题的。

3.在嵌入式MCU的硬件设计上没有自动将Flash程序提前拷贝到RAM的机制,在软件设计上也没有相应的代码执行这个拷贝工作--这样的拷贝过程无疑会造成内核CPU资源的浪费,代码搬移的过程总内核CPU无法处理其他任务;(除非是在开发嵌入式MCU的BootLoader时,需要对片上Flash进行擦除和编程,而大多数嵌入式MCU片上都只有一个Flash块(block/partion), 不支持read-while-read操作,所以需要将Flash驱动程序事先拷贝到RAM然后调用—事实上,只需要将Flash擦除和编程命令的launch语句和查询等待命令完成的程序拷贝到RAM执行即可。程序的执行至少包含取指à译码à执行三个环节,其中取指就是从存储器中读出指令,需要访问Flash/RAM)

4.通过调试嵌入式MCU,在CPU寄存器窗口查看程序运行时PC寄存器的值也可以验证嵌入式MCU程序默认运行时就是在Flash本地执行的、即存储地址与运行时地址相同;

由于S12XE系列MCU的Flash分页访问机制,地址0xFE8029其实是其Flash的Page_FE的逻辑地址,对应的Flash物理地址(也称作全局地址--Global Address)为0x7F8029;

误区二:工程编译生成的下载文件大小即为最终占用Flash的大小

很多工程师判断一个嵌入式MCU应用工程的编译结果大小往往看工程编译生成的HEX/S19/BIN等下载文件的大小,认为工程编译生成的下载文件大小即为最终占用Flash的大小,这是不正确的。

因为在HEX/S19/BIN等下载文件往往还包含了编译器版本信息,工程配置信息,每行数据/代码的存储地址,长度、校验和以及整个工程的复位运行地址等非常丰富的信息。因为只有具备了这些信息,编程器才找到将编译结果中的数据和代码烧写到Flash/EEPROM存储器的具体地址并保证数据/代码的完整性,通过每一行和整个文件的校验(Verify)来保证整个编程过程的正确完整。

以下以Motorola的S19文件(也称为S-Record)格式进行说明:

S-record每行最大是78个字节,156个字符

S-record 格式如下:

type count address data checksum

其中:

type(类型):2个字符。用来描述记录的类型 (S0,S1,S2,S3,S5,S7,S8,S9)。

count(计数):2个字符。 用来组成和说明了一个16进制的值,显示了在记录中剩余成对字符的计数。

address(地址):4或6或8个字节。用来组成和说明了一个16进制的值,显示了数据应该装载的地址, 这部分的长度取决于载入地址的字节数。2个字节的地址占用4个字符,3个字节的地址占用6个字符,4个字节的地址占用8个字符。

data(数据):0—64字符。用来组成和说明一个代表了内存载入数据或者描述信息的16进制的值。

checksum(校验和):2个字符。这些字符当被配对并换算成16进制数据的时候形成了一个最低有效字符 节,该字符节用来表达作为补充数据,地址和数据库的字符对所代表的(字节的)补码的byte总和。即计数值、地址场和数据场的若干字符以两个字符为一对, 将它们相加求和,和的溢出部分不计,只保留最低两位字符NN,checksum =0xFF-0xNN。

S0 Record:记录类型是“S0” (0x5330)。地址场没有被用,用零置位(0x0000)。数据场中的信息被划分为以下四个子域:

name(名称):20个字符,用来编码单元名称

ver(版本):2个字符,用来编码版本号

rev(修订版本):2个字符,用来编码修订版本号

description(描述):0-36个字符,用来编码文本注释

此行表示程序的开始,不需烧入memory。

S1 Record:记录类型是“S1” (0x5331)。地址场由2个字节地址来说明。数据场由可载入的数据组成。

S2 Record:记录类型是“S2” (0x5332)。地址场由3个字节地址来说明。数据场由可载入的数据组成。

S3 Record:记录类型是“S3” (0x5333)。地址场由4个字节地址来说明。数据场由可载入的数据组成。

S5 Record:记录类型是“S5” (0x5335)。地址场由2字节的值说明,包含了先前传输的S1、S2、S3记录的计数。没有数据场。

S7 Record:记录类型是“S7” (0x5337)。地址场由4字节的地址说明,包含了开始执行地址。没有数据场。此行表示程序的结束,不需烧入memory。

S8 Record:记录类型是“S8” (0x5338)。地址场由3字节的地址说明,包含了开始执行地址。没有数据场。此行表示程序的结束,不需烧入memory。

S9 Record:记录类型是“S9” (0x5339)。地址场由2字节的地址说明,包含了开始执行地址。没有数据场。此行表示程序的结束,不需烧入memory。

一个具体的S12XEP100的CodeWarrior5.2工程编译后S19文件的大小为6KB,而实际占用Flash的大小只有2445个字节,远小于S19文件的大小,所以判断一个应用工程编译结果所占Flash和RAM的大小,应该看MAP文件中的统计结果,而非S19文件的大小:

或者以IDE(比如CodeWarrior 10.6或者S32DS)的Print Size工具从控制台(console)打印出来的text + data来判断,下面是一个具体的MPC5748G S32DS for Power V1.2工程,其编译及我国所占Flash的大小为23366(text) + 1372(data)=24738 Byte,而其S19文件大小为73KB。

误区三:用户应用工程的编译结果建议不能超过MCU片上Flash的80%

通过对以上误区一的分析,嵌入式MCU中用户应用工程的编译结果(数据和程序代码)是一直存储在片上Flash中的,对其下载编程之后在整个产品的生命周期中都不会再改变(除非用户开发了在线/远程升级的BootLoader功能),因此,完全可以将将Flash全部用来保存编译结果,只要在工程链接文件中按照MCU实际存储器大小和地址进行配置,编译链接结果没有存储器溢出即可。用户应用工程的编译结果建议不能超过MCU片上Flash的80%的说法没有任何理论依据。

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分