MCU和EFM8BB1LCK开发板评测

     拿到这个板子, 可以说没有什么惊奇.这个板子从外观还是功能讲, 在笔者最近用过的板子中可以说非常普通. 不过评价一个板子并不能仅仅从外貌出发吧, 借着这次评测机会, 想跟大家聊聊嵌入式处理器的一些个人看法.

     近年来,随着工艺与IP的逐渐成熟, 32bit的MCU增长迅速, 风头之劲乃至于16bit的MCU基本上被跳过了. 现在说嵌入式MCU, 要么就是8bit, 要么就是32bit, 16bit的MCU产品型号屈指可数:

     1. Intel公司曾经想在8051上逐渐升级的80251, 现在市场上基本见不到踪影. 细心的程序员可能还会注意到Keil现在还有C251的开发工具出售. 某些过时的大学教材中也有过80251的痕迹. 但是至少在中国市场上, 80251没有存在感.

     2. TI的MSP430, 主打低功耗, 随着其他厂商也在低功耗上下功夫, MSP430的低功耗特性也不再是独门绝技.在市场上的份额也是逐渐萎缩.

     3. 还是TI的一些16bit的DSP, 主要是定点DSP. 在电机控制领域还有一些份额. 主要是厂商在垂直领域做了很多优化.从产品本身来讲, 这种非主流的DSP必要性也在慢慢降低.

     4. Microchip的dsp24系列, 跟TI的16bit定点DSP情形相似.

     5. 英飞凌的C166系列, 主打汽车市场. 也是着重于存量市场.

     6. 凌阳的一个16bit系列, 主打简单语音处理应用. 上大学我还学过一阵子, 但是现在连型号也不记得了.

 

     当然还有一些专攻垂直领域的产品, 这里不多说了.

     可以看出的是16bit的MCU并没有像人们曾经想象的那样, 替代8bit的市场份额, 在市场上唱主角若干年后再被32bit的MCU取代. 现代嵌入式处理器市场的现实是: 简单的任务还是基本上使用8bit的内核, 有一定复杂性的应用就会使用32bit的MCU. 16bit的MCU处理能力不及32bit, 成本功耗上不及8bit, 所以市场份额一直没有起来.

那么8bit的MCU的情形又如何, 很多嵌入式工程师都有一些误解. 下面来简单分析下.

 

关于8 bit的误解

 

8位处理器正在被淘汰

 

     这是最常见的误解, 先说事实: 根据最新的Gartner的市场报告. 8bit的市场营收额和增长额跟32bit的相比都仅仅差几个百分点. 考虑到8bit的单个芯片比32bit芯片要便宜很多的事实, 8bit的出货量其实远高于32bit的.

     打个直观的比方, 现在我们有了高铁, 是不是所有传统的普快,特快火车都要立即淘汰呢. 显然事实并非如此, 至于原因就太多了.现实情况就是8bit的MCU曾经的应用领域并不能立即用32bit的MCU直接替代.

 

8位处理器缺乏创新

 

     不少人会认为既然现在市场的宠儿是32bit的MCU, 厂商们是不是都没有投入研发资源在8bit产品上了. 这么想的人可能一想到8bit的MCU, 脑海中会浮现40DIP的”经典8051”的形象.

     事实上芯片厂商们并没有停止创新, Silicon labs这样的厂商同时有32bit与8bit的产品. 但是在8bit产品线上的创新一直没有停止. 比如CIP-51内核因为采用了一个时钟周期等同于一个指令周期的设计, 瞬间将同频率的8051性能提高了12倍. 国内的一些半导体厂商也有基于8051或其他8bit内核的创新.

 

8位处理器难以使用C/C++语言编程

 

     如果你了解Arduino的设计原理, 这个误解就不攻自破. 当然坦白讲, 8bit的MCU使用高级语言编程确实比32bit的MCU要困难些. 主要障碍就是内存地址的不统一. 比如8051内核的内存地址就分为CODE, data, sfr, idata, xdata. 如果涉及到banking就更复杂了. 8bit的PIC还有硬件Stack这样更加”非主流”的设计. 但是这些障碍都可以通过工具的优化来缓解.

 

8位处理器专为简单应用而生

 

     这个观点倒是有几分真实, 但是嵌入式应用本身就是简单应用居多. 嵌入式系统应用的本身特点决定了8bit依然有很多用武之地. 外设, 编译器的进化将慢慢拓展8bit处理器的应用范畴.

 

8位处理器不能胜任IoT应用需求

 

     IoT应用不是一个单独的应用, 而是一个复合应用. 智能手表, 智能音箱, 主控制器, 网关这种当然需要复杂的处理器来实现. 但是IoT应用还包含大量的传感器节点, 执行节点, 转换节点. 这种节点用低功耗的8bit处理器来实现更加适合.

 

8位处理器响应慢

 

     这个就是完全的误解了, 典型的嵌入式应用中, 响应速度主要跟中断响应和唤醒延迟相关. 8bit处理器有天然的优势(地址转换工作量小, IP单元实现门数少). 至少不输于32bit的处理器.

 

8位处理器的能效低于32位处理器

 

     曾经看过ARM公司的权威工程师写的一本书, 书中观点是32bit处理器的能效比高于8bit的MCU. 理由是32bit处理器能快速处理完任务, 休眠时间的比例更大. 但是这个结论包含一个假设, 就是任务有一定复杂度, 如果任务本身非常简单, 唤醒过程的功耗也很大, 那么这个假设不成立. 针对不同应用场景, 不能简单说8bit, 32bit哪个能效比更高. 至少非常简单的应用中, 8bit的能效比要高. 如果再加上单独响应,无需CPU干预的一些任务, 8bit的能效比甚至能高出很多.

 

相同价格的32位处理器功能远强于8位处理器

 

     这个也有一定程度的可信度. 但是不要忘记有相当大的一部分的应用, 使用8bit的MCU就足够的情况下, 非要购买平均价格高一点的32bit MCU, 成本是会上升的. 很多基本上标准化了的嵌入式产品有很大的量, 就会发现8bit的成本优势还是会高一点的.

 

8位处理器设计的应用不能适应未来变化

 

     这是个思维角度问题, 作为嵌入式程序员, 更应该是考虑当前的任务. 不管是什么类型的MCU, 如果产品形态变化了或者需求本身变化了,就要重新设计. 未来谁都看不清, 何必考虑那么多没有实际意义的前瞻.

 

8位处理器开发工作更繁重

 

32bit处理器的处理更加以软件中心, 可以做更多的代码复用. 8bit处理器更多地利用硬件外设来完成任务. 综合而言, 没有绝对的差别.

 

8位处理器没有升级路径

 

     只要是嵌入式处理器, 升级路径都不大明确. 如果你采用既有8bit, 又有32bit的产品的厂家, 你会发现很多外设都很相似. 考虑到现在图形化配置外设的趋势, 升级路径逐渐变得不那么重要, 反正都是图形化或者脚本化来生成基础驱动代码.

 

EFM8BB1芯片

芯片亮点:

 

     1. 内核是8051世界中的明星:CIP-51. EFM8BB系列中这个内核最高25MHz,相当于经典8051跑在300MHz. 使用内部时钟可以跑在24.5MHz, 相当于经典8051跑在294MHz.

     2. 内部低速时钟,80KHz与24.5MHz的内部高速时钟互为补充, 方便低功耗设计.

     3. 16-bit CRC硬件计算单元

     4. AEC-Q100认证, 套用一句广告语:“不是所有的MCU都能过AEC-Q100认证”. 通过这个认证表示可以使用在汽车级别的恶劣环境.

     5. 其余特点不用单独拿出来讲, 但是很多人会忽视的一个亮点就是Silicon Labs的图形配置开发工具界面, 能大大节省开发时间.

软件开发-Simplicity Studio+图形化配置

     关于图形化配置式开发

 

     顾名思义, 所谓的图形化配置就是通过GUI方式来配置外设, 生成代码. 这一点很重要, 因为现代MCU的外设越来越多, 越来越复杂, 涉及到的初始化配置非常繁琐, 容易出错, 已经不适合工程师慢慢查阅动辄几百,几千页的参考手册来手动书写寄存器读写代码. 除了外设配置之外, 还有IO分配, 纯软件组件的配置,时钟树的配置, 这些重复机械的工作以前都是工程师手工完成的. 目前市场上领先的MCU厂家都有自己的图形化配置工具, 可以说图形化配置工具+优化过的编译链接工具链+图形化的调试工具是现代嵌入式开发的必不可少的三项标配. 笔者印象中,Silicon Labs公司是最早推出图形化配置工具的MCU厂家之一. 当然最初的工具只能配置Cross Bar, 解决IO口分配问题. 经过多年进化, Simplicity Studio内置的配置工具现在已经非常完善了, 很多功能笔者现在也还没有用到过. 

 

     关于8051编译工具链

 

     工程师们所熟知的8051的C语言工具链:

     1. 当然就是Keil了,Keil已经被ARM收购了, 现在可能更著名的产品是ARM内核的开发工具.但是8051工具链还是业界最著名的8051商业化开发工具. Silicon Labs跟ARM/Keil达成某种合作关系, 凡是购买这块开发板的用户都可以免费使用全功能版本的Keil工具链. 这个工具链跟Silicon Lab的Simplicity Studio结合的很完美. 如何安装工具, 配置编译器请看后文的参考连接.

     2. IAR. 以优化为特点.

     3. Tasking, ICC这些公司也有8051的编译工具链产品, 本人很少用, 不评价.

     4. 曾经有开源的SDCC工具链对8051内核支持也很好. 但是这个工具链至少有如下缺点.

         4.1 没有商业化的支持, 很多新型芯片的头文件没有及时更新, 对工程开发是个障碍. 起码程序员需要自己建立具体型号的头文件, 连接配置. 这些工作并没有什么附加值.

         4.2 图形化配置功能外设, 生成代码, 配置引脚这些功能没有商业化的支持, 不可能做的好.

         4.3 对仿真,调试支持的不好

         4.4 开源产品, 缺乏维护, 生成的代码正确性, 优化效果只能靠程序员自己去慢慢踩坑.

     综上所述, 本人并不看好开源的8051工具链. 至于高质量的gcc,llvm为什么一直没有支持8051这样的内核呢. 这是因为这些MCU的内存分布并不标准, 而且完整的LibC尺寸太大,直接让gcc,llvm产生可以用于实际生产环境的8051可执行代码非常困难. 上述的SDCC工具链也是一种特殊的支持8051的GCC版本. 算是开源界对8051内核的一次已经被放弃的尝试.

     现在随着市场形态的进化, 商业化的工具链越来越容易获取. 比如购买了本开发板的程序员就可以免费得到完全版本的Keil 8051工具链, 再加上Simplicity Studio本身具有的图形化的配置,调试功能. 现在的8051程序员们可以说非常幸福了.

     至于不使用C语言, 直接使用汇编语言设计整个工程的做法, 笔者并不提倡. 程序员最宝贵的就是开发与调试时间, 应该抓住重点.

跑个分: CRC16硬件加速

EFM8BB1的硬件CRC16单元有两个功能:

     1. 接受软件指定的字节流计算CRC16

     2. 自动对Flash内容进行CRC16计算.

 

如果对功能安全有所了解, 这个CRC16硬件加速单元可以帮工程师很大的忙. 这里用几种不同的方法来计算CRC16, 来跑个分. 参赛选手(除非另外说明, 编译器都为Keil, 优先级最高, LibC使用高效率版本, 数据模型为small):

     1. EFM8BB1上的硬件CRC16计算单元(运行在24.5MHz)

     2. EFM8BB1上的软件实现的CRC计算函数(运行在24.5MHz)

     3. 另外一款32bit的MCU使用软件实现的CRC计算函数(Cortex M0, 运行在32MHz)

     实际的测试工程都在后文的下载链接中可以找到, 重要测试代码, 分别是软件CRC16与硬件计算函数:

跑分结果:

可以看出:

 

同样频率下(24.5MHz), 硬件CRC16单元的效率是软件CRC16函数的2.8倍, 跟更高频率(32MHz)的Cortex M0的软件实现版本类似. 而经过频率调整(即运算效率除以运行频率)后, 硬件CRC16单元比Cortex M0的软件实现版本的效率更高.

 

总结与参考

 

目前而言, 8位MCU过时的那一刻还远远没有到来. 大多数复杂度较低, 可以使用硬件单元加速的嵌入式应用选用8位MCU能达到最佳ROI. 使用先进的开发工具, 配合设计合理的外设, 8bit的MCU上的软件开发工作也会非常简单高效, 如上文所是的硬件CRC16计算函数只有几行. 嵌入式工程师在选型时, 要注意上述演示得出的一些结论.

 

官方Silicon Labs的EFM8BB1LCK页面: https://www.silabs.com/support/getting-started/microcontrollers/efm8-mcu/efm8bb1lck-busy-bee-mcu-low-cost-kit

笔者不是很感冒, 但是很多人希望了解下的开源8051工具链SDCC: http://sdcc.sourceforge.net/

 

代码工程下载: https://github.com/zhanzr/efm8bb1lck-demo.git