深入浅出ZStack2006OSAL多任务资源分配机制.docVIP

一、概述　　OSAL (Operating System Abstraction Layer)，翻译为“操作系统抽象层”。如何理解这个复杂的名词呢？表面上看它是作为操作系统存在的，可是为什么又加上“抽象层”呢？它的本质是什么？在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则负责处理传递给此任务的事件。　　大概浏览一下GenericApp_ProcessEvent这个函数，我们可以发现，此函数的主要功能是判断由参数传递的事件类型，然后执行相应的事件处理函数。我们可以由此推断Z-Stack应用程序的运行机制如下图所示： 　　当有一个事件发生的时候，OSAL负责将此事件分配给能够处理此事件的任务，然后此任务判断事件的类型，调用相应的事件处理程序进行处理。　　明白了这个问题，新的问题又摆在了我们的面前：OSAL是如何传递事件给任务的。三、OSAL的事件传递机制　　在试图弄清楚这个问题之前，我们需要弄清楚另外一个十分基础而重要的问题。那就是如何向我们的应用程序中添加一个任务。　　我们先来看看GenericApp是如何添加任务的。　　我们打开OSAL_GenericApp.c文件。这里我们可以找到一个很重要的数组tasksArr和一个同样很重要的函数osalInitTasks。　　TaskArr这个数组里存放了所有任务的事件处理函数的地址，在这里事件处理函数就代表了任务本身，也就是说事件处理函数标识了与其对应的任务。　　osalInitTasks是OSAL的任务初始化函数，所有任务的初始化工作都在这里面完成，并且自动给每个任务分配一个ID。　　要添加新任务，我们需要编写新任务的事件处理函数和初始化函数，然后将事件处理函数的地址加入此数组。然后在osalInitTasks中调用此任务的初始化函数。在此例中，我们此前提到过的GenericApp_ProcessEvent这个函数被添加到了数组的末尾， GenericApp_Init这个函数在osalInitTasks中被调用。　　值得注意的是，TaskArr数组里各任务函数的排列顺序要与osalInitTasks函数中调用各任务初始化函数的顺序必须一直，只有这样才能够保证每个任务能够通过初始化函数接收到正确的任务ID。　　另外，为了保存任务初始化函数所接收的任务ID，我们需要给每一个任务定义一个全局变量来保存这个ID。在GenericApp中Gene