Currently, Windows CE has upgraded from a basic operating system to a small size, component-timered embedded operating system. Although Windows CE has the same application programming interface (API) as Win32, and Microsoft desktops and server operating systems are also equipped with such interfaces, but the underlying operating system architecture of Windows CE is completely different. Windows CE supports both a desktop application development structure including Win32, MFC, ATL, etc., also supports management application development of .NET Compact Framework, and supports current real-time embedded system design, providing real-time kernels necessary for operating systems. . In this article, we mainly discuss operating system tools for verifying Windows CE 5.0 real-time efficacy.
It is well known that the real-time system does not test through a single analysis, even if a single analysis can prove the correctness of the real-time system. The test of real-time system is based on the basis for discussing this issue. Your job is to build a user's trust in the solution. The tools introduced below can explain the interaction between applications and operating systems in real time, which helps you deepen your understanding of real-time systems.
Although there are still many disputes on real-time definitions, we still come to understand the definition of it. Here, I will quote the definition of Comp.RealTime FAQ. The authority definition of the real-time system is as follows:
"The real-time system is such a system, that is, the correct or not, but also depends on whether the calculation logic is correct, but also depends on the time spent on the calculation result. If the system's time limit is not met, the system failure will occur. "
Because the high speed I / O, robotic technology and mechanical control of industrial automation is most demanding. Microsoft began to understand special social requirements for real-time embedded operating systems. Since 1986, General Vehicle Power Corporation (GMPTG) has been in a leading position in manufacturing applications, and the formation of OMAC subscribers is then contributed to the OMAC user group. After assessing hundreds of applications, they found that most systems (95%) require a millisecond or a slight period. A millisecond cycle allows for a variation of 10%, or 100 microseconds (μs). This is a design goal of Windows CE based on 200 MHz X86 system, which is 50 μs on this platform. Windows CE reaches or exceeds 95% of the evaluated hard-real application OMC requirements.
Most industrial automation applications that meet the requirements are driven by external signals from one machine. This signal is sent to a hard real-time application in an interrupted form. Microsoft encourages the developers of Windows CE to place more application code in the Interrupt Service Thread (IST) as much as possible. This makes the OMAC jitter definition to time limit for IST delays that do not exceed 100 μs. The rest of the evaluated application uses the timer to create its cycle. This requires a 1 millisecond timer that is delayed or jitter does not exceed 100 μs. In short, OMAC definitions present the following design and test requirements:
· Interrupt Service Thread (IST) Latencies of no more Than 100 μs latency.
· 1 Millisecond Timers with maximum of 100 μs latency.
• Interrupt Service Thread (IST) delay does not exceed 100 μs.
· 1 millisecond timer delay is up to 100 μs.
After you understand the OMAC's design and test requirements, let's take a look at the tools installed in Windows CE. The purpose of these tools is to determine interrupt timing, application execution action, operating system function timing, timing schedule.
It is also important to distinguish between real-time systems and real-time operating systems. Real-time systems include all elements such as hardware, operating systems, and applications. The real-time operating system is merely one of the elements that make up the real-time system. For more information, see Microsoft Windows CE Real - Time Performance Design and Optimization. We will introduce many tools and uses:
· Iltiming. This tool is used to determine the interrupt service routine (ISR) and interrupt service thread (IST) delay of the platform. The ISR delay refers to the time interval between the hardware to the first interrupt service routine instruction. The IST delay refers to the time interval between the existing ISR to the interrupt service thread.
One of the most important features of the internal verification time, that is, interrupts can be implemented within the specified time. The interrupt delay mainly refers to the time interval between the software interrupt processing, that is, from the external interrupt to the processor until the start of the interrupt processing starts.
If a paging operation occurs, the Windows CE interrupt delay time is limited to a thread that is locked in memory. This can calculate the delay time in the worst case - to the startup of the ISR and the total use of the start of the IST. By calculating the time required for ISR and IST, it is possible to determine the total use of the interrupt processing previously used.
ISR delay
The ISR delay refers to the time when the IRQ is set to the ISR in the CUP. The following three related variables affect the start of the ISR:
A = the longest time in which the interrupt is closed in the kernel. The kernel rarely closes the interrupt, but if they turn it off, the length of time that is turned off will be restricted.
B = Time between the kernel scheduling interrupt and the ISR being actually invoked. The kernel uses this time to determine what ISR to run and save any registers that must be saved before proceeding.
C = The time between the ISR returns to the kernel and kernel instinct stop processing interrupt. This is the time of completion of the ISR operation by restoring any status (e.g., register) saved before the ISR is called.
The startup time of the ISR that is measured can be calculated based on the current state of other interrupts in the system. If the interrupt is being performed, the startup time of the new ISR to be measured must take into account two factors: the number of higher priority interrupts will occur after the interrupt has occurred, and the time occupied by the ISR.
Windows CE and Original Equipment Manufacturers (OEM) will affect the time of execution ISR. The control variables A, B, and C of Windows CE are limited.
IST delay
The IST delay refers to the time executable from completion of the ISR (notification thread) to IST. The following four-related variables affect the start of IST:
B = Nuclear scheduling interrupt and truly call the time interval of ISR. The kernel uses this time to determine what ISR will run and save any registers that must be saved before proceeding.
C = The time between the ISR returns to the kernel and kernel instinct stop processing interrupt. This is the time of the ISR operation by restoring any status (e.g., register) saved before the ISR is called.
L = The maximum time in kcall (kernel call).
M = time for scheduling the thread.
In the ISR returns to the kernel and the kernel performs some work to start the startup time of the highest priority IST after IST. After the ISR returns and notifies the IST start operation, the IST startup time is affected by the total time of all ISR. The following example illustrates the resulting start time:
Top priority IST startup time =
Windows CE and OEM will affect the time required to execute IST. Windows CE control variables B, C, L, and M are limited. OEM Controls NISR and TISR (N), which can affect IST delays.
Windows CE also adds the following restrictions on the IST: Link ISR and IST events can only be used in the WaitForsingleObject function. Windows CE prevents ISR-IST event processing from being used in the WaitFormultiPleObjects function, which means that the kernel can guarantee the time of triggering events and the time limit of the IST.
· Osbench: This tool allows you to collect timer samples, measure the performance of the kernel by performing scheduling performance timing tests. · KERNEL TRACKER: This tool can visually display the execution status of the Windows CE .NET operating system on the target device. This tool can be used to view thread interactions, internal associations, and system status information in real-time environments. This article is to verify the interaction between threads and processes.
• Call the Evaluation Process: This tool can be used to determine the algorithm of the code.
There are many factors that affect real-time performance, such as hardware, drivers, and applications. In this example, we start from the application level. All resources should be assigned when running in the real-time environment. All kernel objects (processes, threads, mutex, critical sections, signals, and events) are allocated to virtual memory in accordance with the needs of the needs. On-demand is assigned is uncertain, so it cannot be limited to the time limit of the operation of the operating system, so it cannot be used in real-time execution of the application.
Remote call evaluation program
Real-time systems include not only hardware and operating systems, but also increasing application logics are also running on the same hardware. Therefore, the application code in the embedded design may have failed risks. Windows CE does not force the IST to run in the device driver environment, IST is just a special thread, so IST threads can be run in the application environment. In this case, how do I verify the bottleneck of application code? Of course, this may affect the overall performance of the equipment. The answer is: This is the tool for Windows CE installation - the functionality of the remote call evaluation program. This tool can answer the following questions: When is the code to do? What is the interaction of software components? What is the CPU do when the application is running?
In order to prove this, I use the construction and run "philosopher dining problem" applied to Windows CE. The following is a solution process: now, five philosophers (threads) sit around the round table. Put a bowl of food in front of each person. Philosophers started to eat with a chopstick. The premise of philosophers' dining is that he must have two chopsticks (therefore, there must be one person in five philosophers to offer a chopstick). At this time, philosophers must find a way to share chopsticks to ensure that everyone can eat food in the bowl.
Similarly, when there is more than one thread (philosopher) in multi-threaded programs, it is possible to die or dispute, of course, this depends on the extent of philosophers! If multiple threads are waiting for use of scarce resources, they will cause uncertainty of waiting time, and thus freeze all applications. For real-time applications, this is not a problem, you can choose the remote call evaluation program to run applications to resolve this issue.
Remote Call Evaluate can display call information in different views, including intuitive call charts. It displays the time spent when the application runs each function. Obviously, this is the most efficient tool for processing real-time compression / decompression issues for video / audio streams. The following table shows the view in the remote call evaluation program application.
Table 1. View in the remote call evaluation program
view
description
Top view (TOP X View)
Shows the longest function or the value calculated based on the specified timing standard.
Module Overview
Statistics list the data loaded into the module and the case of entering each functional module.
Call tree view
Display the hierarchical description of the function call path.
Butterfly view
Displays data reflecting the relationship between the main call and the called function in list format.
Call chart view
Displays the total dependency between functions.
Call tracking and function tracking view
Display data grids to reflect the timing value of the actual and calculation of the function into and exit the event. The following figure shows the call chart view of the philosopher application. This figure shows that 35% of the application time is expected to be on the function EAT (). Maybe you should find out the content of the function!
Figure 1. Remote call evaluation program
You may ask, to run a remote call evaluation program, you need to add something to your application code. In fact, you don't need to change all code at all, but only need to compile with other flag functions (WinceCallcap = 1).
The call evaluation library provides a unique application logic execution process detail for the application developers. Use the tool for low speed testing processes to cultivate customer sense of application code.
Kernel Tracker:
The remote kernel trace program can be used to detect the interaction relationship between processes, threads, and interrupts on running devices. Below is a sample code integrated in the kernel trace program. The application in the instance is running a file system for the Windows CE device, one of which places a release file on the desktop, which generates a Kitl (kernel independent transport layer) interrupt for each file residing in the desktop. Therefore, we can clearly observe the interaction between applications and interrupts in the operational system mirror image, or determine the time increment between the application thread operation and KITL interrupt processing.
As a user interface
,
The kernel tracking program is divided into three areas.
,
Left pane display interrupt and process
,
Medium pane display thread
/
Interaction between processes
,
Right pane
(
Not displayed
In the content
Is the interpretation of the symbols used in the middle pane. We can see clearly in the bottom of the image.
W
Alktree
Application is running
,
But you can't see the time spent in the application and kernel environment.
