|
|
|
| R2012a Documentation → xPC Target | |
Learn more about xPC Target |
|
| Contents | Index |
Polling mode for the kernel is designed to execute target applications at sample times close to the limit of the hardware (CPU). Using polling mode with high-speed and low-latency I/O boards and drivers allows you to achieve smaller sample times for applications that you cannot achieve using the interrupt mode of the xPC Target software.
Polling mode has two main applications:
Control applications — Control applications of average model size and I/O complexity that are executed at very small sample times (Ts = 5 to 50 µs)
DSP applications — Sample-based DSP applications (mainly audio and speech) of average model size and I/O complexity that are executed at very high sample rates (Fs = 20 to 200 kHz)
Polling mode for the kernel does not have the 8 µs of latency that interrupt mode does. This is because the kernel does not allow interrupts at all, so the CPU can use this extra time for executing model code.
Polling mode is sometimes seen as a "primitive" or "brute force" real-time execution scheme. Nevertheless, when a real-time application executes at a given base sample time in interrupt mode and overloads the CPU, switching to polling mode is often the only alternative to get the application to execute at the required sample time.
Polling means that the kernel waits in an empty while loop until the time at which the next model step has to be executed is reached. Then the next model step is executed. At least a counter implemented in hardware has to be accessible by the kernel in order to get a base reference for when the next model step execution has to commence. The kernel polls this hardware counter. If this hardware counter must be outside the CPU, e.g., in the chip set or even on an ISA or PCI board, the counter value can only be retrieved by an I/O or memory access cycle that again introduces latency. This latency usually eats up the freed-up time of polling mode. Fortunately, since the introduction of the Pentium CPU family from Intel, the CPU is equipped with a 64 bit counter on the CPU substrate itself, which commences counting at power-up time and counts up driven by the actual clock rate of the CPU. Even a highly clocked CPU is not likely to lead to an overflow of a 64 bit counter (2^64 * 1e-9 (1 GHz CPU) = 584 years). The Pentium counter comes with the following features:
More precise measurements — Because the counter counts up with the CPU clock rate (~1 GHz nowadays), time measurements even in the microsecond range are very precise, leading to small real-time errors.
Overflow handler not required— Because the counter is 64 bits wide, in practical use overflow does not occur, avoiding the CPU-time overhead of handling overflows.
Minimal latency — The counter resides on the CPU. Reading the counter value can be done within one CPU cycle, introducing minimal latency.
The polling execution scheme does not depend on any interrupt source to notify the code to continue calculating the next model step. While this frees the CPU, it means that any code that is part of the exclusively running polling loop is executed in real time, even components, which have so far been executed in background tasks. Because these background tasks are usually non-real-time tasks and can use a lot of CPU time, do not execute them. This is the main disadvantage of polling mode. To be efficient, only the target application's relevant parts should be executed. In the case of the xPC Target software, this is the code that represents the Simulink model itself.
Therefore, host-target communication and target display updating are disabled. Because polling mode reduces the features of the xPC Target product to a minimum, you should choose it only as the last possible alternative to reach the required base sample time for a given model. Therefore, do the following before you consider polling mode:
The model is optimal concerning execution speed — First, you should run the model through the Simulink profiler to find any possible speed optimizations using alternative blocks. If the model contains continuous states, the discretization of these states will reduce model complexity significantly, because a costly fixed-step integration algorithm can be avoided. If continuous states cannot be discretized, you should use the integration algorithm with the lowest order that still produces the required numerical results.
Use the fastest available computer hardware — Use the CPU with the highest clock rate available for a given PC form factor. For the desktop form factor, this would mean a clock rate above 3 GHz; for a mobile application, e.g., using the PC/104 form factor, this would mean a clock rate above 1 GHz. Executing xpcbench at the MATLAB prompt gives a relative measure of CPU performance when running typical target applications.
Use the lowest latency I/O hardware and drivers available — Many xPC Target applications communicate with hardware through I/O hardware over either an ISA or PCI bus. Because each register access to such I/O hardware introduces a comparably high latency time (~1 µs), the use of the lowest latency hardware/driver technology available is crucial.
The base sample time is about 50 µs or less — The time additionally assigned to model code execution in polling mode is only about 8 µs. If the given base sample time of the target application exceeds about 50 µs, the possible percentage gain is rather small. Other optimization technologies might have a bigger impact on increasing performance.
Polling mode is an alternative to the default interrupt mode of the kernel. This means that the kernel on the bootable media created by the GUI allows running the target application in both modes without using another boot disk.
By default the target application executes in interrupt mode. To switch to polling mode, you need to pass an option to the System target file command.
The following example uses xpcosc.mdl.
In the Simulink window, and from the Tools menu, point to Code Generation, and then click Options.
The Configuration Parameters dialog box opens.
In the left pane, click the Code Generation node.
In the TLC options edit field, specify the option
-axpcCPUClockPoll=CPUClockRateMHzYou must assign the target computer CPU clock rate because the Pentium's on-chip counter used for polling mode counts up with the CPU clock rate. If the clock rate is provided, the kernel can convert clock ticks to seconds and vice versa. If the required clock rate is not provided, the target application does not execute at the required base sample time. You can find out about the CPU clock rate of the target computer by rebooting the target computer and checking the screen output during BIOS execution time. The BIOS usually displays the CPU clock rate in MHz right after the target computer has been powered up.
For example, if your target computer is a 1.2 GHz AMD Athlon, specify the following option in the TLC options edit field:
-axpcCPUClockPoll=1200
If you want to execute the target application in interrupt mode again, either remove the option or assign a CPU clock rate of 0 to the option:
-axpcCPUClockPoll=0
If you make a change to the TLC options field, you need to rebuild the target application for the change to take effect. Building the target application, downloading it, and preparing it for a run then work exactly the same way as they did with default interrupt mode.
After the download of the target application has succeeded, the target screen displays the mode, and if polling mode is activated, it additionally displays the defined CPU clock rate in MHz. This allows you to check the setting.
As explained above, polling mode executes the Simulink-based target application in real time exclusively. While the target application is executing in polling mode, all background tasks, including those for host-target communication, target screen updating, and UDP transfers, are inactive. This is because all interrupts of the target computer are fully disabled during the execution of the target application. On one hand, this improves polling performance; on the other hand, background tasks are not serviced.
The following topics list all relevant restrictions of polling mode, which are otherwise available in the default interrupt mode.
If the target application execution is started in polling mode, e.g., with
start(tg)
host-target communication is disabled throughout the entire run, or in other words until the stop time is reached. Each attempt to issue a command like
tg
leads to a communication-related error message. Even the start(tg) command to start polling mode execution returns such an error message, because the host side does not receive the acknowledgment from the target before timing out. The error message when executing start(tg) is not avoidable. Subsequently, during the entire run, it is best not to issue any target-related commands on the host, in order to avoid displaying the same error message over and over again.
As a consequence, it is not possible to issue a stop(tg) command to stop the target application execution from the host side. The target application has to reach its set stop time for polling mode to be exited. You can use
tg.stoptime=x
before starting the execution, but once started the application executes until the stop time is reached.
Nevertheless, there is a way to stop the execution interactively before reaching the target application stop time. See Controlling the Target Application.
If the target application execution finally reaches the stop time and polling mode execution is stopped, host-target communication will begin functioning again. However, the host-target communication link might be in a bad state. If you still get communication error messages after polling mode execution stops, type the command
xpctargetping
to reset the host-target communication link.
After the communication link is working again, type
tg
to resync the target object on the host side with the most current status of the target application.
As with the restriction mentioned above, target screen updating is disabled during the entire execution of the target application. Using the kernel with the Enable target scope option enabled (see xpcexplr GUI) does not work. You should therefore use the kernel with the Enable target scope property disabled (text output only). The kernel enabled with text mode actually provides more information when running in polling mode.
Because all interrupts are disabled during a run, the session time does not advance. The session time right before and after the run is therefore the same. This is a minor restriction and should not pose a problem.
Because host-target communication and target screen updating are disabled during the entire run, most of the common rapid-prototyping features of the xPC Target product are not available in polling mode. These include
Parameter tuning — Neither through the command-line interface nor through Simulink external mode
Through scope objects — Not through the following types of scope objects:
host (xPC Target Explorer or scripts)
target (scopes on the target screen if property Enable target scope is enabled)
file (xPC Target Explorer, scripts, or blocks, on target computers that have file systems)
Signal monitoring — You cannot run a GUI interface on the host computer using an environment that depends on communication between the host and target computers.
Applications using the xPC Target API
The Internet browser interface
Other utilities like xpctargetspy
The only rapid-prototyping feature available is signal logging, because the acquisition of signal data runs independently from the host, and logged data is retrieved only after the execution is stopped. Nevertheless, being able to log data allows gathering good enough information about the behavior of the target application. Signal logging becomes a very important feature in polling mode.
Because of the polling mode execution scheme, executing Simulink-based target applications in multitasking mode is not possible. The modeling of function-call subsystems to handle asynchronous events (interrupts) is not possible either. This can be a hard restriction, especially for multirate systems. Multirate systems can be executed in single-tasking mode, but because of its sequential execution scheme for all subsystems with different rates, the CPU will most likely overload for the given base sample time. As an important consequence, polling mode is only a feasible alternative to interrupt mode if the model has a single rate or if it can be converted to a single-rate model. A single-rate model implies continuous states only, discrete states only, or mixed continuous and discrete states, if the continuous and discrete subsystems have the same rate. Use the Simulink Format > Sample time color feature to check for the single rate requirement. Additionally, set the tasking mode property in the Simulation menu Configuration Parameters > Solver pane to SingleTasking to avoid a possible switch to multitasking mode. For more information on single-tasking mode compared to multitasking mode, see the Simulink Coder User's Guide documentation.
Some xPC Target drivers use timing information exported from the kernel to, for example, detect time-outs. Because the standard timing engine of the kernel does not run in polling mode, the required timing information is not passed back to the drivers. Therefore, in polling mode you cannot use drivers that import the header file time_xpcimport.h. This is a current restriction only. In a future version of polling mode, all drivers will make use of the Pentium counter for getting timing information instead.
As mentioned, there is no way to interact with the running target application in polling mode. This is especially restrictive for the case of stopping the model execution before the application has reached the stop time that was defined before the execution started. Because polling mode tries to be as optimal as possible, any rapid-prototyping feature except signal logging is disabled. But because I/O driver blocks added to the model are fully functional, you can use I/O drivers to get to a minimal level of interactivity.
Stopping a target application using polling mode — You can use a low-latency digital input driver for the digital PCI board in your model, which reads in a single digital TTL signal. The signal is TTL low unless the model execution should be stopped, for which the signal changes to TTL high. You can connect the output port of the digital input driver block to the input port of a Stop simulation block, found in the standard Simulink block library. This stops the execution of the target application, depending on the state of the digital input signal. You can either use a hardware switch connected to the board-specific input pin or you can generate the signal by other means. For example, you could use another digital I/O board in the host machine and connect the two boards (one in the host, the other in the target) over a couple of wires. You could then use the Data Acquisition Toolbox™ product to drive the corresponding TTL output pin of the host board to stop the target application execution from within the MATLAB interface.
Generally, you can use the same software/hardware setup for passing other information back and forth during run time of the target application. It is important to understand that any additional feature beside signal logging has to be implemented at the model level, and it is, therefore, the user's responsibility to optimize for the minimal additional latency the feature introduces. For example, being able to interactively stop the target application execution is paid for by the additional 1 µs latency required to read the digital signal over the digital I/O board. However, if you need to read digital inputs from the plant hardware anyway, and not all lines are used, you get the feature for free.
This is preliminary information. All benchmarks have been executed using a 1 GHz AMD Athlon machine. For more information about benchmarks, see xpcbench or type help xpcbench in the MATLAB Command Window.
The minimum achievable base sample time for benchmark model Minimal is 1 µs with signal logging disabled and 2 µs with signal logging enabled.
The minimum achievable base sample time for model f14 using an ode4 fixed-step integration algorithm is 4 µs with signal logging disabled and 5 µs with signal logging enabled.
A more realistic model, which has been benchmarked, is a second-order continuous controller accessing real hardware over two 16 bit A/D channels and two 16 bit D/A channels. The analog I/O board used is the fast and low-latency PMC-ADADIO from http://www.generalstandards.com, which is used in conjunction with some recently developed and heavily optimized (lowest latency) xPC Target drivers for this particular board. The minimum achievable base sample time for this model using an ode4 fixed-step integration algorithm is 11 µs with signal logging disabled and 12 µs with signal logging enabled. This equals a sample rate of almost 100 kHz. The achievable sample time for the same model in interrupt mode is ~28 µs or a sample rate of ~33 kHz. For this application, the overall performance increase using polling mode is almost a factor of 3.
If your target computer has multicore processors, enabling the multicore processor supports removes the following restrictions. Other restrictions still apply. (For details on how to enable multicore processor support, see the setxpcenv function or the Changing Environment Properties with xPC Target Explorer topic in the Target Application Environment chapter.)
Host-target communication is now available during the execution of the target application.
Target screen now updates during the execution of the target application.
External interrupts are now allowed during the execution of the real-time model. This does not mean that you can trigger your model with an external interrupt.
File scopes can now log data into a file on the target computer.
 | Interrupt Mode | Execution Using MATLAB Scripts |  |
Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.
| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
