21、TinyOS设备驱动与硬件抽象架构解析

TinyOS设备驱动与硬件抽象架构解析

设备驱动的访问控制

在程序运行中，当多个部分试图访问同一设备时，设备驱动需要进行访问控制以避免出现问题。例如，ATmega128 A/D转换器一次只能采样一个通道，若程序中无线电需要检查天线信号强度，而用户代码需要采样当前温度，就需要进行协调，防止两者的请求相互干扰。

TinyOS 1.x主要依靠检测冲突和程序员的自律来处理访问控制问题。例如，执行A/D转换的请求若遇到程序其他部分正在使用A/D转换器，会返回错误：

/* Let ’s read temperature ! */ if ( call ADC.getData() == FAIL ) /* oops , we need to try again */ post tryAgain();

但在实际应用中，这种方法并不理想。程序员可能会忽略错误检查，或者无法找到合适的错误恢复策略。而且，这些错误路径出现的概率较低，所以测试不够充分。最终导致代码复杂，难以编写、理解和维护。系统的演变会使情况更加复杂，例如用户代码在不检查错误代码的情况下采样温度，在使用不采样信号强度的无线电堆栈时可能正常工作，但一旦更换为采样信号强度的无线电堆栈，应用程序代码可能会突然失效。

TinyOS 2采用了更为系统的访问控制方法，所有设备驱动组件可分为以下三种访问控制类别：
-专用（Dedicated）：专用驱动只有一个用户，该用户对设备拥有完全控制权，大多数HPL组件都属于此类。
-虚拟化（Virtualized）