Open wsxk opened 8 months ago
https://wsxk.github.io/iot_dev_tech_three/
设计硬件抽象层
6.1 由eCos \& amp;Android的系统架构谈起 6.2 HAL vs. BSP 6.3 为什么会需要HAL? 6.4 HAL是否会增加开发难度?
菜鸟当自强：软件工程师硬起来
做好存储器管理
存储器管理（II）：NAND Flash概论
模拟器
Callback Function
用C来实作面向对象的概念
这个架构同时要支持两种系统（RTOS与Embedded Linux），但我们又希望driver可以共享，不要有两套，否则maintain将会是个大麻烦，所以在driver上再加了一层HAL，所谓HAL就是将硬件抽象化，Linux可以基于HAL再往上开发自己格式的driver。 HAL的另一个好处是就算硬件配置做了修改，也只需要修改driver，两方系统都不需要大更动。 6.1 由eCos & amp;Android的系统架构谈起 般通用性的嵌入式操作系统，如VxWorks、μCOS II等，可能应用在截然不同的产品上，硬件配置南辕北辙，所以很难去定义通用的HAL;但如果我们的产品线定义颇为明确的话，若希望我们的系统能够具有可扩展性，可以用较少的effort来执行未来的项目，那么，HAL就不可或缺。 Open Source的嵌入式操作系统——eCos，它的系统架构就明确定义了HAL这一层 我们来看另一个例子。最近火红的手机系统Android，因为Android的应用锁定在手机上，且智能手机的硬件架构差异有限，所以可以看到Android的HAL中就包含了许多硬件设备。 举例来说，不同的手机制造商可以选用不同的GPS硬件模块，只要能按照Android HAL中对GPS设备所定义的行为模式（如送出位置信息的格式），并包装出指定的API，则其他程序都不需要修改，内置的导航应用程序应该就可以正常运行。 6.2 HAL vs. BSP HAL之前已经提到很多了，现在具体说说BSP的定义 ■ BSP（Board Support Package）：BSP介于主板硬件和操作系统间，其功能与PC主机板上的BIOS相类似，主要功能为完成硬件初始化，并切换到相应的操作系统。
■ BSP是相对于操作系统而言的，不同的操作系统会对应于不同定义形式的BSP。例如，某一CPU上的VxWorks BSP和Linux BSP，尽管实现的功能一样，但写法和接口定义是完全不同的。
■ BSP单纯只支持某个硬件板子的配置，无法用于其他板子、CPU或操作系统。举例来说：微软定义BSP是由Boot-loader、OAL（OEM Adaptation Layer）、Device Driver及Run-Time Image Configuration File这几个组件所构成。
所以BSP和HAL是不一样的东西，应用时机也不同。BSP是针对某个板子的硬件配置，进行驱动程序套件开发，并包装出某种OS的接口，让使用者拿到板子后，可以很快地将OS与应用程序移植到这个板子。Linux、VxWorks、Microsoft Windows Mobile都有BSP这样的说法 相较于HAL，BSP是一专用于某个板子、某种系统的一组驱动程序套件，但HAL是一种概念、一组作为系统标准的API。嵌入式系统基本上是个分层架构，上层通过下层提供的API与下层沟通，而分层的好处就在于只要API不变，上层不需要知道下层的实现方式与细节，就算下层模块整个切换或全部改写，上层程序都不需要修改. 6.3 为什么会需要HAL? 很简单，为了减少未来开发的成本，建立商业竞争的领先 假设第一代产品大卖，此时竞争对手肯定会争相研发同样的产品，为了保持自身的领先，此时当然需要投入资源到第二代产品的开发当中，此时，如果第一代产品设计了HAL，那么进行第二代产品开发说，会大大减少开发成本和时间耗费。 6.4 HAL是否会增加开发难度? 直接说结论：不会 通常我们实现HAL的流程如下: Step01：定义HAL的规模（Scope）。根据产品特性，分析上层的系统与应用程序需要哪些硬件功能，这些需求就是HAL必须要包含的基本模块，然后再根据硬件配置，分析是否仍有目前系统没用到的硬件功能，这些功能可能在下一代产品就会被用到，我们可为其设计相应HAL模块的API，但在本项目内可先不implement。
Step02：定义HAL API。如果可以的话，最好从硬件到应用程序的开发小组，都要派人员参与HAL设计工作，否则至少要有资深的系统与固件工程师参与，不能仅由一个部门闭门造车。一般定义HAL API步骤为： □ 系统工程师说明系统需求，包含系统对硬件事件的处理方式。 □ 固件工程师根据硬件功能，提供第一版的HAL API定义文件。 □ 系统工程师协同固件工程师，逐一review HAL API。 □ 在HAL API立项前，必须针对项目中的所有软件工程师做详细报告，收集建议，并做必要的修正。
Step03：由固件工程师负责实现所有HAL的功能，并执行每个模块的单元测试。
Step04：固件工程师release第一版HAL library，由系统工程师负责整合测试，若有需要。各个部门随时可以提出对HAL API增修的建议。
HAL的设计立项后，固件工程师就是照着文件去implement，而系统工程师就被规范只能用HAL API来控制硬件，并不会增加工程师们在实作阶段的工作量。就算系统架构中没有HAL，一般driver的开发流程和上述步骤也差异不大吧. 没有人能够一开始就预知未来，所以不可能直接开发出完善的HAL，只要后续能继续补上就可以了
Callback Function 附录B
用C来实作面向对象的概念 附录C
https://wsxk.github.io/iot_dev_tech_three/
设计硬件抽象层
6.1 由eCos \& amp;Android的系统架构谈起 6.2 HAL vs. BSP 6.3 为什么会需要HAL? 6.4 HAL是否会增加开发难度?
菜鸟当自强：软件工程师硬起来
做好存储器管理
存储器管理（II）：NAND Flash概论
模拟器
Callback Function
用C来实作面向对象的概念
这个架构同时要支持两种系统（RTOS与Embedded Linux），但我们又希望driver可以共享，不要有两套，否则maintain将会是个大麻烦，所以在driver上再加了一层HAL，所谓HAL就是将硬件抽象化，Linux可以基于HAL再往上开发自己格式的driver。 HAL的另一个好处是就算硬件配置做了修改，也只需要修改driver，两方系统都不需要大更动。 6.1 由eCos & amp;Android的系统架构谈起 般通用性的嵌入式操作系统，如VxWorks、μCOS II等，可能应用在截然不同的产品上，硬件配置南辕北辙，所以很难去定义通用的HAL;但如果我们的产品线定义颇为明确的话，若希望我们的系统能够具有可扩展性，可以用较少的effort来执行未来的项目，那么，HAL就不可或缺。 Open Source的嵌入式操作系统——eCos，它的系统架构就明确定义了HAL这一层 我们来看另一个例子。最近火红的手机系统Android，因为Android的应用锁定在手机上，且智能手机的硬件架构差异有限，所以可以看到Android的HAL中就包含了许多硬件设备。 举例来说，不同的手机制造商可以选用不同的GPS硬件模块，只要能按照Android HAL中对GPS设备所定义的行为模式（如送出位置信息的格式），并包装出指定的API，则其他程序都不需要修改，内置的导航应用程序应该就可以正常运行。 6.2 HAL vs. BSP HAL之前已经提到很多了，现在具体说说BSP的定义 ■ BSP（Board Support Package）：BSP介于主板硬件和操作系统间，其功能与PC主机板上的BIOS相类似，主要功能为完成硬件初始化，并切换到相应的操作系统。
■ BSP是相对于操作系统而言的，不同的操作系统会对应于不同定义形式的BSP。例如，某一CPU上的VxWorks BSP和Linux BSP，尽管实现的功能一样，但写法和接口定义是完全不同的。
■ BSP单纯只支持某个硬件板子的配置，无法用于其他板子、CPU或操作系统。举例来说：微软定义BSP是由Boot-loader、OAL（OEM Adaptation Layer）、Device Driver及Run-Time Image Configuration File这几个组件所构成。
所以BSP和HAL是不一样的东西，应用时机也不同。BSP是针对某个板子的硬件配置，进行驱动程序套件开发，并包装出某种OS的接口，让使用者拿到板子后，可以很快地将OS与应用程序移植到这个板子。Linux、VxWorks、Microsoft Windows Mobile都有BSP这样的说法 相较于HAL，BSP是一专用于某个板子、某种系统的一组驱动程序套件，但HAL是一种概念、一组作为系统标准的API。嵌入式系统基本上是个分层架构，上层通过下层提供的API与下层沟通，而分层的好处就在于只要API不变，上层不需要知道下层的实现方式与细节，就算下层模块整个切换或全部改写，上层程序都不需要修改. 6.3 为什么会需要HAL? 很简单，为了减少未来开发的成本，建立商业竞争的领先 假设第一代产品大卖，此时竞争对手肯定会争相研发同样的产品，为了保持自身的领先，此时当然需要投入资源到第二代产品的开发当中，此时，如果第一代产品设计了HAL，那么进行第二代产品开发说，会大大减少开发成本和时间耗费。 6.4 HAL是否会增加开发难度? 直接说结论：不会 通常我们实现HAL的流程如下: Step01：定义HAL的规模（Scope）。根据产品特性，分析上层的系统与应用程序需要哪些硬件功能，这些需求就是HAL必须要包含的基本模块，然后再根据硬件配置，分析是否仍有目前系统没用到的硬件功能，这些功能可能在下一代产品就会被用到，我们可为其设计相应HAL模块的API，但在本项目内可先不implement。
Step02：定义HAL API。如果可以的话，最好从硬件到应用程序的开发小组，都要派人员参与HAL设计工作，否则至少要有资深的系统与固件工程师参与，不能仅由一个部门闭门造车。一般定义HAL API步骤为： □ 系统工程师说明系统需求，包含系统对硬件事件的处理方式。 □ 固件工程师根据硬件功能，提供第一版的HAL API定义文件。 □ 系统工程师协同固件工程师，逐一review HAL API。 □ 在HAL API立项前，必须针对项目中的所有软件工程师做详细报告，收集建议，并做必要的修正。
Step03：由固件工程师负责实现所有HAL的功能，并执行每个模块的单元测试。
Step04：固件工程师release第一版HAL library，由系统工程师负责整合测试，若有需要。各个部门随时可以提出对HAL API增修的建议。
HAL的设计立项后，固件工程师就是照着文件去implement，而系统工程师就被规范只能用HAL API来控制硬件，并不会增加工程师们在实作阶段的工作量。就算系统架构中没有HAL，一般driver的开发流程和上述步骤也差异不大吧. 没有人能够一开始就预知未来，所以不可能直接开发出完善的HAL，只要后续能继续补上就可以了
菜鸟当自强：软件工程师硬起来
做好存储器管理
存储器管理（II）：NAND Flash概论
模拟器
Callback Function 附录B
用C来实作面向对象的概念 附录C