| Insight into Venturcom's real-time Windows extensions |
(Feb 7, 2003)
Here's the first in our series of exclusive articles submitted by Microsoft on the theme of software reliability. This piece, a Q&A between Microsoft and Venturcom's John O' Keefe, provides technical insight into the latter company's real-time extensions to Windows XP embedded. We hope you find it useful; let us know what you think in our talkback section. We'll be bringing you more material in the days and weeks ahead.
Microsoft: What specific features of Real-Time extensions (RTX) are designed for reliability of an embedded system?
Venturcom: Venturcom's RTX includes a real-time enabled hardware abstraction layer (HAL) extension. This extension maintains interrupt isolation between the RTX real-time subsystem (RTSS) and Windows. Windows cannot mask interrupts managed by RTSS at the interrupt controller level. Windows interrupts are masked during RTSS processing. The real-time HAL extension supports high-resolution clocks and timers for RTSS, while it also supports non-real-time clocks and timers for Windows. Other real-time HAL extension features include: a software interrupt mechanism between RTSS and Windows, basic exception management, and various enhancements for determinism.
The RTX RTSS is conceptually similar to other Windows subsystems (such as Win32, POSIX, WOW, and DOS) in that it supports its own execution environment and application programming interface (API). RTSS differs in one important area. Instead of using the Windows scheduler, RTSS performs its own real-time thread scheduling.
RTX supports both uniprocessor and multiprocessor-based computer systems running Windows. In a uniprocessor environment, all RTSS thread scheduling, including Windows-managed interrupts and Deferred Procedure Calls (DPCs), occurs ahead of all Windows scheduling. The multiprocessor system run-time version of RTX provides all of the features of the uniprocessor version, and it exploits the features of Intel MPS-compliant multiprocessor systems to provide improved performance in both Windows and RTX environments. Multiprocessor system RTX runtimes implement a dedicated processor model. In this model, RTSS runs on one processor, while the remaining processors continue to run on Windows. The multiprocessor RTX HAL extension acquires control of the last logical processor during the Windows boot sequence and this processor is reserved for RTSS use. RTSS programs can then be loaded and executed on the dedicated processor.
Therefore, in a quad processor system, RTX can be configured so that Microsoft Windows 2000 Server runs on processors one, two, and three and RTX runs on processor four. If you look at the systems resources available for Windows, you find that Windows reports that three processors are available.
Of course, if you attempt to use Microsoft Windows XP Professional or Windows XP Embedded on the same computer, you have XP running on processors one and two and RTX running on processor four. Processor three would be unused because Windows XP Professional is designed to use a maximum of two processors and RTX will load on the last physical processor.
The RTX API for Win32 and RTSS processes, including those for floating-point unit (FPU) and structured exception handling, are used for both uniprocessor and multiprocessor systems. This eliminates the need to recode RTX (uniprocessor) applications for a multiprocessor platform. RTSS supports Interprocess Communication (IPC) objects that can be manipulated by either RTSS or Win32 processes, which enables simple and standard communication and synchronization between real-time and non-real-time programs. Finally, RTSS provides other time critical services -- such as clocks and timers and interrupt management -- which are available for use by RTSS processes.
Microsoft: How does RTX affect the overall reliability of an embedded system based on Windows XP Embedded?
Venturcom: RTX addresses a number of different aspects that contribute to the overall reliability and performance of a Window XP Embedded system. These include:- RTX manages interrupt latencies that eliminate PIC-level interrupt disabling by isolating interrupts through the RTX HAL extension. Windows and its drivers cannot disable RTSS interrupts. In addition, all Windows interrupts are masked when RTSS is running.
- RTX power management ensures that, if there are RTSS processes running on a system, system power state transitions from working state (S0) to any sleeping state (S1-S5) are blocked. If there are no RTSS processes running on the system, system power state transitions from working state to any sleeping state are not blocked. This ensures that critical processes are not inadvertently interrupted by a Windows application that attempts to change system power state.
- System memory locking is provided to prevent page faults and unpredictable delays in critical sections of code. Real-time applications need to lock data and code in memory. The items that need to be locked into memory include the code and data contained and used by the operating system itself. All process and memory objects in the RTSS environment are locked into physical memory to avoid page faults in RTSS processes by default. RTX provides Rt*Lock API functions to support locking process, heap, and stack. The Rt*Lock APIs include:
- RtLockProcess, which locks all pageable sections of a process into physical memory.
- RtUnlockProcess, which unlocks sections of a process's virtual address space previously locked into physical memory.
- RtCommitLockProcessHeap, which commits and locks the process's heap.
- RtCommitLockHeap, which commits and locks the specified heap.
- RtCommitLockStack, which commits and locks the specified stack.
- RtLockKernel, which locks pageable sections of the Windows kernel into physical memory.
- RtUnlockKernel, which unlocks sections of the Windows kernel previously locked into physical memory.
Microsoft: Can RTX detect abnormal operating system situations and rectify them through operating system restart? If so, which situations can be detected and dealt with?
Venturcom: Watchdog applications can be programmed using RTX applications to check on the "health" of Windows. They can be designed to execute a number of actions if Windows is found to be in an undesirable state. These actions can include executing RTX Shutdown Handlers to transmit the last state of the Windows operating system and other programs to a remote computer using RTX 5.5's integrated real-time networking component, systematically exiting running RTSS processes, forcing a system power reset, and restoring a computer to the last saved stable state. The code to implement this type of system watchdog application, to remotely monitor and perform system recovery in case of a Windows failure, is provided as sample application source code in the RTX version 5.5 Software Development Kit (SDK). Using RTX, RTX's integrated real-time networking component, and RTX's micro-web server, it is easy to create an Windows embedded device that can be remotely monitored. It is also easy to reset or recover the system if there is a Windows failure.
Microsoft: If an application running on Windows XP Embedded fails, can RTX continue running? If so, briefly describe the how it does so.
Venturcom: Stop messages in Windows XP are the result of sanity checks that fail and call KeBugCheck to bring Windows to a controlled stop. This bug check minimizes data corruption and helps find out what went wrong with the system. This type of Windows stop is frequently referred to a as a general protection fault (GPF).
Unless there has been a complete hardware failure, such as the CPU failing or power loss, RTX will continue to run even after KeBugCheck brings Windows to a controlled stop. All RTSS processes, that are not dependent upon Windows supplied services, continue to perform real-time tasks. Since services and components provided by Windows are no longer available, the RTSS processes cannot make calls to Windows or request Windows service. RTX threads, processes, and applications that do not make calls to Windows processes or services can continue to run even after a Windows XP Embedded general protection fault.
The RTX SDK documentation provides a matrix of real-time functions that identifies those RTX API (RTAPI) functions which are deterministic and will survive a Windows XP Embedded GPF failure. The current RTX SDK documentation can be downloaded from Venturcom.
Microsoft: Can you provide examples of devices that use RTX for its reliability features rather than real-time control features?
Venturcom: RTX is used in mail sorting machines and numerous industrial automation applications, such as robotic controllers, because RTSS applications can survive a Windows failure or stoppage, detect the Windows failure, and then execute a procedure to complete an in-process operation, followed by a safe, controlled system shutdown procedure.
Microsoft: Do you have any reliability hints and tips you would like to share?
Venturcom: First, you should fully understand the desired use and function of the device you are building with Windows XP Embedded. Then, include only those components need to support those uses and functions. Attempting to recreate all of the general purpose desktop functionality of Windows XP Professional in an embedded device using Windows XP Embedded introduces the probability that it will be used in an unforeseen manner, compromising the initial design criteria, and affecting device reliability.
Microsoft: How can customers learn more about your product?
Venturcom: Full 30-day trail versions of the RTX SDK and the RTX Windows XP Embedded .sld file are available from the Venturcom site. The RTX documentation is available on the Venturecom site. Venturcom also offers training courses in the development of Windows XP Embedded and RTX systems.
Please note that these papers are contributed by a variety of authors as a convenience for personal informational purposes only and are provided "as is". Microsoft and/or its respective suppliers make no representations about the suitability or accuracy of the information contained in these documents. The information contained in these documents should not be interpreted to be a contractual commitment on the part of Microsoft or its suppliers.
Copyright (c) 2003 Microsoft Corporation. All rights reserved. Reproduced by WindowsForDevices.com under license.
Talk back! Do you have comments or questions about this story? talkback here
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
Use of this site is governed by our Terms of
Service and Privacy Policy.
Except where otherwise specified, the contents of this site are copyright © 1999-2008
Ziff Davis Enterprise Holdings Inc. All Rights Reserved.
Reproduction in whole or in part in any form or medium without express written permission of Ziff Davis Enterprise is
prohibited. Windows is a trademark or registered trademark of Microsoft Corporation in the United States and/or other countries and is used by WindowsForDevices under license from owner. All other marks are the property of their respective owners. WindowsForDevices is an independent publication not affiliated with Microsoft Corporation.
news feed