为了使新能源爱好者和初级研发人员更好地了解新能源汽车的核心技术，笔者结合研发过程中的经验总结，从新能源汽车分类、模块规划、电控技术和充电设施等方面进行了分析。

1新能源汽车分类

在新能源汽车分类中，“弱混、强混”与“串联、并联”不同分类方法令非业内人士感到困惑，其实这些名称是从不同角度给出的解释、并不矛盾。

1.1消费者角度

消费者角度通常按照混合度进行划分，可分为起停、弱混、中混、强混、插电和纯电动，节油效果和成本增等指标加如表1所示。表中“-”表示无此功能或较弱、“+”个数越多表示效果越好，从表中可以看出随着节油效果改善、成本增加也较多。

表1 消费者角度分类

1.2技术角度

图1 技术角度分类

技术角度由简到繁分为纯电动、串联混合动力、并联混合动力及混联混合动力，具体如图1所示。其中P0表示BSG(Belt starter generator，带传动启停装置)系统，P1代表ISG(Integrated starter generator，启动机和发电机一体化装置)系统、电机处于发动机和离合器之间，P2中电机处于离合器和变速器输入端之间，P3表示电机处于变速器输出端或布置于后轴，P03表示P0和P3的组合。从统计表中可以看出，各种结构在国内外乘用或商用车中均得到广泛应用，相对来说P2在欧洲比较流行，行星排结构在日系和美系车辆中占主导地位，P03等组合结构在四驱车辆中应用较为普遍、欧蓝德和标致3008均已实现量产。新能源车型选择应综合考虑结构复杂性、节油效果和成本增加，例如由通用、克莱斯勒和宝马联合开发的三行星排双模系统，尽管节油效果较好，但由于结构复杂且成本较高，近十年间的市场表现不尽如人意。

2新能源汽车模块规划

尽管新能源汽车分类复杂，但其中共用的模块较多，在开发过程中可采用模块化方法，共享平台、提高开发速度。总体上讲，整个新能源汽车可分为三级模块体系、如图2所示，一级模块主要是指执行系统，包括充电设备、电动附件、储能系统、发动机、发电机、离合器、驱动电机和齿轮箱。二级模块分为执行系统和控制系统两部分，执行部分包括充电设备的地面充电机、集电器和车载充电机，储能系统的单体、电箱和PACK，发动机部分的气体机、汽油机和柴油机，发电机的永磁同步和交流异步，离合器中的干式和湿式，驱动电机的永磁同步和交流异步，齿轮箱部分的有级式自动变速器(包括AMT、AT和DCT等)、行星排和减速齿轮；二级模块的控制系统包括BMS、ECU、GCU、CCU、MCU、TCU和VCU，分别表示电池管理系统、发动机电子控制单元、发电机控制器、离合器控制单元、电机控制器、变速器控制系统和整车控制器。三级模块体系中，包括电池单体的功率型和能量型，永磁和异步电机的水冷和风冷形式，控制系统的三级模块主要包括硬件、底层和应用层软件。

图2三级模块体系

根据功能和控制的相似性，三级模块体系的部分模块可组成纯电动(含增程式)、插电并联混动和插电混联混动三种平台架构，例如纯电动(含增程式)由充电设备、电动附件、储能系统、驱动电机和齿轮箱组成。各平台模块的通用性较强，采用平台和模块的开发方法，可共享核心部件资源，提升新能源系统的安全性和可靠性，缩短周期、降低研发及采购成本。

3新能源三大核心技术

在三级模块体系和平台架构中，整车控制器(VCU)、电机控制器(MCU)和电池管理系统(BMS)是最重要的核心技术，对整车的动力性、经济性、可靠性和安全性等有着重要影响。

3.1VCU

VCU是实现整车控制决策的核心电子控制单元，一般仅新能源汽车配备、传统燃油车无需该装置。VCU通过采集油门踏板、挡位、刹车踏板等信号来判断驾驶员的驾驶意图；通过监测车辆状态(车速、温度等)信息，由VCU判断处理后，向动力系统、动力电池系统发送车辆的运行状态控制指令，同时控制车载附件电力系统的工作模式；VCU具有整车系统故障诊断保护与存储功能。

图3为VCU的结构组成，共包括外壳、硬件电路、底层软件和应用层软件，硬件电路、底层软件和应用层软件是VCU的关键核心技术。

图3 VCU组成

VCU硬件采用标准化核心模块电路( 32位主处理器、电源、存储器、CAN )和VCU专用电路(传感器采集等)设计；其中标准化核心模块电路可移植应用在MCU和BMS，平台化硬件将具有非常好的可移植性和扩展性。随着汽车级处理器技术的发展，VCU从基于16位向32位处理器芯片逐步过渡，32位已成为业界的主流产品。

底层软件以AUTOSAR汽车软件开放式系统架构为标准，达到电子控制单元(ECU)开发共平台的发展目标，支持新能源汽车不同的控制系统；模块化软件组件以软件复用为目标，以有效提高软件质量、缩短软件开发周期。

应用层软件按照V型开发流程、基于模型开发完成，有利于团队协作和平台拓展；采用快速原型工具和模型在环(MIL)工具对软件模型进行验证，加快开发速度；策略文档和软件模型均采用专用版本工具进行管理，增强可追溯性；驾驶员转矩解析、换挡规律、模式切换、转矩分配和故障诊断策略等是应用层的关键技术，对车辆动力性、经济性和可靠性有着重要影响。

表2为世界主流VCU供应商的技术参数，代表着VCU的发展动态。

表2 VCU技术参数

3.2MCU

MCU是新能源汽车特有的核心功率电子单元，通过接收VCU的车辆行驶控制指令，控制电动机输出指定的扭矩和转速，驱动车辆行驶。实现把动力电池的直流电能转换为所需的高压交流电、并驱动电机本体输出机械能。同时，MCU具有电机系统故障诊断保护和存储功能。

MCU由外壳及冷却系统、功率电子单元、控制电路、底层软件和控制算法软件组成，具体结构如图4所示。

图4 MCU组成

MCU硬件电路采用模块化、平台化设计理念(核心模块与VCU同平台)，功率驱动部分采用多重诊断保护功能电路设计，功率回路部分采用汽车级IGBT模块并联技术、定制母线电容和集成母排设计；结构部分采用高防护等级、集成一体化液冷设计。

与VCU类似，MCU底层软件以AUTOSAR开放式系统架构为标准，达到ECU开发共同平台的发展目标，模块化软件组件以软件复用为目标。

应用层软件按照功能设计一般可分为四个模块：状态控制、矢量算法、需求转矩计算和诊断模块。其中，矢量算法模块分为MTPA控制和弱磁控制。

MCU关键技术方案包括：基于32位高性能双核主处理器；汽车级并联IGBT技术，定制薄膜母线电容及集成化功率回路设计，基于AutoSAR架构平台软件及先进SVPWM PMSM控制算法；高防护等级壳体及集成一体化水冷散热设计。

表3为世界主流 MCU硬件供应商的技术参数，代表着MCU的发展动态。

表3 MCU技术参数

3.3电池包和BMS

电池包是新能源汽车核心能量源，为整车提供驱动电能，它主要通过金属材质的壳体包络构成电池包主体。模块化的结构设计实现了电芯的集成，通过热管理设计与仿真优化电池包热管理性能，电器部件及线束实现了控制系统对电池的安全保护及连接路径；通过BMS实现对电芯的管理，以及与整车的通讯及信息交换。

电池包组成如图5所示，包括电芯、模块、电气系统、热管理系统、箱体和BMS。BMS能够提高电池的利用率，防止电池出现过充电和过放电，延长电池的使用寿命，监控电池的状态。

图5 电池包组成

BMS是电池包最关键的零部件，与VCU类似，核心部分由硬件电路、底层软件和应用层软件组成。但BMS硬件由主板(BCU)和从板(BMU)两部分组成，从版安装于模组内部，用于检测单体电压、电流和均衡控制；主板安装位置比较灵活，用于继电器控制、荷电状态值(SOC)估计和电气伤害保护等。

BMU硬件部分完成电池单体电压和温度测量，并通过高可靠性的数据传输通道与BCU 模块进行指令及数据的双向传输。BCU 可选用基于汽车功能安全架构的32 位微处理器完成总电压采集、绝缘检测、继电器驱动及状态监测等功能。

底层软件架构符合AUTOSAR标准，模块化开发容易实现扩展和移植，提高开发效率。

应用层软件是BMS的控制核心，包括电池保护、电气伤害保护、故障诊断管理、热管理、继电器控制、从板控制、均衡控制、SOC估计和通讯管理等模块，应用层软件架构如图6所示。

图6 应用层软件架构

表4为国内外主流 BMS供应商的技术参数，代表着BMS的发展动态。

表4 BMS技术参数

4充电设施

充电设施不完善是阻碍新能源汽车市场推广的重要因素，对特斯拉成功的解决方案进行分析，并提出新能源汽车的充电解决方案、剖析充电系统组成。

4.1特斯拉充电方案分析

特斯拉超级充电器代表了当今世界最先进的充电技术，它为MODEL S充电的速度远高于大多数充电站，表5为特斯拉电池和充电参数。

表5电池和充电参数

特斯拉具有5种充电方式，采用普通110/220V市电插座充电，30小时充满；集成的10kW充电器，10小时充满；集成的20kW充电器，5小时充满；一种快速充电器可以装在家庭墙壁或者停车场，充电时间可缩短为5小时； 45分钟能充80%的电量、且电费全免，这种快充装置仅在北美市场比较普遍。

特斯拉使用太阳能电池板遮阳棚的充电站，既可以抵消能源消耗又能够遮阳。与在加油站加油需要付费不同，经过适当配置的 MODEL S 可以在任何开放充电站免费充电。

特斯拉充电技术特点可总结如下两点：1)特斯拉充电站加入了太阳能充电技术，这一技术使充电站尽可能使用清洁能源，减少对电网的依赖，同时也减少了对电网的干扰，国内这一技术也能实现。 2)特斯拉充电时间短也不足为奇，特斯拉的充电机容量大90~120kWh，充电倍率0.8C，跟普通快充一样，并没有采用更大的充电倍率，所以不会影响电池寿命；20分钟充到40%，就能满足续航要求，主要原因是电池容量大。

4.2充电解决方案

图7充电系统组成

图7为一种可参考的新能源汽车充电解决方案，充电系统组成：配电系统(高压配电柜、变压器、无功补偿装置和低压开关柜)、充电系统(充电柜和充电机终端)以及储能系统(储能电池与逆变器柜)。无功补偿装置解决充电系统对电网功率因数影响，充电柜内充电机一般都具备有源滤波功能、解决谐波电流和功率因数问题。储能电池和逆变器柜解决老旧配电系统无法满足充电站容量要求、并起到削峰填谷作用，在不充电时候进行储能，大容量充电且配电系统容量不足时释放所储能量进行充电。如果新建配电系统容量足够，储能电池和逆变器柜可以不选用。风力发电和光伏发电为充电系统提供清洁能源，尽量减少从电网取电。

5总结

从消费者和技术角度分别对新能源汽车结构进行归纳分类，分析各种结构的优势，以及国内外各主机厂的应用情况。分析新能源汽车的模块组成和平台架构，详细介绍了三级模块体系中相关的执行系统和控制系统。分析VCU、MCU和BMS的结构组成及关键技术，以及世界主流供应商的技术参数和发展动态。对特斯拉成功的解决方案进行分析，并提出新能源汽车的充电解决方案。

任何一款MCU，其基本原理和功能都是大同小异，所不同的只是其外围功能模块的配置及数量、指令系统等。对于指令系统，虽然形式上看似千差万别，但实际上只是符号的不同，其所代表的含义、所要完成的功能和寻址方式基本上是类似的。因此，对于任何一款MCU，主要应从如下的几个方面来理解和掌握：

MCU的特点

要了解一款MCU，首先需要知道就是其ROM空间、RAM空间、IO口数量、定时器数量和定时方式、所提供的外围功能模块(Peripheral Circuit)、中断源、工作电压及功耗等等。

了解这些MCU Features后，接下来第一步就是将所选MCU的功能与实际项目开发的要求的功能进行对比，明确那些资源是目前所需要的，那些是本项目所用不到的。对于项目中需要用到的而所选MCU不提供的功能，则需要认真理解MCU的相关资料，以求用间接的方法来实现，例如，所开发的项目需要与PC机COM口进行通讯，而所选的MCU不提供UART口，则可以考虑用外部中断的方式来实现;

对于项目开发需要用到的资源，则需要对其Manua*进行认真的理解和阅读，而对于不需要的功能模块则可以忽略或浏览即可。对于MCU学习来讲，应用才是关键，也是最主要的目的。

明确了MCU的相关功能后，接下来就可以开始编程了。对于初学者或初次使用此款MCU的设计者来说，可能会遇到很多对MCU的功能描述不明确的地方，对于此类问题，可以通过两种方法来解决，一种是编写特别的验证程序来理解资料所述的功能;另一种则可以暂时忽略，程序设计中则按照自己目前的理解来编写，留到调试时去修改和完善。前一种方法适用于时间较宽松的项目和初学者，而后一种方法则适合于具有一定MCU开发经验的人或项目进度较紧迫的情况;

指令系统千万不要特别花时间去理解。指令系统只是一种逻辑描述的符号，只有在编程时根据自己的逻辑和程序的逻辑要求来查看相关的指令即可，而且随着编程的进行，对指令系统也会越来越熟练，甚至可以不自觉地记忆下来。

MCU的基本功能

对于绝大多数MCU，下列功能是最普遍也是最基本的，针对不同的MCU，其描述的方式可能会有区别，但本质上是基本相同的：

TImer(定时器)：TImer的种类虽然比较多，但可归纳为两大类：一类是固定时间间隔的TImer，即其定时的时间是由系统设定的，用户程序不可控制，系统只提供几种固定的时间间隔给用户程序进行选择，如32Hz，16Hz，8Hz等，此类TImer在4位MCU中比较常见，因此可以用来实现时钟、计时等相关的功能;另一类则是Programmable Timer(可编程定时器)，顾名思义，该类Timer的定时时间是可以由用户的程序来控制的，控制的方式包括：时钟源的选择、分频数(Prescale)选择及预制数的设定等，有的MCU三者都同时具备，而有的则可能是其中的一种或两种。此类Timer应用非常灵活，实际的使用也千变万化，其中最常见的一种应用就是用其实现PWM输出(具体的应用，后续会有特别的介绍)。由于时钟源可以自由选择，因此，此类Timer一般均与Event Counter(事件计数器)合在一起;

IO口：任何MCU都具有一定数量的IO口，没有IO口，MCU就失去了与外部沟通的渠道。根据IO口的可配置情况，可以分为如下几种类型：

纯输入或纯输出口：此类IO口有MCU硬件设计决定，只能是输入或输出，不可用软件来进行实时的设定;

直接读写IO口：如MCS-51的IO口就属于此类IO口。当执行读IO口指令时，就是输入口;当执行写IO口指令则自动为输出口;

程序编程设定输入输出方向的：此类IO口的输入或输出由程序根据实际的需要来进行设定，应用比较灵活，可以实现一些总线级的应用，如I2C总线，各种LCD、LED Driver的控制总线等;

对于IO口的使用，重要的一点必须牢记的是：对于输入口，必须有明确的电平信号，确保不能浮空(可以通过增加上拉或下拉电阻来实现);而对于输出口，其输出的状态电平必须考虑其外部的连接情况，应保证在Standby或静态状态下不存在拉电流或灌电流。

外部中断：外部中断也是绝大多数MCU所具有的基本功能，一般用于信号的实时触发，数据采样和状态的检测，中断的方式由上升沿、下降沿触发和电平触发几种。外部中断一般通过输入口来实现，若为IO口，则只有设为输入时其中断功能才会开启;若为输出口，则外部中断功能将自动关闭(ATMEL的ATiny系列存在一些例外，输出口时也能触发中断功能)。外部中断的应用如下：

外部触发信号的检测：一种是基于实时性的要求，比如可控硅的控制，突发性信号的检测等;而另一种情况则是省电的需要;
信号频率的测量;为了保证信号不被遗漏，外部中断是最理想的选择;

数据的解码：在遥控应用领域，为了降低设计的成本，经常需要采用软件的方式来对各种编码数据进行解码，如Manchester和PWM编码的解码;

按键的检测和系统的唤醒：对于进入Sleep状态的MCU，一般需要通过外部中断来进行唤醒，最基本的形式则是按键，通过按键的动作来产生电平的变化;

通讯接口：MCU所提供的通讯接口一般包括SPI接口，UART，I2C接口等，其分别描述如下：

SPI接口：此类接口是绝大多数MCU都提供的一种最基本通讯方式，其数据传输采用同步时钟来控制，信号包括：SDI(串行数据输入)、SDO(串行数据输出)、SCLK(串行时钟)及Ready信号;有些情况下则可能没有Ready信号;此类接口可以工作在Master方式或Slave方式下，通俗说法就是看谁提供时钟信号，提供时钟的一方为Master，相反的一方则为Slaver;

UART(Universal Asynchronous Receive Transmit)：属于最基本的一种异步传输接口，其信号线只有Rx和Tx两条，基本的数据格式为：Start Bit + Data Bit(7-bits/8-bits) + Parity Bit(Even， Odd or None) + Stop Bit(1~2Bit)。一位数据所占的时间称为Baud Rate(波特率)。对于大多数的MCU来讲，数据为的长度、数据校验方式(奇校验、偶校验或无校验)、停止位(Stop Bit)的长度及Baud Rate是可以通过程序编程进行灵活设定。此类接口最常用的方式就是与PC机的串口进行数据通讯。

I2C接口：I2C是由Philips开发的一种数据传输协议，同样采用2根信号来实现：SDAT(串行数据输入输出)和SCLK(串行时钟)。其最大的好处是可以在此总线上挂接多个设备，通过地址来进行识别和访问;I2C总线的一个最大的好处就是非常方便用软件通过IO口来实现，其传输的数据速率完全由SCLK来控制，可快可慢，不像UART接口，有严格的速率要求。

Watchdog(看门狗定时器)：Watchdog也是绝大多数MCU的一种基本配置(一些4位MCU可能没有此功能)，大多数的MCU的Watchdog只能允许程序对其进行复位而不能对其关闭(有的是在程序烧入时来设定的，如Microchip PIC系列MCU)，而有的MCU则是通过特定的方式来决定其是否打开，如Samsung的KS57系列，只要程序访问了Watchdog寄存器，就自动开启且不能再被关闭。一般而言watchdog的复位时间是可以程序来设定的。Watchdog的最基本的应用是为MCU因为意外的故障而导致死机提供了一种自我恢复的能力。

MCU程序的编写

MCU的程序的编写与PC下的程序的编写存在很大的区别，虽然现在基于C的MCU开发工具越来越流行，但对于一个高效的程序代码和喜欢使用汇编的设计者来讲，汇编语言仍然是最简洁、最有效的编程语言。对于MCU的程序编写，其基本的框架可以说是大体一致的，一般分为初始化部分(这是MCU程序设计与PC最大的不同)，主程序循环体和中断处理程序三大部分，其分别说明如下：

初始化：对于所有的MCU程序的设计来讲，出世化是最基本也是最重要的一步，一般包括如下内容：

屏蔽所有中断并初始化堆栈指针：初始化部分一般不希望有任何中断发生;

清除系统的RAM区域和显示Memory：虽然有时可能没有完全的必要，但从可靠性及一致性的角度出发，特别是对于防止意外的错误，还是建议养成良好的编程习惯;

IO口的初始化：根据项目的应用的要求，设定相关IO口的输入输出方式，对与输入口，需要设定其上拉或下拉电阻;对于输出口，则必须设定其出世的电平输出，以防出现不必要的错误;

中断的设置：对于所有项目需要用到的中断源，应该给予开启并设定中断的触发条件，而对于不使用的多余的中断，则必须给予关闭;

其他功能模块的初始化：对于所有需要用到的MCU的外围功能模块，必须按项目的应用的要求进行相应的设置，如UART的通讯，需要设定Baud Rate，数据长度，校验方式和Stop Bit的长度等，而对于Programmer Timer，则必须设置其时钟源，分频数及Reload Data等;

参数的出世化：完成了MCU的硬件和资源的出世化后，接下来就是对程序中使用到的一些变量和数据的初始化设置，这一部分的初始化需要根据具体的项目及程序的总体安排来设计。对于一些用EEPROM来保存项目预制数的应用来讲，建议在初始化时将相关的数据拷贝到MCU的RAM，以提高程序对数据的访问速度，同时降低系统的功耗(原则上，访问外部EEPROM都会增加电源的功耗)。

主程序循环体：大多数MCU是属于长时间不间断运行的，因此其主程序体基本上都是以循环的方式来设计，对于存在多种工作模式的应用来讲，则可能存在多个循环体，相互之间通过状态标志来进行转换。对于主程序体，一般情况下主要安排如下的模块：

计算程序：计算程序一般比较耗时，因此坚决反对放在任何中断中处理，特别是乘除法运算;

实时性要求不高或没有实时性要求的处理程序;

显示传输程序：主要针对存在外部LED、LCD Driver的应用;

中断处理程序：中断程序主要用于处理实时性要求较高的任务和事件，如，外部突发性信号的检测，按键的检测和处理，定时计数，LED显示扫描等。一般情况下，中断程序应尽可能保证代码的简洁和短小，对于不需要实时去处理的功能，可以在中断中设置触发的标志，然后由主程序来执行具体的事务――这一点非常重要，特别是对于低功耗、低速的MCU来讲，必须保证所有中断的及时响应。

对于不同任务体的安排，不同的MCU其处理的方法也有所不同。例如，对于低速、低功耗的MCU(Fosc=32768Hz)应用，考虑到此类项目均为手持式设备和采用普通的LCD显示，对按键的反应和显示的反应要求实时性较高，应此一般采用定时中断的方式来处理按键的动作和数据的显示;而对于高速的MCU，如Fosc》1MHz的应用，由于此时MCU有足够的时间来执行主程序循环体，因此可以只在相应的中断中设置各种触发标志，并将所有的任务放在主程序体中来执行;

在MCU的程序设计中，还需要特别注意的一点就是：要防止在中断和主程序体中同时访问或设置同一个变量或数据的情况。有效的预防方法是，将此类数据的处理安排在一个模块中，通过判断触发标志来决定是否执行该数据的相关操作;而在其他的程序体中(主要是中断)，对需要进行该数据的处理的地方只设置触发的标志。――这可以保证数据的执行是可预知和唯一的。

来源： 21ic电子网

(本文作者为Silicon Labs软件开发产品经理)

当想要创建一个合适的项目，或是更进一步探索这个想法并将其产品化时，必须先考虑要从哪种软件框架入手。另外，还须分辨Espruino、Arduino、microPython、Segger embOS、Micrium uC/OS-II以及在uC/OS-II和uC/OS-III之间有那些区别。还要决定该采用初始成本较低的开放原始码框架，或者选择须要支付前期费用的商业解决方案来加速设计过程。

因此，这里将讨论在为微控制器(MCU)或无线微控制器项目选择一套优秀的软件时，所需要考虑的各种要素。

认识软件框架　从项目中找灵感

所谓的「软件框架」这个词，本文将其解释为「撰写软件的一种特定方式」。例如，Arduino提供撰写程序代码的一种特定方式，允许软件的片段可以跨越多个项目被重新使用。

软件框架是由几个不同的部分所组成，并由程序语言、应用程序编程接口(API)以及某些工具集的联结等组件所定义。例如，在Arduino和Espruino的案例中，软件框架可以被紧密地关联到工具，或是在Micrium和FreeRTOS的案例中则是去耦合的(Decoupled)。

了解操作系统　分构运行步骤

该如何选择一个软件框架呢？首先，须要对一些操作系统、软件组件等这些名词解释得更明确一点；操作系统(OS)核心需求在撰写可执行特定需求的程序代码，藉由这些程序代码做出产品区隔。但是，仍然须要依靠软件的其他部分共同规划完成，例如ADC的驱动程序或SD卡的文件系统堆栈，而这些软件通常被称为软件组件。

做一个简单明了的比喻，将软件组件想象成砖块，然后把操作系统视为水泥(图1)。在操作系统中定义了砖块的形状以及砖块间将如何互动作用，因此当加入更多组件到软件时，依旧能继续完美地协同工作。这听起来相当不错，但是否真的需要一个操作系统？毕竟增加操作系统，同时带来了额外的负荷，不只会消耗数千字节的闪存，为事件的响应增加延迟的时间，还须要花费些许的时间学习如何在操作系统环境中撰写程序。

根据一般的经验法则，如果选用的闪存容量是128KB或更高，并且需要通讯功能，便需要一些堆栈如通用串行总线(USB)、以太网络、安全数字输入输出(SDIO)、控制局域网络(CAN)、Wi-Fi、蓝牙低功耗(BLE)，因此从长期来看，使用操作系统还是比较好的选择。

在操作系统中，最重要的其中一件事情便是排程器(Scheduler)。排程器是用在为可能会争夺相同资源的不同任务，分配资源和处理时间的组件。在一般情况下，排程器有两种作业的方式，而这正是实时(RT)在实时操作系统(RTOS)的意义所在。

实时意味着在一个固定的时间内，会有一个特定的任务一定可以被执行。假设得到一个须要处理的无线电封包，无论装置目前正在做甚么事，实时操作系统的核心会先离开其目前所执行的任务，先完成此高优先等级的任务。这种方式在处理器的利用率上并不是最有效率的，但在通讯堆栈中，或是在重视反应时间的应用中，例如马达控制应用，这是有必要的。

商用vs.开放原始码 方案选择的两难

如果已经想通是否须要采用实时操作系统，并开始收集软件的需求。此时将需要一个USB堆栈和以太网络堆栈，搭配外部媒介访问控制(MAC)/实体(PHY)驱动程序一起将装置连接到因特网。但是，该从哪里开始呢？真的只须要为首选的微控制器下载最新的FreeRTOS模板和继续下载开放原始码软件并放到装置中就可以吗？或者必须要寻求产品所需软件的商业供货商，以获得完整的软件组合比较好呢？

为了做出更明智的决定，还须为选定的解决方案提出一个总体拥有成本(TCO)的概念。所谓的总体拥有成本包含的不仅是付出的软件货币价值，还包括花费在寻找解决方案、收集不同的组件，并将不同的组件整合到项目以及开发、测试和生产的工作时间(图2)。

在一般情况下，看到的是商业解决方案的总体拥有成本，将比自己整合开放原始码组件的解决方案要来得更低一些。但既然是商业解决方案便涉及到初始成本，这些厂商通常要求在使用解决方案的前期，取决于自身所需要的组件，便必须先支付1万到10万美元之间的费用。相对地，下载FreeRTOS并开始整合自己的解决方案，在某些拥有密集资源的应用中，可节省金钱，但却消耗更多的整体资源。

决定操作系统种类 选择适用软件框架

到此阶段时，很多人可能都会认为：「只要给我一个可以让我开始使用的框架就好了！」但可惜还没那么快，肯定有一些方案优于其他选项，但由于微控制器的应用非常多样性，因此没有那种单一且适用于所有需求的解决方案。
接下来，将针对主流操作系统和软件框架深入探讨：

慎选操作系统 商用抑或开放源码

所有在这里所提到的操作系统，都应该具有实时能力(RTOS)。说到商用解决方案的选择，可从以下三项选择其一：

．Micrium uC/OS-II与uC/OS-III
这是在微控制器业界最流行的两个实时操作系统，因其创新商业模式，Micrium允许下载完整的软件套件进而开发，待创造营收时，才须要开始支付解决方案的费用。此外，也在安全关键系统中拥有重要的地位，并且其大部分软件组件都已经通过认证。

．Segger embOS
嵌入式软件市场的新进者，但这并不意味着他们是新手。该软件产品已经开发了超过20年的时间，并已经使用在其硬件产品之中，对装置的支持程度非常好，并配有一个完备的驱动程序库。

．Express Logic ThreadX
由业界资深人士所创办，该公司专注在所有关于性能的事物上，并挤压出零组件中每一个频率周期的效能。其通常被看作是操作系统中的劳斯莱斯，并已经有很多安全关键系统的相关认证。

若要从开放原始码中找寻相关的解决方案，计有以下三种选择：

．FreeRTOS
FreeRTOS与Micrium uC/OS一样，都是在业界最常被采用的实时操作系统之一。拥有庞大的社群，许多人都在为软件做出贡献，例如TCP/IP堆栈，但做为开放原始码软件，便意味着没有公司会负责整合，因此需要更多的人力物力和时间来整合出一个完整的解决方案。也有一些公司在FreeRTOS的生态系统中，专门从事将差异化的软件组件提供给那些需要整合协助的客户。例如，Wittenstein High Integrity System就提供一个具有安全认证的FreeRTOS替换核心，称为SAFERTOS，以及HCC Embedded提供可以用在任何实时操作系统的USB、以太网络和文件系统。

．mbed OS
由安谋国际(ARM)负责整合工作，mbed OS解决一般在开放原始码软件容易所遇到的痛点。但因为仍然是处于萌芽阶段，适合想对此系统有些贡献者。

．RIOT OS
RIOT OS被冠以「物联网中最佳操作系统」，以通讯概念为基础所建立起来的操作系统。即使在面对困难的通讯问题时，RIOT OS仍然精简且高效率操作。但即便如此，由于也还在积极发展的阶段，撰写程序时仍须花几个小时来进行除错。

依据项目发展 挑选软件框架

有些操作系统的功能就像是将砖块黏合在一起的水泥，会与发展框架紧密地结合在一块，因此一般而言，不能将其只使用在项目的某一部分，必须围绕着它来进行整个开发流程。这些框架往往是使用比C++更高阶的语言所撰写，通常可以在实时操作系统上运行。

．mbed
mbed也出现在这里，这时则是做为快速原型的项目。使用C++编写，并对大多数微控制器和电路板有绝佳的支持，拥有一个庞大的组件函式库和一个采用网页架构的漂亮集成开发环境(IDE)。在框架准备全面部署前，仍然需要一点成熟的时间，因而较适合硬件原型开发。

．Espruino
Espruino是在微控制器上运行的实时JavaScript解释器。允许动态更改程序代码，甚至不需要刻录微控制器便可以撰写程序代码。但其开始量产之前，仍然需要一些时间来发展，因而较适用于硬件原型。此外，Espruino有成为一个不可忽视的软件框架的巨大潜力。

．microPython
microPython所能做的事与Espruino大致相同，差别仅在于其使用Python而不是JavaScript。其发展的概念是，让开发者从产品开发的一开始到量产时，都有已预先编译程序的支持，并使用C语言来撰写时序关键的程序代码。其目前仍在开发当中。

．microEJ
microEJ是一个采用Java架构的框架，可轻松地为自身的装置打造好看的图形化应用程序，目前已经在许多智能手表和一些物联网(IoT)装置中使用。

以目的为依凭　贯彻项目执行

如果想要着手进行装置的开发，而无考虑量产事宜，诸如mbed和microPython这类的框架，便是入门的好方法。但若是要建立更大的部署，采用一个纯粹的实时操作系统将会是更好的选择。 但对于以工作时间取代金钱来做为软件投资的公司，FreeRTOS或RIOT这类非商业解决方案便有其优势。反之，要是能负担得起前期投资者，Segger、Express Logic和Micrium等商业解决方案，将大幅降低软件开发风险和缩短产品上市的时间。

在商业解决方案中，特别是如Micrium的稳定性和已认证的程序代码基础、广泛普及的部署、良好的零件支持、开放的原始码，以及易于负担的商业模式，更使其在商业解决方案中显得特别突出。

​新通讯 2016 年 12 月号 190 期《 技术前瞻 》
文．Alf Petter Mossevig

物联网(IoT)安全一直是备受关注的议题，但目前欧美业者在应用中实作安全防护机制的案例仍比亚太区业者来得多。究其原因，除了欧美市场对安全议题更为重视外，实作安全机制所需投入的成本跟资源也是障碍之一。不过，近来亚洲业者对安全MCU的询问度已有明显升温，对物联网安全的需求可望萌芽。

意法半导体安全微控制器技术行销专案经理阎欣怡表示，随着越来越多产品添加联网功能，使用者个资外泄或系统被骇客远端入侵的事件也时有所闻，引发各界对物联网安全的重视。有鉴于此，以欧美为主的联网硬体制造商，已在产品的资讯安全及功能安全防护方面投入更多心力。

为了守护物联网应用产品的资讯安全及功能安全，产品制造商可以导入四大类防护机制，分别是加密记忆体、具备安全防护功能的韧体、在MCU程式码中加入加密函式库或采用专门的安全MCU来扮演安全元件(Secure Element)。就安全防护能力来说，安全MCU的防护等级最强，对绝大多数软/硬体骇客攻击手法都有对应的防御能力。但对产品制造商而言，因为要导入额外的晶片与韧体，因此必须投入对应的成本跟开发资源，形成一定的导入障碍。

有鉴于此，意法近期推出一系列高整合度的STSAFE-A统包解决方案，包含MCU晶片、嵌入式软体、开发工具与主控端函式库(Host Library)，可大幅降低为物联网应用导入高强度安全防护机制所需投入的资源。此外，由于STSAFE-A是专门为了物联网应用而最佳化的解决方案，因此其成本相当具有竞争力，大量采购时，晶片单价均在1美元以下。

阎欣怡指出，物联网应用需要更强固的安全防护能力，已经是整个业界的共识。继欧美业者陆续在物联网硬体中导入安全元素后，亚太区产品制造商的态度也比以往更为积极，相关解决方案的市场询问度有升温迹象。现阶段意法将优先针对工业电脑、自动化设备制造商进行推广，因为这类产品对安全的需求相对迫切。事实上，在欧美市场，工业物联网客户也是最早导入安全MCU的客户群，消费性物联网的需求出现速度较慢。

至于台湾，本地业者对安全元素其实并不陌生，因为在PC/伺服器领域，英特尔(Intel)及微软(Microsoft)力推的可信任平台模组(Trusted Platform Module, TPM)已相当普及，很多商用笔记型电脑及伺服器均已搭载，意法也有对应的解决方案。不过，TPM是针对PC/伺服器所设计的技术，对于以安谋(ARM)架构为主的物联网应用来说，TPM不是最理想的方案，因此意法才另外针对物联网应用推出STSAFE-A系列解决方案。

来源：新电子

作为典型的嵌入式开发，物联网应用的开发与互联网应用从硬件配置到运行环境有巨大的不同。本文介绍了当前物联网开发者面临的挑战，并分析IoT时代完整的开发平台至少需要具备的特征。

1969年10月29日晚上10点30分，雷纳德•克兰罗克（Leonard Kleinrock）在洛杉矶向在斯坦福的比尔·杜瓦利的计算机发送了两个字符“Lo”，它们是单词“Login”的一部分，只发送了“Lo”，传输系统就崩溃了。这是一个伟大的事件，标志着世界上第一次计算机网络互连的开始，也标志计算机编程由单机向网络发展。

物联网（IoT）是个新名词，顾名思义，就是把物体用网络连接在一起。却是一个新瓶装旧酒的新名词，它不是一个新事物。看官你说，当年克兰罗克和比尔.杜瓦利手中的互相连接的两台计算机，算不算物联网设备，他们的确是用通信介质连接在一起的“物体”啊，谁说计算机不算物体的？

今天的物联网通信，与40多年前传输的两个字节，并没有本质的不同，说来也就是通信速度、通信成本、设备体积和功耗方面，逐步进化而已。然而，量变引起质变，上世纪末计算机网络通信的发展，引发了互联网革命，现在，随着通信成本的降低，功耗的减小、无线通信的普及，又引发了物联网革命。

互联网时代，承载网络应用的是通用计算机或者个人终端数字助理，例如手机、iPad等。通信主要关注的是数据流量，也就是带宽，应用主要关注的是界面的友好性、丰富性、个性化。同时，CPU功能比较强大，内存配置等也比较丰富，并不强调实时性，也不特别强调可靠性，开发平台也很一致，功能丰富。

物联网应用开发的挑战

物联网应用，与互联网应用有着巨大的不同，物联网应用开发是典型的嵌入式开发，从硬件配置到运行环境等等，都千差万别。

谈到开发平台，很多人第一反应就是编程语言，从汇编、C、C++、Pascal、VB、VC等编译型语言，到Java、JS、Python、Lua等脚本语言，说得上名字的、说不上名字的，可以罗列出成百上千种，著名的TIOBE，每年都要为各种编程语言排座次。其实要谈物联网开发平台的发展，还得从早期嵌入式系统说起。曾几何时，嵌入式MCU很多只有几十字节的内存，几百自己就算多的了，那时候，汇编语言是嵌入式编程不二的选择。那时候，也没有编程平台的说法的，也没有Shell之类的调试工具，更没有标准IO系统，总之，程序员就像在一堆沙土上盖房子，没有地基，也没有房梁，更没有混凝土，就是用泥浆砖头石块慢慢糊。及后来，出现了单片机前后台C语言（俗称裸机C）开发工具，典型的是keil，同时，也出现了RTOS，例如vrtx、pSOS、VxWorks等，但裸机C语言开发长期占主导地位。早期的C语言开发平台，从平台角度，其实没比汇编年代进步多少，同样的没有Shell、没有标准IO系统，没有异常处理系统，除了编码语言外，差不了太多。虽然代码的可移植性比汇编强，但仍然是跟硬件平台紧耦合的，它要求软件工程师了解硬件的每一个细节，了解CPU每一个寄存器的含义，硬件平台稍有变动，软件就懵逼了。

在裸C时代，首先出手改进开发平台的是MCU厂商，ST、ATMEL、Freescale、NXP等知名MCU厂家，都推出了越来越完善的固件，使用这些固件，尽可能地抹平不同型号CPU之间的差异，使用户的应用程序更加通用。同时，他们还推出了越来越完善的IDE，利用他们的IDE，可以自动化地生成一部分跟CPU相关的代码，减轻了工程师的工作。但是，所有这些工作，都仅限于同一厂家的不同型号MCU之间，甚至只在同一厂家的同一系列MCU之间，才能体现出其价值。为什么MCU厂家要做这些工作呢？因为他们要卖东西，他们的客户，大多数还使用裸机C开发，而不像系统级CPU那样有完善的开发平台支持。他们的客户，迫切需要一个开发平台，来规避晦涩难懂的硬件驱动开发，使应用和驱动相分离。一个非常典型的现象是freescale，它主要为MCU产品线提供驱动固件，而对于PPC产品线，原厂提供的驱动就是垃圾，谁用谁知道。

在物联网时代，也许某一天，牧场跑的每一只羊，农场里的每一株黄瓜，我们喝水的杯子，都是IoT的一个节点，里面都有一颗MCU，都有一套嵌入式程序，如此爆炸性发展的网络规模，使我们面临什么挑战呢？

首先我们面临的是人的问题，海量增加的物联网软件工程师队伍，你再象过去要求嵌入式工程师那样，要求他们掌握大量MCU底层技能，根本不现实，他们需要的是一个开发平台，类似PC上编程的开发平台。而裸机C语言编程，则无论如何也摆脱不了“要求程序员掌握MCU底层编程”这一现实。因此，在物联网时代，RTOS成了必须品，裸机C语言平台，必然会被RTOS环境所替代。这并不是说，物联网时代的嵌入式产品有多复杂，非RTOS不可，可是，再过几年，裸机C编程，会像现在的汇编编程那样，成为“高端技能”。现在，许多嵌入式学科的大学生，在校时就已经基本掌握了RTOS下编程技能，裸机C反倒不懂了。结果是，5年后，你将越来越难于找到能够驾驭裸机C编程的人，即使找到了，其人力成本也必然居高不下，年龄大概也会在30岁以上，你能找一个只有1~2年经验的毕业生干的事情，为什么要花更高的薪水，请“老”工程师干呢。同时，虽然摩尔定律在高性能CPU上已经失效（这个有争议），但在MCU领域，还是符合得很好，硬件的发展，使RTOS带来的额外开销，在成本上显得微不足道。

由于IoT产品必然涉及到网络编程，也就注定了不能使用太低端的处理器配置，硬件成本持续下降，运行RTOS所需要的额外硬件成本，占总成本的比例，直接可以无视之。人力成本持续上升，RTOS甚至更高级的开发平台，将会占领IoT开发领域。

一定会有人问，裸机C不是比RTOS更简单么？我问你，如果只是点个灯，用C简单还是用汇编简单？你也许会毫不犹豫地回答，用C简单。为什么呢？因为开发工具已经完成了大量的工作，有厂家的固件，完成GPIO的驱动，IDE自动生成的代码，完成了main函数之前的大量环境初始化工作。所以，你只需要3分钟，在main函数里放一个循环改变GPIO状态的代码，一个C语言的闪灯程序就完成了。事实上，如果从0开始做，汇编完成闪灯，不知比C简单多少倍。

裸机C取代汇编语言的过程，正在裸机C和RTOS编程之间重演着，不信么？我出个“简单”的题，写一个“hello world”的嵌入式程序看看。

很快，你写出来了，UartSend(“Hello World”)；

别急，我的题还没出完呢，我需要输出“你好，欢迎你第xxx次光临”。

这就难一些了，聪明的，就写一个MyPrintf吧，谁知道这道题还有什么变化呢（注意这里，你不能用printf作为函数名的，下面有解释）。

花了一个星期时间，把MyPrintf弄出来了，效率够高吧？
好吧，你牛，I 服了 You，现在请你把输出重定位到板载的LCD上。
什么，玩我啊，这涉及到IO重定向呢，爷不干了。
光重定向一个输出就不干了，还没有要你把输入重定向一下呢，板子上不是有按键嘛！

IO重定向，是C语言的基本要求，然而，在裸机C环境下，这个基本要求，却让一个裸机C高手望而生畏。

IO服务，只是一个基本需求，它只是C Runtime的一部分，而C Runtime，是IoT开发所需要的进阶工具的基础，恰恰是，裸机C都是很难实现完整的、通用的、可移植的C Runtime。

先爆点料，绝大多数嵌入式RTOS，都没有fopen、fwrite、fread、printf函数，有部分RTOS会有xxx_fopen、xxx_fwrite、xxx_fread、xxx_printf之类的API，即使是一些老牌的商业RTOS也是如此，这里我就不点名了。

没有IO体系的RTOS也就罢了，那些有IO体系的RTOS，为啥要在API前加个xxx呢？你知道加上那个xxx，会给用户添加多少麻烦吗？IoT时代，许多嵌入式软件工程师，原来可能是Windows或者Linux下编程的，他们熟悉c标准函数；嵌入式设备网络化、应用程序通用化的倾向，许多IoT开发会涉及到开源软件或者第三方库，这些开源软件或者库，许多是遵循C语言标准写的，也就是说，里面很可能会大量调用fopen之类的C标准函数。你要用这些开源软件或者第三方库，就必须修改它的源码，把调用C标准IO函数的地方，全部改掉。改就改呗，改了不就行了嘛，有什么大不了的。好吧，如果是二进制的库呢，怎么改？即使是开源软件，维护方升级了，修正了bug，你是不是要再改一次？既然这么多坏处，为啥还要加哪个“xxx”前缀呢？问题就出在标准C库上，因为编译器所带的C库，实现了那些函数，OS如果要自己实现这些函数，就必须先实现C库，而C库，而许多RTOS，并没有实现自己的C库，而是借用编译器提供的C库，自然就不能使用跟C库重名的函数了。

IoT时代的嵌入式开发平台

从完整开发平台的角度，看看几十年来涌现的数以百千计的RTOS，能不能算合格的IoT开发平台呢？答案恐怕是否定的，即使有些非常知名的RTOS，也是如此，有许多RTOS，充其量是一个调度器。有意思的是，从开发平台完整性来看，目前流传的绝大多数嵌入式操作系统，甚至比不上Industrial Programming Inc（IPI）公司在上世纪70年代的MTOS。

那么，IoT时代完整的C开发平台，至少需要具备哪些特征呢？

只有调度器内核是不够的，按今天的标准，它甚至不能称作RTOS，这种系统，权且叫它“裸核”吧，并不比裸机C开发高明多少。用户使用操作系统，目的是为了省事，并没有在操作系统下能干成而裸机C干不成的事情。然而在“裸核”下开发，没有标准驱动框架，没有Shell，没有IO系统，没有C Runtime支持，真的没省多少事。

在“裸核”的基础上，起码，要提供C Runtime，提供C库，使之成为完整的C开发平台，让标准的c程序能编译运行。所谓的标准C程序，不仅仅指符合C语法的程序，C库函数也是标准的一部分，调用标准C库的程序都不能运行，不能算完整的C支持平台吧。要支持完整的C Runtime，你就必须有文件系统，有IO驱动架构，有协议栈等。有了C Runtime，才能支持C++，才能实现Python、Lua、JavaScript等更高级的开发语言，实现IoT设备的快速开发。

即使有了完整的C支持平台，在IoT时代，还是不够的。我要访问一个云服务器，还要自己写Socket通信，从最底层的http编解码开始；我要在设备间交换点数据，或者配置一下设备功能，起码JSON之类的解析器要提供吧。还有，诸如WiFi、蓝牙、ZigBee等，是IoT中最常用的无线协议，也是必须支持的。进一步地，较为复杂的设备，还需要有图形系统支持，一个完善的GUI也是非常受欢迎的了。

总之，IoT时代，需要的是能快速开发IoT设备的平台，而不仅仅是提供一个符合C语法规范的开发平台。

来源： CSDN大数据