vxWorks RTP功能应用案例

WindRiver提出RTP这个功能，想必也是从Linux中汲取了精华。次功能从vxWorks6.0出现，可以兼顾内核保护性和实时性。对于从5.5一路走来的研发人员来说，如何使用该功能，又多了份新的研究方向。且看WindRiver给出的RTPdemo，看它如何展现它新的特征，对大家的工作有何帮助。

从Memory Space角度讲，RTP彼此独立，同时也与kernel独立。虽然可以disable MMU，使之在Flat memory mode下访问其它模块，但这违背了RTP设计的初衷，会使程序变得畸形。

从sheduling角度说，为了在RTP中调度thread，WR引入的POSIX  and VxWorks Scheduler.该Scheduler在内核态下，功能与traditional的Scheduler一致。仅存少许差异。

In all other cases, the POSIX thread scheduler schedules pthreads and tasks in the same (non-POSIX) manner as the traditional VxWorks scheduler. (There is a minor difference between how it handles tasks and pthreads whose priorities have been lowered; seeDifferences in Re-Queuing Pthreads and Tasks With Lowered Priorities.)

 

PS.

3.2  Comparing Kernel Applications with RTP Applications

The primary difference between kernel applications and RTP applications is that RTP applications execute in separate, protected memory environments, while kernel applications do not. There are also differences in the features available in each environment, as well as differences in performance, footprint, and memory use.

 

VxWorks kernel applications execute in kernel mode in the kernel memory space. They can be linked with the kernel or downloaded into it at runtime (as downloadable kernel modules--DKMs). Because kernel applications execute in the kernel, the system cannot protect the kernel from misbehavior on the part of applications, nor applications from one another. At runtime, VxWorks system tasks (such astExcTask) and application tasks are distinguished only by their priority and the functionality of their code.

 

RTP applications execute as real-time processes in user mode, each in a their own protected memory space, which is separate from that of other RTP applications and from the kernel. RTP applications should be used when this protection is a key consideration for the system. RTP applications are built and stored separately from the kernel (on the host during development and on the target for deployed systems). VxWorks RTP applications are similar to applications for other operating systems such as UNIX and Linux, except that VxWorks real-time processes are designed for real-time systems (for more information in this regard, see the2. Real-Time Processes: RTPs).

 

The kernel application environment and the RTP application environment have many of the same features, but also differ in what is available in each. For example, drivers can only be installed in the kernel, and PSE52 conformance can only be achieved in the RTP environment.

 

While there is no inherent difference in the speed of code executing in the kernel environment or the RTP environment, it can be affected by code optimization (although less so in the RTP environment) and the use of system calls (which are specific to the RTP environment). RTP applications that make notable use of system calls--which is generally the case--are slower than comparable kernel applications. In addition, VSB projects can be used to remove RTP-handling code from various VxWorks libraries (using theReal-Time Process option), which improves the performance of those libraries and reduces their size (for information in this regard, see theVxWorks Kernel Programmer's Guide.)

 

In addition, a VxWorks image configured with RTP support components will be slightly larger than one that is not. And the overall memory requirements for a system that employs RTP applications is generally larger than one that uses comparable kernel applications because RTP applications include user-side libraries (which "duplicate" those already included in the kernel).

 

A.2.4  Eliminating Hardware Access

Process code executes in user mode. Any supervisor-level access attempt is illegal, and is trapped. Access to hardware devices usually falls into this category. The following are prohibited:•Do not access devices directly from user mode even if the device is accessible. (Access to devices is sometimes possible depending on the memory map and the mappings for the address area for the device.) Instead of direct access, use the standard I/O library APIs:open( ), close( ), read( ), and so forth. An appropriate user-mode alternative is to access a memory-mapped device directly by creating a shared-data region that maps the physical location of the device into the process memory space. A private shared-data region can be created if access to the device must be limited to a single process. For more information, see theVxWorks Application Programmer's Guide: Shared Data.•Do not use processor-specific features and instructions in application code. This hampers portability.Note that interrupts cannot be locked from a process (theintLock( ) routine ins not available).