MCU面临哪些软件挑战?为什么拓展MCU的潜能需要新的思维方式

控制/MCU

1882人已加入

描述

  为什么拓展MCU的潜能需要新的思维方式

   恩智浦 Brendon Slade

  微控制器(MCU)已经历了无数次技术进步,从硬件加密到复杂的图形功能,然而在此期间,软件开发一直难以跟上这种步伐。这篇博文介绍了工程师在MCU平台上进行软件开发所面临的挑战、恩智浦计划如何应对这些挑战,以及为什么选择能力是未来MCU必不可少的要素。

  硬件能力不断更新,软件开发停滞不前

  与所有电子器件一样,自1970年代首批MCU问世以来,微控制器已经历了巨大的变化。首款真正具有商业价值的微处理器(如无所不在的8051)基于8位技术,并整合了几个计时器、UART端口、ADC,以及DAC(少数产品)。这些器件非常简单,易于掌握,指令集非常小,可以轻松地使用低层语言,如汇编语言。

  快进到2023年,MCU经历了巨大的变化,内存更大、CPU更快,拥有多种外设,从高级电机控制到机器学习(ML)加速器。然而,MCU最重要的一个变化是其内部架构的复杂性增加了,如果没有驱动程序提供对底层硬件的抽象,从零开始为现代MCU编写代码就非常具有挑战性。

  为了帮助工程师对现代MCU进行编码,我们提供广泛的软件解决方案和工具(包括驱动程序和高级配置工具),用户无需进行寄存器级编程。虽然这些工具对于项目实施至关重要,但用于MCU编码的软件基础架构并未达到与硬件相同的高度,导致软件和硬件之间存在巨大的技术鸿沟。

  了解更多。恩智浦开启MCUXpresso生产力新篇章,赋予开发人员更丰富的开发体验

  MCU面临哪些软件挑战?

  无论使用哪个平台,MCU的软件开发都面临着诸多挑战,包括平台锁定、可移植性有限、碎片化、缺乏开源支持、开发人员自由受限和缺少标准化等。

  首先,大多数MCU平台通常会将工程师锁定在固定平台上,因为要将代码移植到其他平台、其他架构或供应商会非常耗时,即使平台使用了相同的处理器内核(如Arm® Cortex-M®)。对于不使用MCU或其外设全部功能的简单项目而言,这可能是小问题,但对于因硬件需求变化而需要切换到其他制造商的项目来说,则可能会带来灾难性的后果。当OEM拥有各种价格和功率需求不同的产品时,不可避免地要使用多种不同的MCU,因此维护多代码基础的成本可能非常高。

  另一个可能影响工程师的软件挑战是IDE差别迥异。工程师通常使用不同制造商的众多设备,因为每个设备只适用于特定的应用。但对每一个平台,工程师都需要了解IDE的工作原理、工具位于何处,以及如何让项目运行。因此,工程师要跟上每个开发环境的新变化可能需要耗费大量的时间。

  此外,MCU供应商很少支持一个以上免费的IDE平台,并且大部分都基于Eclipse,Eclipse被视为软件开发行业的主力。Eclipse作为主流IDE,供应商可高效定制,便于使用,但由于它采用基于Java的内核,对CPU和内存资源需求要求非常高。相比之下,微软的Visual Studio Code(VS Code)非常轻量化和快速,因此许多工程师选择使用VS Code开发环境。

  IAR和Arm Keil是高级开发工具领域久负盛名的专家,他们提供的IDE具有自己的专业调试功能,以及高性能优化编译器和功能安全认证。恩智浦与这两家白金级合作伙伴密切合作,通过MCUXpresso SDK软件包为他们的工具提供开箱即用的支持。甚至这些开发工具巨擘也承认Visual Studio Code广受青睐且具有较高的灵活性,因为它支持多种编译器,用户可借助该工具采用混合方法进行编辑和构建,并结合开发工具领军企业的专业调试经验。

  MCUXpresso for Visual Studio Code介绍

  恩智浦认识到Visual Studio Code对于现代开发人员非常重要,现已推出MCUXpresso for VS Code,该扩展产品为MCUXpresso软件驱动程序和中间件提供全面支持,使开发人员能够使用主流IDE进行快速响应的编码。除了比较传统的MCUXpresso SDK流程外,这款新产品为使用开源Zephyr RTOS的开发人员提供全面支持,与现有解决方案相比,提升了用户体验。

恩智浦

  MCUXpresso for Visual Studio Code功能框图

  MCUXpresso硬件抽象层

  为了方便工程师在不同MCU平台之间移植代码,恩智浦即将推出新的硬件抽象层(HAL),为开发人员提供一组适用于i.MX RT、LPC5500和MCX MCU的API。随着新HAL的推出,恩智浦MCU代码可以完全移植到广泛的产品组合中,用户可在众多功率/性能之间进行选择,不存在代码移植障碍。

  尽管HAL的推出本身并不新鲜,但它基于与其他平台已使用的开源代码API定义,体现了恩智浦致力于为用户提供选择能力的承诺。通过这种方法,工程师不仅能够在不同的恩智浦器件中自由迁移,甚至还可以将他们的代码传输给其他芯片供应商。这种灵活性为设计人员提供了极大的自由,他们能够编写不锁定在某个硬件平台的MCU代码,从而使固件设计更贴近不受设备局限的未来。

  恩智浦和Open-CMSIS-Pack

  在MCU解决方案中使用中间件变得日益重要。由于MCU设计和应用要求的复杂性不断增加,工程师开始转向能够提供高级功能的软件库,例如图形处理、网络协议栈、USB设备枚举、音频功能,甚至ML/AI。在这些情况下,试图将其它公司提供的第三方中间件纳入项目会非常具有挑战性,因为某个供应商的软件在形式和风格方面可能与其它供应商的软件不同。因此,可能需要手动执行几个步骤,将外部软件重新构建到所需的文件夹并集成编译命令,并且在供应商每次交付新库时都会出现这些问题。

  为了帮助工程师将中间件纳入其项目中,MCUXpresso生态系统中的所有IDE现在都支持Open-CMSIS-Pack。这些完整的软件产品使用特定的标准和形式进行封装,使IDE能够自动识别内容、将所需的文件添加到项目中、配置Build工具,并提供API访问。由于依赖性已整合到Open-CMSIS-Pack中,工程师不必花费数小时从不同的位置下载单独的文件,也不需要检查下载的版本是否兼容。

  为什么选择能力会决定MCU设计的未来

  计算机行业朝着统一和开放标准发展,同样,MCU生态系统也可以效仿,从而打造新环境,让固件工程师编写代码时不受硬件的限制。这并不意味着硬件将变得不重要;相反,硬件将继续在产品设计中发挥重要作用。变化在于,创建固件的用户不必再担心代码可移植性、哪些设备在执行他们的软件以及软件如何与硬件对接等问题。

  MCU采用统一的行业标准,也将推动开源软件的迅速普及。如果MCU软件具有较高的可移植性,用户可轻松共享MCU代码,因为它适用于更多的平台。这有助于加速开源项目,因为与不同芯片供应商合作的工程师都可以使用自己的原生平台共同开发互惠互利的软件解决方案。

  在MCU之间引入HAL开放标准也有助于鼓励新制造商采用这些标准,因为他们的设备将与大多数(如果不是全部)现有软件解决方案兼容。因此,新的MCU可以快速普及,从而提高工程师使用先进解决方案的速度,而无需重新在软件资源方面投入大量资金。

  这种选择能力最终将缓解MCU行业的碎片化问题,这难道不是当今开发人员所希望的吗?

  作者

  Brendon Slade

  恩智浦通用MCU生态合作体系总监

  Brendon Slade是通用MCU生态合作体系团队总监。他在DSP和微控制器行业拥有超过25年的经验,曾在工业、移动、汽车、语音通信和音频处理市场方面担任设计、应用和技术营销职务。他的团队专注于支持恩智浦基于Arm® Cortex®-M的MCU,与合作伙伴和恩智浦的内部软件团队合作,定义并交付互补的开发工具和软件解决方案。他毕业于英国普利茅斯大学(University of Plymouth),现居加利福尼亚州桑尼维尔,拥有调试技术专利。

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

全部0条评论

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

×
20
完善资料,
赚取积分