网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
2、硬件平台各式各样,接口难以统一
3、功能差异性导致软件模块化极其有限
4、嵌入式系统不支持硬件抽象
这也是芯片供应紧缺或升级迭代加快,频繁更换物料时嵌入式设备软件开发所面临的问题,重复的无用功太多。
如车载空调ECU零件(Electronic Control Unit 电子控制单元),在A款车型上进行首次开发,可通过实体按键操作调节温度。但是同样的空调、同样的ECU,换到B款车型上做开发时,想用中控大屏幕来控制温度,之前写的控制代码就不管用了,需要从头开始重新开发。或者说,同样的A款车型,想升级换另一个空调零件,那么软件也得重新开发。
深度耦合的架构,导致新项目很难复用以前的代码,几乎每一个新项目都是从头开始。
而AUTOSAR的目的就是建立分层的体系架构和制定接口规范,将分层架构高度抽象,使得汽车嵌入式系统软硬件耦合度降低。
应用软件层专注于业务功能开发,不关注底层硬件细节;基础软件层针对不同的硬件适配提供基础接口,不关注业务逻辑。各个供应商或厂家按统一的标准实现各自的功能,互不干扰。
基础软件层框架:
基础层基于硬件实现基础的驱动功能,类似BSP效果,但进行了一定抽象封装,与硬件解耦。
应用层实现业务功能,为保证业务功能和底层的解耦,中间是运行时环境RTE隔离。RTE是AUTOSAR 体系的核心,支持软件组件间、基础软件间、软件组件与基础软件之间的通信。
AUTOSAR的标准化,使软件开发合作如同堆积木一样,可以按需修改和更换不同的子模块,其核心思想是“统一标准、分散实施、集中配置”。软件系统的开放化和标准化提高软件开发的效率和质量。
2、软件分层实施
软件分层理论不错,但如汽车电子的AUTOSAR的复杂架构需要工具配置保证接口和规范,对于消费电子或者小公司无法满足条件的,如何结合实情进行简化实施呢?
以电子产品充电时需要亮LED为例,即主芯片的某个GPIO控制LED亮灭的需求,抛砖引玉的发表见解。
主控芯片可能有C1、C2、C3三种,而不同的产品形态导致硬件布局差异,即使都是C1主控方案,可能采用P1、P2、P3三个引脚的其中一个用于LED控制,对于点亮LED,P1、P2是输出高亮灯,而P3是输出低亮灯。
针对这个需求,充电时亮灯属于业务需求,按需求执行亮灯接口;底层提供GPIO输出,对于LED的控制属于运行时环境。为了简化称呼,自定义为三层结构,即平台适配层—功能组件层—业务层 ,最下层为芯片原厂库或者SDK。
软件开发从底层开始,不同的芯片控制GPIO的接口不同,因此需要封装一层,使用固定的pal_gpio_write接口。至于最终使用哪颗芯片的HAL库或者SDK,需要根据芯片类型配置决定,这样功能组件层不关注芯片差异导致的GPIO控制接口差异,只需要关注具体的GPIO引脚,而这个由LED功能里的配置决定。最终提供给业务层的接口就只有led_charge_show(),具体这个接口运行在什么平台、控制哪个端口都是封闭的。对于业务层开发,只需要知道,充电时LED的工作状态执行led_charge_show即可,其内部细节不关注。
这其中除了C源码开发,对脚本处理及其扩展也是软件分层实现的基础,仅仅使用IDE开发工具是无法做到的。按开发环境选择合适的脚本语言,分层配置,最后统一使用某个项目宏,即开启对应的项目宏。编译时选择对应的C文件或者宏定义,实现一套代码选择性的编译匹配不同的硬件主板或软件需求。脚本方面可以参考微信公众号 嵌入式系统 的 《项目配置与编译自动化》。
3、小结
因为接口标准化,软件与硬件解耦,业务逻辑和驱动模块解耦,功能组件相互独立解耦,软件复用度提高,多人并行开发,软件质量和进度大大提高。
分层隔离的优点很多,但也存在些弊端。
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!**