横向分解：提高硬件抽象资源再利用率

硬件抽象架构除了有纵向的分解之外还有横向的分解。横向分解可以使得不同平台上硬件抽象资源重新利用率更高。因此，TinyOS 2.0引入了芯片的概念，即为给定芯片设计独立的完整的硬件资源，如微控制器芯片、射频芯片以及闪存芯片等。每个芯片都可以遵循硬件抽象架构的模型进行分解，提供HIL的实现部分作为顶层组件。然后，一个平台由各种芯片组件组合在一起。如图5-3所示，CC2420软件依赖于专用的物理定时器，micaz平台代码就将其映射到Atmega128微控制器的定时器上。

图5-2 通过HIL和HAL并行访问MSP430的ADC硬件抽象

图5-3 micaz平台把CC2420所需的定时功能连接到Atmega128定时器(www.xing528.com)

一些共用的硬件模块是通过标准的总线接口连接到微控制器的，如SPI总线、I2C总线以及UART接口等。为了实现硬件驱动的平台兼容性，就需要实现这些互连总线的硬件抽象。显然，类似NetBSD（http：//www.netbsd.org）的通用总线抽象可以最大程度实现这些硬件驱动的可移植性和再利用性。这种模型是从不同的总线协议中提取出一种通用的总线接入方案。以这种方式，把芯片抽象和互连抽象分离开来，这样就可以在一定程度上实现“同一芯片抽象以不同的连接协议引入不同的平台”。然而，这种通用化的实现方式会导致较高的性能开销。这样的做法对于桌面操作系统能够接受，但对于根据特定应用设计的传感器网络平台来说，这种实现方式绝不是最理想的。

TinyOS 2.0采用较少的通用化方法，提供了一些主要的总线协议的硬件抽象，如I2C、SPI、UART以及I/O引脚。例如，SPI总线抽象不必了解用户的地址，而I2C总线抽象就需要知道占有I2C总线的用户的地址。此外，还可以把这些互连抽象直接接入特定芯片的HAL组件，根据芯片的配置选项作细微调整，从而进一步提高性能。

TinyOS 2.0的总线抽象是与底层I/O引脚和引脚中断的抽象相结合的，这样就提高了芯片的硬件抽象在支持该总线协议的平台上的重新利用率。例如，CC2420射频芯片可以同时在Telos平台和MicaZ平台上使用，这是因为MSP430和Atmega128微控芯片的串行模块的硬件抽象都可以支持标准的SPI总线抽象，而CC2420芯片使用的就是SPI总线。

跨平台的芯片共享也会带来一些问题。当多个芯片设备连接到总线上时，就会导致总线资源的竞争冲突。例如，MicaZ平台上的CC2420芯片连接到专用的SPI总线，而Telos平台上的一条SPI总线被CC2420芯片和闪存芯片共用。为了化解冲突，就需要引入资源仲裁机制；总线上的每个芯片抽象为了获得总线资源，都必须使用Resource接口。无论是专用总线，还是多个芯片共用的总线，只要基于这种资源仲裁机制，就都可以安全访问芯片。