OSAL的思想起源

1. OSAL的思想起源

本部分拟通过研究相关文献总结出OSAL (Operating System Abstraction Layer) 的产生原因以及思想起源。

1.1 早期WSN的架构

在早期WSN的软件架构中,开发环境是极其轻量的 (Lightweight),开发者直接操控硬件进行开发,如图1 所示:

硬件(Hardware)
应用端 (Application)
图 1 早期无线传感器网络的架构


在这种软件架构下,存在以下四种限制:

  • 与硬件依赖 (Hardware dependent)的应用端程序

    开发者直接面向硬件底层,应用端程序的代码与低级硬件细节相耦合。例如,操纵硬件寄存器来进行网络控制。在这种情况下,当硬件提供的接口发生了变化将会影响开发者专注于应用端程序的开发,强迫开发者深入硬件细节。

  • 没有分离开的独立进程 (Independent process)

    在这种架构下,只存在一个进程。这样就迫使开发者组合不同应用程序代码,这样就导致组合出来的程序在数据请求数据处理时间同步会相互关联,使得程序可读性变差,难以调试。

  • 无法对时间进行控制

    由于在一个程序里组合了不同的应用代码,使得对于时间进行精确的掌控变得尤为困难。只要改变了一部分涉及到延迟的代码,整个系统的时间将会发生变化。

  • 无处理器分配机制

    程序始终顺序执行不同的应用代码,处理器无法获得任何优先权。

由图2 可知,随着发展,WSN的架构在硬件上为开发者提供了一些十分重要的抽象:

应用端(Application)
操作系统API
中断服务程序 (ISR)
硬件表示层 (HPL)
基本函数层(Basic function)
硬件(Hardware)
图 2 后期的无线传感器网络架构

  • 基本函数 (Basic function) 层

    是一个功能十分简单的层,提供以下基础功能:

    • 对寄存器进行读、写功能
    • 产生硬件中断,将中断信息传递给上层
  • 中断服务程序 (Interrupt Service Routines ISR) 层

    用于处理中断,并且能够对信号量 (semaphore) 进行管理,对硬件进行基本的处理。

  • 硬件表示层 (HPL)

    提供一个完整的接口用于硬件和应用之间的交互。

我们下面介绍操作系统的使用,WSN社区广泛使用了一系列操作系统 (OS, Operating System),尽管这些不同的操作系统几乎都提供具有相同功能的服务,但是它们使用了不同的应用编程接口 (API, Application Programming Interface),从而使可移植性 (Portability) 变得更加困难,对于不同平台,提供的API 不相同,导致代码的兼容性较差。

1.2 OSAL的提出

通过上述分析可知,对于不同的硬件平台以及操作系统提供的不同API 都会导致软件的可移植性变差。因此,人们提出了一个新的想法:在操作系统API与应用端之间的交互上,再提供一层抽象,这个抽象就是OSAL,如图3 所示:

应用端(Application)
OSAL(操作系统抽象层)
操作系统API
图 3 集成OSAL的WSN架构


OSAL 为应用端提供了对操作系统API的一个抽象,就是为了解决不同操作系统提供功能相同的服务但却不具备相同API的问题。这样当软件代码要移植到不同的操作系统时,仅仅只需要重新定义OSAL的相关功能,但并不改变OSAL为用户提供的接口,也就是OSAL API。

1.3 小结

通过上述分析可知,我们可以得出以下结论:

  • OSAL 的产生的根本目的是为了提高代码的可移植性
  • OSAL 在严格意义上并不是操作系统,只是对于不同操作系统的API 进行了一层抽象,统一了用户接口

你可能感兴趣的:(Z-Stack,OSAL分析)