|
Understanding INtime software architecture |
Contents
How do INtime software and Windows NT work together?
About the modified Windows HAL
How INtime software and Windows NT work together to run RT applications
How the RT interface driver works
When an INtime application runs on an INtime node, Windows NT threads communicate with RT threads via the Windows NT extension (NTX) library as shown in this figure:
The INtime components include:
1RT kernel: Provides deterministic scheduling and execution of RT threads within RT processes. For detailed information about the kernel, see About INtime software’s RT kernel.
2Real-time application, C, and EC++ libraries: Gives direct access to the RT kernel services for RT threads. For an overview of calls in these libraries, see Appendix A, “INtime software system calls” in the ”INtime software overview guide”. For detailed information, including syntax and parameter values, see high level, low level, C calls, and EC++ calls.
3NTX library: Provides RT extensions for the Win32 API that allow Windows NT threads to communicate and exchange data with RT threads within the application. For an overview of calls in this library, see Appendix A, “INtime software system calls” in the INtime software overview guide. For detailed information, including syntax and parameter values, see NTX calls.
4Transport driver: A driver that converts information to the protocol needed by the specified transport mechanism. For details, see Transport mechanisms.
5Transport mechanism: The communication protocol or method used by NTX to communicate between Windows NT and RT threads. Whether the various portions of your INtime applications reside on a single PC, or on multiple computers accessed via serial or Ethernet cable, NTX provides this essential communication. For details, see Transport mechanisms.
6Modified Windows NT hardware abstraction layer (HAL): A special version of the Windows NT HAL that improves the overall reliability and robustness of an INtime node, allowing RT threads to continue executing properly even if Windows NT crashes. For details, see About the modified Windows NT HAL.
¨Note
The modified HAL is required only on an INtime node. Systems which run RT processes on a separate RT nodes use the standard system HAL.
INtime distributed across multiple PCs
When INtime software runs as an INtime node, the Windows NT host communicates with the RT client via the OSEM.
INtime distributed across multiple PCs
When INtime software runs between computers, the Windows NT host communicates with the RT client via RS-232 or Ethernet.
The Windows NT node is a computer that requires a Windows NT subsystem which contains the Windows NT host software.
The RT node is a computer that requires an RT subsystem which contains the RT client software.
With INtime software, NTX communicates between Windows NT and RT portions of INtime applications, whether they reside on a single PC, or on separate computers accessed via serial or Ethernet cable:
1The Windows NT portion of INtime applications, located on a Windows NT host, makes NTX calls that communicate to RT clients.
2NTX determines RT client locations, detects the connection method, and determines how to communicate from Windows NT to RT threads.
3NTX uses the appropriate transport method to communicate with the RT portion of the INtime applications, located on RT clients.
Transport methods available to NTX include:
MechanismTransport driverDescription
OSEMRTIF.SYSUsed when the Windows NT hosts and RT clients co-exist on a single PC. For details, see About the OSEM and How the RT interface driver works.
EthernetUDP/IPUsed for Windows NT nodes and RT nodes connected via a local area network (LAN) cable. UDP/IP provides the quickest transport because it does not handle network congestion. This method is not recommended if the data must travel through numerous routers to reach its destination.
RS-232Serial I/OUsed for Windows NT nodes and RT nodes connected by serial cable.
The OSEM defines the Windows NT and RT environments, and transparently switches execution to the appropriate kernel based on interrupt activity and thread scheduling. Once encapsulated, Windows NT (with all its processes and threads) execute as a single, low priority, RT thread in the context of the RT root process.
The OSEM provides:
·Isolated processes: Uses standard Intel architecture support for hardware multi-tasking to maintain proper address space isolation and protection between Windows NT processes and RT processes. This approach also provides RT responsiveness, regardless of Windows NT activity.
·Transparent thread creation and switching: Transparently creates a hardware task for the RT kernel, and manages the switching and execution of both the standard Windows NT and INtime application hardware tasks.
In a standard Windows NT configuration, the bulk of the OS runs in the confines of a single hardware task. Additional hardware tasks are defined only to handle catastrophic software-induced failures, such as stack faults and double faults, where a safe and known environment is required from which to handle the failure. INtime software’s task switching approach guarantees the integrity of both Windows NT and the RT kernel, and enables the successful operation of RT threads even in the event of a total Windows NT failure (a blue screen crash).
·Additional address isolation via 32-bit segmentation: Provides additional address isolation and protection between RT processes, and between RT processes and Windows NT code. The RT kernel accomplishes this by using multiple sets of 32-bit segments, separate from those used by Windows NT.
·Easy-to-use interface: Provides a clean, well defined interface, which minimizes interaction with Windows NT to a few key areas. The result is improved product reliability and simplified compatibility between Windows NT releases.
With INtime applications running on a single PC, the INtime runtime environment encapsulates all Windows NT processes and threads into a single RT thread of lowest priority as shown in the next figure. As a result, RT threads always preempt running Windows NT threads, guaranteeing hard determinism for RT activities within the system:
When an interrupt occurs, the INtime runtime environment responds in one of these ways:
| Interrupt type | Windows NT In control | RT in control | Shared control |
| Windows NT | Windows NT maintains control. | RT maintains control. | RT determines whether to maintain or relinquish control. |
| RT | RT takes control and pre-empts Windows NT activity. | RT maintains control. | RT maintains control. |
How the RT interface driver (RTIF) works
The RTIF driver begins execution as a Windows NT kernel driver, early in the Windows NT boot process. During initialization, it allocates physically contiguous memory for the RT kernel’s memory pool.
The RTIF driver cooperates with the RT Kernel Loader to load and start the RT kernel in its own environment. The driver queries the registry for various kernel parameters and passes them to the RT kernel at the kernel’s initialization time. Parameters include:
·The number of Windows NT threads that can simultaneously make NTX library calls.
·The low-level tick duration used by the RT kernel.
·The Windows NT time base currently in effect (in microseconds).
If the RT kernel is running, the RTIF driver:
·Routes the clock interrupt (IRQ 0), based on who needs the next clock tick, to either the RT kernel or to the Windows NT clock interrupt entry point for processing.
When neither environment needs the tick, the driver sends an EOI to the PIC for this level and returns control to the interrupted Windows NT thread.
·Immediately routes all other real-time interrupts to the RT kernel for processing.
·Relays NTX library requests to the RT kernel and blocks the calling Windows NT thread until the RT kernel responds to the request and/or until resources are available to complete the request.
Otherwise, the RTIF driver terminates NTX library requests. When the RT kernel announces its termination, the RTIF driver terminates all pending requests.
·Manages the Windows NT portion of controlled shutdown during a Windows NT blue screen crash: the handler notifies the RT kernel to handle the RT portion of the controlled shutdown. If the kernel is not running, control is returned to Windows NT.
In summary, the RTIF.SYS device driver contains the Windows NT portion of the OSEM. It also acts as the NTX transport driver for a co-resident, or local, RT kernel. RTIF.SYS allocates physical memory for the RT kernel and locks that memory in place so it will not be used or paged to disk by the Windows NT kernel. A Windows NT service loads the RT kernel into the allocated memory and issues a “start kernel” command to RTIF.SYS. In response to the start command, the driver establishes a separate hardware task for the RT kernel and hands off control to the kernel’s initialization code. After initializing its environment, the RT kernel creates a low-priority thread (priority level 254) which returns to Windows NT and becomes the Windows NT thread.
About the modified Windows NT HAL
INtime software contains a modified version of the Windows NT Hardware Abstraction Layer (HAL) for PC-compatible EISA/ISA systems. The modified HAL:
·Traps attempts to modify the RT clock so that the RT kernel can control the system time base.
·Traps attempts to assign interrupt handlers to interrupts reserved for RT kernel use.
·Ensures that interrupts reserved for RT kernel use are never masked.
The RT kernel switches the CPU between threads and makes sure the processor always executes the appropriate thread. The kernel maintains an execution state and a priority for each thread.
A priority is an integer value from 0 through 254, with 0 being the highest priority.
| Range | Usage |
| 0–127 | Used by the RT kernel for servicing interrupts. Creating a thread that handles internal events here masks numerically higher interrupt levels. |
| 128–139 | Used by the RT kernel for high-priority threads. Application threads in this range should be limited to high-priority threads which do not need to mask interrupts. |
| 140–253 | Used for normal application threads. |
| 254 | Reserved for the Windows NT thread. |
| 255 | Reserved for a default idle thread that runs only if the Windows NT thread is suspended (for example, as the result of a BSOD. |
Interrupt threads mask lower-priority (numerically higher) interrupt levels. When you assign interrupt levels, give a higher-priority (numerically lower) level to interrupts that can't wait, such as serial input, and a lower priority (numerically higher) to interrupts that can wait, such as cached input.
The execution state for each thread is, at any given time, either running, ready, asleep, suspended, or asleep-suspended. The RT kernel enforces the scheduling policy in which the highest priority ready thread is always the running thread.
Threads run when they have the highest (numerically lowest) priority of all ready threads in the system and are ready to run. Threads can change execution state:
1Threads are created in the ready state.
2The running thread, the ready thread with the highest priority, does one of these:
·Runs until preempted by a higher-priority thread that is ready
·Runs until it removes itself from the ready state by making a blocking system call.
3A thread in any state except ready cannot run, even if it has the highest priority.
A thread can put itself to sleep or suspend itself by using system calls for that purpose. The RT kernel might indirectly put a thread to sleep if the thread makes a “blocking” call by, for example, waiting at a mailbox until a message arrives. The kernel puts the thread in the ready state when the message arrives.
INtime software also provides round-robin scheduling, where equal-priority threads take turns running. Each thread gets a time slice. If a thread is still running when its time slice expires, that thread moves to the end of a circular queue for that priority level where it waits until all threads ahead of it use up their time slices, as shown in the next figure. You adjust the length of the time slice and set the priority level where round-robin scheduling occurs.
Threads A, B, and C are of equal priority below the round-robin priority threshold.
1Thread A, the running thread, stops running when its time slice runs out. Thread A's state is saved and it moves to the end of the queue.
2Thread B, a ready thread, then becomes the running thread.
3Thread A runs again when all threads in the queue finish running.
Higher-priority threads still preempt any running thread in the round-robin queue, regardless of the amount of time left in its time slice.
¨Note
Round-robin scheduling cannot guarantee a predictable worst-case response to events because the number of threads in the queue varies.
Interrupt handler/thread combination
System hardware invokes an interrupt handler in response to an asynchronous interrupt from an external source, based on its entry number in the IDT. The handler takes control immediately and saves the register contents of the running thread so it can be restarted later. There are two ways you can service an interrupt:
·Using a handler alone
·Using a handler/thread combination
An interrupt handler alone can process only interrupts that require very little processing and time. Handlers without threads can:
·Accumulate data from the device in a buffer. The data must have an associated thread to process the data.
·A handler begins running with all interrupts disabled. It must execute quickly and then exit to minimize its effect on system interrupt latency.
·Find the interrupt level currently serviced. This is useful if one handler services several interrupt levels.
·Send an EOI signal to the hardware.
By itself, an interrupt handler can only do very simple processing, such as sending an output instruction to a hardware port to reset the interrupt source. Handlers can use only a few system calls. For a list and description of system calls, see Appendix A, INtime software system calls in the INtime software overview guide. For detailed information, including syntax and parameter values, see System calls by type.
During the time the interrupt handler executes, all interrupts are disabled. Since even very high level interrupts are disabled, it is essential that the handler execute quickly and exit.
When the handler finishes servicing the interrupt, it sends an EOI to the PIC via an INtime software system call, restores the register contents of the interrupted thread, and then surrenders the processor. The processor returns to the interrupted thread.
Interrupt handler/thread combination
An interrupt handler/thread combination provides more flexibility. Although the handler may perform some processing, it typically signals the corresponding interrupt thread to do most or all interrupt processing. In general, use an interrupt handler/thread combination if the processing requires more than 50 microseconds or requires system calls that interrupt handlers cannot use.
When the specified interrupt thread exists, the handler can put accumulated information into a memory address, if the interrupt thread set one up. The interrupt thread can access data in the memory address and perform the required processing.
Interrupt threads can access to the same resources and use the same system calls as ordinary threads. Interrupt threads also have a thread priority assigned by the RT kernel, based on the interrupt level associated with the handler. Ordinary threads have a priority which you assign.
In addition to the usual thread activities, an interrupt thread can also:
·Cancel the assignment of an interrupt handler to an interrupt level.
·Wait for an interrupt to occur.
·Enable and disable interrupts.
This shows how an interrupt thread enters an event loop where it waits to service an interrupt.
1Upon creation, the interrupt thread uses an RT system call to set up an RT interrupt and associate itself with this interrupt. Normally, it then waits for a signal that indicates an interrupt occurred.
2When signaled, the interrupt thread executes the required operations.
3The interrupt thread releases control by waiting for the next signal from the interrupt handler, which restarts the cycle shown in this figure.
INtime software enables threads to:
·Create single-shot and repetitive alarm events for a specified time interval, and specify which alarm event thread to activate.
·Specify a low-level tick duration of less than the 10-millisecond granularity provided by high level.
·Start and stop scheduling by the RT kernel.
Software alarm events are virtual timers that invoke alarm event threads that you write.