第五章 系统内核！.pptVIP

第五章 系统内核 第五章 系统内核 硬件抽象架构 任务和调度 系统启动顺序 资源仲裁 微控制器的电源管理 外围设备的电源管理 串口通信 1、硬件抽象架构 TinyOS 2.0采用硬件抽象架构（Hardware Abstraction Architecture，HAA）的组件设计模型，一方面可以提高代码的可重用性和可移植性，另一方面可以实现效率和性能的优化。 基于抽象化的三个不同级别，采用三层结构的硬件抽象化设计，大大提高了底层硬件平台和独立于平台的硬件接口之间的兼容性。 顶层抽象提供平台无关的硬件接口，便于代码移植； 中间层抽象带有丰富的硬件相关的接口，有助于提高效率； 而底层抽象则与硬件的寄存器和中断密切相关。 存在着一条分界线，在线上软件组件是平台独立的，而在线下的组件是为一个硬件平台特别编写的。 硬件表示层 属于硬件表示层（Hardware Presentation Layer，HPL）的组件直接位于在硬件/软件的接口之上。 其主要任务是表示硬件的功能。组件访问硬件的一般方法是通过内存或者I/O映射。 HPL组件提供的接口完全由硬件模块的本身功能决定。 每个HPL组件都应该有： 为了实现更有效的电源管理，必须有硬件模块的初始化、开始和停止命令； 为控制硬件操作的寄存器提供“get”和“set”命令； 为常用的标志位设定和测试操作提供单独的命令； 开启和禁用硬件中断的命令； 硬件中断的服务程序。 硬件适配层 硬件适配层（Hardware Adaptation Layer，HAL）的组件是硬件抽象架构的核心部分。它们使用由HPL层提供的原始接口，建立起有用的硬件抽象，并隐藏硬件资源的复杂性。 允许HAL组件持有可用于资源仲裁和控制的状态变量。 HAL组件应当使用丰富的、定制的接口，而不是那种通过重载命令隐藏掉所有功能的标准接口。 硬件接口层 硬件接口层（Hardware Interface Layer，HIL）使用由HAL层提供的平台相关的硬件抽象，并将它们表现为可跨平台使用的独立接口。这些独立接口提供了与平台无关的硬件抽象，从而隐藏了硬件之间的差异，简化了应用软件的开发。 HIL组件的复杂性主要取决于被抽象化的硬件相对于平台无关接口的性能水平。 当硬件的功能超过了当前的API接口，HIL层只需把HAL层的抽象“降级”，直到HIL层在选择的接口上能平稳运行； 当底层硬件的功能比较有限时，HIL层就需要通过软件模拟出缺少的硬件性能。 不同层次抽象的结合 为应用程序提供两种不同的抽象 横向分解 促进不同平台上硬件抽象资源的重利用 采用较少通用化的方法,提供一些主要总线协议的硬件抽象 跨平台资源共享,导致总线资源的竞争冲突 引入资源仲裁机制 微处理器抽象 硬件抽象框架还不能提取出不同微处理器的特点 HIL抽象级别 强HIL 弱HIL 硬件接口无关 实用组件 2、任务和调度 任务是TinyOS系统提供的一种特殊的机制，类同于线程。 任务是一个函数，组件告诉TinyOS稍后再运行而不是立即运行。 任务之间的运行是原子性（就像原子一样是不可分割的基本微粒，不可被中断的）。 TinyOS1.x的任务 TinyOS2.x的任务 基本任务模型 新的任务接口 2.1 TinyOS 1.x的任务和调度器 任务采用延时调度机制,不能互相抢占,任务之间是原子性的关系。 任务调度器是一组c函数的集合，保存在sched.c文件中，不建议使用者修改。 提交任务到任务队列可能返回失败，任务可以被多次提交。 有些组件对于提交失败没有合理的相应 由于一个任务可以多次提交，因此会出现一个任务占用多个位置的情况 所有的任务共享一个循环的任务队列，那么只要一个任务发生错误，就可能造成其他所有任务阻塞。 任务模型存在缺陷 如果一个组件出现异常，可能导致整个TinyOS系统挂起。 2.2 TinyOS 2.x的任务 基本任务 任务队列不再出现多个一样的任务 每个任务在任务队列里都有它自己预留的存储槽 任务可以多次提交，只有任务已经被提交，但还没有开始执行，再次提交会返回失败。 一个任务可以总在运行，但在队列中只占一个位置。 TinyOS2.x分配了一个字节表示任务的ID号 任务的ID越大表示越受关注。 任务接口 新的任务种类 不一直占用RAM 2.3 TinyOS 2.x的调度器 任务调度器被实现为一个TinyOS组件 负责协调不同的任务类型 调度器提供一个参数化的任务接口，每一个绑定到这个任务接口的任务都需要使用unique()函数来获得唯一的标识符，调度器就是通过这个标识符来调度任务。 调度器还必须提供参数化的TaskBasic接口。 2.4 调度器的替换 TinyOS2.x允许用户使用自己的程序取代系统调度器。 通过替换调度器，可引入超时管理 所有