zigbee深入浅出.docx

深入浅出Z-Stack 2006 OSAL多任务资源分配机制
一概述
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--\Projects\zstack\Samples\GenericApp。
首先我们去繁就简,先来了解应用程序的运行方式。
在右侧工作空间窗口打开App文件夹,我们可以看到三个文件,分别是“”、“”、“”。我们整个程序所实现的功能都在这三个文件当中。。我们首先看到的是比较重要的两个函数:GenericApp_Init和GenericApp_ProcessEvent。从函数名称上我们很容易得到的信息便是,GenericApp_Init是任务的初始化函数,而GenericApp_ProcessEvent则负责处理传递给此任务的事件。
大概浏览一下GenericApp_ProcessEvent这个函数,我们可以发现,此函数的主要功能是判断由参数传递的事件类型,然后执行相应的事件处理函数。我们可以由此推断Z-Stack应用程序的运行机制如下图所示:
当有一个事件发生的时候,OSAL负责将此事件分配给能够处理此事件的任务,然后此任务判断事件的类型,调用相应的事件处理程序进行处理。
明白了这个问题,新的问题又摆在了我们的面前:OSAL是如何传递事件给任务的。
三、OSAL的事件传递机制
在试图弄