Q: 我为OpenWSN开发了一个模块，如何决定这个模块归入的层次？

此问题即代码分配原则，这对于今后维护，不把整个architecture弄乱是很重要的．

为了回答这个问题，我们需要clarify每个层次的作用以及我们架构设计时的考虑．本answer可以看作是架构设计的进一步详细补充说明：

名称	说明	代码分配原则 依据该原则决定所写代码在何层
BOOT	启动/引导层 专用于初始化芯片和引导整个系统，例如初始化存储器映射、芯片内部连接、中断等。如果系统中引入了RTOS，则BOOT还要负责启动RTOS。一部分HAL代码的正常工作也需要依赖BOOT	BOOT应只包含MCU芯片的初始化代码，而与目标板(Target Evaluation Board)无关，因此，一切与板子设计有关的代码都不应该归入BOOT层。
RTOS	RTOS层 提供一个实时调度内核。备选的RTOS有：eCos, FreeRTOS, uCOS-II, Linux 2.6 Embedded(准实时)，MANTIS, 和TinyOS(非实时)。	事实上，我们只是需要一个小的实时调度器，完全有能力自己开发一个或者移植一个。如果系统资源允许，我们可以引入更多的OS功能，如线程通信和同步、内存管理、调试和控制台等。
HAL	硬件抽象层 硬件抽象层(hardware abstraction layer)。为了最大限度保证上层代码的可移植性，提供HAL层。	可以认为，HAL层是各种硬件对象的软件代理。为了减小移植工作量，HAL中代码应尽可能精简。HAL中的代码是不允许使用RTOS功能的。
DRIVER	驱动程序层 在比HAL更高层次上提供对硬件功能的封装，比HAL更强调对上层的服务功能。DRIVER层次开发可以使用RTOS提供的调度、通信等功能。原则上，DRIVER中应该尽可能不出现强硬件依赖性代码，尽可能将此类代码放入HAL，但出于开发的便利性不对此做严格限制。	凡与硬件相关且不适合放在HAL中的代码都应该放在该层。如果该DRIVER的开发需要利用RTOS的功能，则只能归入DRIVER层。出于开发的方便，一部分没有必要利用RTOS功能的HAL层代码也直接做成了DRIVER，例如Uart, Transceiver, SPI，I2C等。
SERIVICE	服务层 从面向对象的角度看，一个系统，可以认为是由很多对象组成的，而系统的运行，就可以认为这些对象的动态交互行为。因此，我们需要重点设计和开发好各个对象。这也有助于提高软件代码的可重用性。可独立运行的进程/线程也可以认为是具有自治能力的对象。为了避免class/object名词的混淆，我们用service术语来表示对象，因为每个对象必然是要为其它对象服务的。每个service在设计的时候要牢记Hollywood原则：不要调用我，而要让我来调用你。	是系统的主要组成部分，包含了一个应用系统的绝大部分代码。
APPLICATION	应用层 设置各对象之间的连接方式，提供各对象之间的配置和粘合代码。	在一个完整的系统中，应尽可能将大部分代码对象化并归入SERVICE层，APPLICATION应尽可能保持精简。 主要的业务逻辑代码一定要放在SERVICE或DRIVER中，不允许放在APPLICATION层。

.