|
经验表明，C语言的可移植性、开发速度及内置的运行时间支持(C标准库)等优势远比使用该语言成本较低的特点更重要。Java语言自出现以来也是如此。事实上，采用Java编写的系统级软件具有更好的成本－效益比，这使得Java成为目前和将来嵌入式设计的首选语言之一。
确切地说，什么是系统级编程呢？对大多数开发者来说，是指在系统的最底层进行编程，直接与硬件对话并控制硬件。设备驱动程序是系统级编程的一个典型例子。它们一般与操作系统(OS)和硬件直接相连，以便让设备以某种标准方式存取应用级程序。应注意的是，有些类型的设备驱动程序不能用Java编写。例如，在很多OS中，驱动程序要么作为共享目标被装载，要么与内核本身静态链接。对于这种OS，不能用Java编写设备驱动程序，因为Java虚拟机(JVM)是在内核外运行的。
很多驱动程序都是由三部分组成：硬件初始化、中断处理和客户端接口。在详细探讨这三个组成部分之前，先介绍一些关键的Java概念，特别是Java本地接口(JNI)。
Java标准库提供了很多函数。然而，它并不总能提供直接与底层系统接口所需的特性。输入JNI，就可以安全且轻便地从共享库中调用本地函数。这些函数可以与类交互，剔除异常(exception)，就跟其它Java函数一样运行(从调用该本地函数的Java程序的角度来看)。
这种方法有一个缺点：每次使用一个本地方法，若转向一个新的系统必须移植这种方法。一个好的设计将用纯粹的Java来完成逻辑及高级任务，而尽可能精简JNI代码。这样可以充分复用项目间的本地函数。
中断处理
存储器存取的接口比较简单，相比之下，中断处理则复杂得多。对于起步者，有些OS甚至不让他们访问中断。针对嵌入式和实时市场的OS要么在应用和内核空间之间不做任何区分，要么提供一个合适的API来处理用户空间中断(如QNX的Neutrino RTOS)。
即便操作系统提供了一个可通过JNI访问的API，开发者仍需要解决JVM内的时序问题。如果JVM符合Java实时规范(RTSJ)，所生成的实时线程不会被JVM垃圾收集器所阻碍。然而，如果没有这些实时线程，由Java控制的任何中断都要受垃圾收集器支配，不得不忍受数毫秒至数秒的延迟。如果这种延迟无法令人接受，那么必须采取基于JNI的解决方案。
假如纯Java方案是可行的，就可以创建一个JNI容器类进行中断管理。利用这种类就可启动一个附着于所需中断的高优先级线程，然后揭开该中断，并等待处理循环中的中断。之后，该线程就可读或写每个中断上的硬件，并可以利用一个安全线程数据结构向系统内的低优先级线程发布任何数据。
对于有些系统，这种纯Java方案可能无法提供所期望的性能和延迟。如果是这样，就必须采用本地中断处理机。在RTOS.InterruptAttach()调用期间，相关的JNI代码将创建一个线程或注册一个处理机函数，然后将指针返回到堆积分配的ID数据结构。该代码不调用RTOS.InterruptWait()，而是调用RTOS.InterruptPopData()和RTOS.InterruptPushData()。当中断开始时，本地线程可以从FIFO类型结构中读取及写入，为任何等待数据“弹出”的Java线程扫除障碍(如图1所示)。 （图片）
图1：有时，纯Java方案无法提供所期望的性能和延迟。如果是这样，就必须采用本地中断
处理机。当中断开始时，本地中断处理机可以从FIFO类结构中读取及写入，为任何等待数据“弹出”的Java线程扫除障碍。 客户端接口
如果设备驱动程序所处理的数据只能由它本身访问，那么该驱动程序没有太大用途。驱动程序需要与系统的其它部分相互通信。在Unix等传统操作系统上，一个客户端程序可以通过打开一个设备的文件描述符来访问该设备，一般是通过调用open()。如果该过程随后绕过该描述符而执行一个系统调用，内核就将该调用路由到适当的设备。显然，这种方法不适用于Java编写的驱动程序。在一个良好的系统内，任何用户应用程序都可能注册一个设备并处理打开/读取/写入操作。尽管如此，这种方法并不总是容易移植。这迫使我们寻求两种可能的路径，即与客户端－套接及内部JVM对话。
有些设备更加适合于采用Java的系统级工作。前端面板系统就是理想的候选对象。还可以利用Java广泛的内置GUI API来设置一个仿真环境，以便在一个带有按钮小部件的窗口内运行被仿真的帧缓冲。在这种环境下，设计者可以在硬件到达之前设计、构建及调试应用程序驱动接口。
其它候选对象包括任何低中断率、支持DMA的设备。这种设备在中断之间有足够的缓冲，从而可缓解JVM中的延迟问题。Java驱动程序不太适用的对象包括硬件缓冲器小且要求低延迟的高中断率设备。
作者：Chris McKillop
软件工程师
Email：cdm@qnx.com
QNX软件系统公司
6/20/2005
|
