+<h1><a id="horizontal-decomposition" name="horizontal-decomposition">4. Horizontal decomposition</a></h1>
+<p>In addition to the <em>vertical</em> decomposition of the HAA, a <em>horizontal</em>
+decomposition can promote reuse of the hardware resource abstractions
+that are common on different platforms. To this aim, TinyOS 2.0
+introduces the concept of <em>chips</em>, the self-contained abstraction of a
+given hardware chip: microcontroller, radio-chip, flash-chip, etc.
+Each chip decomposition follows the HAA model, providing HIL
+implementation(s) as the topmost component(s). Platforms are then
+built as compositions of different chip components with the help of
+"glue" components that perform the mapping (<a class="reference" href="#fig-3">Fig.3</a>)</p>
+<pre class="literal-block" id="fig-3">
+ +----------------------------------------------------+
+ | AppM |
+ | /Application Component/ |
+ +------+--------------------------------------+------+
+ | |
+ |Millisecond Timer | Communication
+ +------+------+ +---------+------+
+ | TimerMilliC | | ActiveMessageC |
+ | | | |
+ | /Platform | | /Platform |
+ | Component/ | | Component/ |
+ +------+------+ +---------+------+
+ | |
+ +------+------+ +------+------+
+ | | 32kHz Timer | |
+ | | +--------------+ | |
+ | Atmega128 | | CC2420AlarmC | | CC2420 |
+ | +----+ +----+ |
+ | Timer Stack | | /Platform | | Radio Stack |
+ | | | Component/ | | |
+ | /Chip | +--------------+ | /Chip |
+ | Component/ | | Component/ |
+ +-------------+ +-------------+
+
+
+
+Fig.3: The CC2420 software depends on a physical and dedicated
+timer. The micaZ platform code maps this to a specific Atmega128
+timer.
+</pre>
+<p>Some of the shared hardware modules are connected to the
+microcontroller using one of the standard bus interfaces: SPI, I2C,
+UART. To share hardware drivers across different platforms the issue
+of the abstraction of the interconnect has to be solved. Clearly,
+greatest portability and reuse would be achieved using a generic bus
+abstraction like in NetBSD <a class="citation-reference" href="#netbsd" id="id10" name="id10">[netBSD]</a>. This model abstracts the
+different bus protocols under one generic bus access scheme. In this
+way, it separates the abstraction of the chip from the abstraction of
+the interconnect, potentially allowing the same chip abstraction to be
+used with different connection protocols on different platforms.
+However, this generalization comes at high costs in performance. This
+may be affordable for desktop operating systems, but is highly
+sub-optimal for the application specific sensor network platforms.</p>
+<p>TinyOS 2.0 takes a less generic approach, providing HIL level,
+microcontroller-independent abstractions of the main bus protocols
+like I2C, SPI, UART and pin-I/O. This distinction enables
+protocol-specific optimizations, for example, the SPI abstraction does
+not have to deal with client addresses, where the I2C abstraction
+does. Furthermore, the programmer can choose to tap directly into the
+chip-specific HAL-level component, which could further improve the
+performance by allowing fine tuning using chip-specific configuration
+options.</p>
+<p>The TinyOS 2.0 bus abstractions, combined with the ones for low-level
+pin-I/O and pin-interrupts (see <a class="citation-reference" href="#tep117" id="id11" name="id11">[TEP117]</a>), enable a given chip
+abstraction to be reused on any platform that supports the required
+bus protocol. The CC2420 radio, for example, can be used both on the
+Telos and on micaZ platforms, because the abstractions of the serial
+modules on the MSP430 and Atmega128 microcontrollers support the
+unified SPI bus abstraction, which is used by the same CC2420 radio
+stack implementation.</p>
+<p>Sharing chips across platforms raises the issue of resource contention
+on the bus when multiple chips are connected to it. For example, on
+the micaZ the CC2420 is connected to a dedicated SPI bus, while on the
+Telos platform one SPI bus is shared between the CC2420 radio and the
+flash chip. To dissolve conflicts the resource reservation mechanism
+proposed in [<a class="reference" href="#tep108">TEP108</a>] is applied: every chip abstraction that uses a
+bus protocol MUST use the <tt class="docutils literal"><span class="pre">Resource</span></tt> interface in order to gain
+access to the bus resource. In this way, the chip can be safely used
+both in dedicated scenarios, as well as in situations where multiple
+chips are connected to the same physical bus interconnect.</p>
+</div>