IOT跨平台组件设计方案

组件设计示意图

组件设计原则

1. 组件内部不能互相显式调用，上层组件可以依赖下层组件接口，不同组件之间可以隐式调用；
2. 一个组件实现一个功能；
3. 组件分类为通用组件、基础组件、业务组件、应用组件。

组件类别	组件说明
平台组件	平台相关的硬件抽象层，抽象硬件基础能力，比如PWM，FLASH、UART、TIMER等，兼容不同厂家SDK，向上层业务提供统一接口，连接业务和不同芯片平台，其它组件可以显式调用；说明：不同协议，不同芯片平台驱动实现有差异，建议分芯片平台抽象组件，比如ST的芯片是一个组件，乐鑫的硬件抽象层放到一个组件；虽然不同芯片类型的驱动能力放到不同组件，但是各芯片的sal接口命名是统一的，可以由上层业务统一显式调用。
通用组件	集成通用工具，比如：字符处理，信号数据解析，加解密接口等
业务组件	就是实现IOT业务，比如设备监控组件、设备统计报表
应用组件	对高频定制业务的抽象，需要适应本地业务变化，持续集成，比如：遥控器/按钮对应的功能库，大客户定制业务等。问题：考虑后续集成功能规模较大，Flash资源可能不够。暂行办法：拆分成颗粒度适当的组件，通过配置项配置；优点：不使用的组件不占用硬件资源；缺点：颗粒度太小，组件数量太多，不好管理。

4. 组件下沉 比如业务组件的重复功能，可以抽象成为应用组件
5. 单独物理隔离 每个组件都可以单独编译，不能出现不编译某个组件编译报错的情况（个别基础组件除外）；
6. 保持兼容性 组件接口分为：兼容性接口，非兼容性接口两种，实际情况也是如此，很难做到所有接口兼容；但是原则上讲，尽量做成兼容接口；

平台适配

1. 硬件适配 对不同硬件的适配，通过增加一个软件抽象层实现，以C语言为标准，格式类似 manufacturer_sal_xx()，一般芯片厂商都提供了硬件抽象层manufacturer_hal_xx()，但是有些厂商的原厂SDK接口没有抽象hal层。所以如果是已经提供了manufacturer_hal_xx() 接口那么只需要再抽一个manufacturer_sal_xx.h头文件接口，如果芯片平台调用的原厂SDK没有提供hal层，那么需要新增两个文件作为软件适配层，分别是：manufacturer_sal_xx.h，manufacturer_sal_xx.c；manufacturer_sal_xx.h
2. 系统适配 由于目前很多WiFi芯片是基于RTOS进行应用开发，BT和ZigBee更多是基于裸机开发，那么跨平台组件就涉及到是否支持OS的适配问题，RTOS内核主要包括几大模块：线程管理，任务调度，线程通信，内存管理、时钟管理，中断管理；但是由于有些模块在裸机上实现比较复杂，考虑到当前业务场景的使用频率，暂时只实现部分OS接口适配，分为兼容性适配层和非兼容性适配层，其中裸机实现比较复杂的放到非兼容性适配层。针对OS和裸机接口需要再做一个适配层，这个适配层和上述硬件适配层的sal功能类似。
   兼容性适配层
   : 定时器定时器
   : 内存管理
   : 消息队列
   非兼容性适配层
   : 线程管理
   : 互斥锁
3. 通信适配 以C语言特性为例
   通信能力主要是指上下行数据，对于设备端而言，也就是指令接收和数据上报，不同芯片平台的上报接口也不同。由于三种芯片平台的通信能力不同，数据链路不同，数据格式也不同，为了抽象不同平台的通信能力，将数据上报抽象成句柄的方式，句柄包括WIFI，BT、ZigBee设备的上报能力；不同芯片平台只需要给句柄赋值，然后调用接口即可。不同芯片平台收到的数据也不同，那么对于组件而言，如何适配这些不同格式的数据？答案是：组件不适配。不同的芯片平台，数据格式不同，这些数据在业务逻辑层转换成组件支持的数据格式，比如收到的是压缩数据，就先将数据解压，然后才能被组件解析。
4. 功耗适配 关于低功耗实现，很多芯片是放在sdk上处理，如果应用上有显式调用就抽出来；平台有用到就抽出来，没用到就空函数。