深入浅出Z-Stack 2006 OSAL 多任务资源分配机制 一 概述 OSAL (Operating Sy stem Abstraction Lay er)，翻译为“操作系统抽象层”。如何理解这个复杂的名词呢？表面上看它是作为操作系统存在的，可是为什么又加上“抽象层”呢？它的本质是什么？在 Z-Stack 协议栈中，它又扮演了什么角色呢？要解答这些问题，我们必须先从宏观入手，渐渐深入探究，最后答案自然会浮出水面。 下图是 ZigBee 协议的结构图： 从这幅图中，我们可以很清楚地从宏观上了解 ZigBee 协议的结构。可是，经过粗略的浏览，我们并没有发现任何 OSAL 的踪迹。当然，我们都知道，Z-Stack 与 ZigBee 之间并不能完全划等号。Z-Stack 是 ZigBee 的具体实现，所以存在于 Z-Stack 中的 OSAL 并不一定出现在ZigBee 中。但是，我们可以在 ZigBee 中找到些许 OSAL 的踪影。 在 ZigBee 协议中，协议本身已经定义了大部分内容。在基于 ZigBee 协议的应用开发中，用户只需要实现应用程序框架即可。从上图可以看出应用程序框架中包含了最多240 个应用程序对象。如果我们把一个应用程序对象看做为一个任务的话，那么应用程序框架将包含一个支持多任务的资源分配机制。于是OSAL 便有了存在的必要性，它正是Z-Stack 为了实现这样一个机制而存在的。 OSAL 就是以实现多任务为核心的系统资源管理机制。所以OSAL 与标准的操作系统还是有很大的区别的。简单而言，OSAL 实现了类似操作系统的某些功能，但并不能称之为真正意义上的操作系统。 二、OSAL 任务运行方式 弄明白了OSAL 是何方神圣，接下来我们将深入 Z-Stack，进一步研究 OSAL。 为了方便，我们使用 Z-Stack 所提供的GenericApp 这个例程为例来进行分析。此例程的默认路径为 C:\Texas Instruments\ZStack-1.4.3-1.2.1\Projects\zstack\Samples\GenericApp。 首先我们去繁就简，先来了解应用程序的运行方式。 在右侧工作空间窗口打开 App 文件夹，我们可以看到三个文件，分别是“GenericApp.c”、“GenericApp.h”、“OSAL_GenericApp.c” 。我们整个程序所实现的功能都在这三个文件当中。 首先打开 GenericApp.c 这个文件。我们首先看到的是比较重要的两个函数：GenericApp_Init 和 GenericApp_ProcessEvent。从函数名称上我们很容易得到的信息便是，GenericApp_Init 是任务的初始化函数，而GenericApp_ProcessEvent 则负责处理传递给此任务的事件。 大概浏览一...
