Managed Code Is Tested in Real-Time and Embedded Applications

Reusability and Garbage-Collection Features Increase the Usefulness of C# in Driver Development.

By Chris Tacke & Lawrence Ricci

Over the last few years, a clear trend has emerged as OEMs moved their embedded-systems applications into volume production. Managed code�principally Microsoft C#�is increasingly being used in these applications. Individuals have selected C# because it has automatic �garbage collection� and should be free of memory leaks. In addition, Microsoft C#�s object orientation facilitates the development of complex systems with reusable components. When they�re complemented by an integrated design environment like Visual Studio IDE, languages like C# and Visual Basic (VB) will facilitate quick application development. Extensive information on C# and its limits wasn�t available, however. To resolve some questions about C#, a series of tests was run under the Compact Framework 2.0 on the Intel PXA255 XScale platform.

The results indicated that C# offers real-time performance that�s essentially equal to C++ for most applications. The most critical of these applications is the use of C# to write �drivers� or what might be more accurately titled �handlers� for typical real-time devices. Those devices are connected through SPI, I2C, GPIO, CAN, and other high-speed interfaces. Many of these common I/Os are supported directly off of the Intel PXA chip set. This article provides a quick summary of the findings from those tests. A more detailed analysis including code samples is available from the Applied Data Systems (www.applieddata.net) or Microsoft (www.microsoft.com) web sites.

The Problem
Driver writing for embedded systems is serious business. This statement is especially true for power-aware, 24-x-7 embedded systems. To keep power consumption low, drivers need to be aware of the major processor states including sleep. They also need to initialize in microseconds. Yet the mandate for 24-x-7 operations means that no development shortcuts can be taken. Code must not create any �stacks,� �buffers,� or reserved memory areas that it doesn�t clean up. Likewise, drivers for the new PXA-native interfaces can be complex. They also demand significant processing before handing data off to the application.

Tests were run to compare both the �speed� of C# to C++ and the �latency� associated with the transfer of data across the managed-code and unmanaged-code boundary. Keep in mind that the actual silicon interface is by necessity an unmanaged environment. Based on these tests, it appears that C# is sufficiently fast and exhibits low enough latency to allow the use of C# and even VB from many types of real-time applications.

The big surprise was raw speed. The chart in Figure 1 shows the speed of a simple program, which was written in C#, toggling a GPIO interface on and off.

Clearly, C# is efficient enough to run this loop about every 100 ns. The results are virtually indistinguishable from a similar test running C++. It could be argued that the C#/JIT interpreter is fast or the C++ compiler produces slow code. With timing at the level of a small spool of copper wire, however, there�s little need to investigate further.

Speed of execution might be the dominant issue for some managed-code applications, such as the process models used for real-time control. Yet it's far from the full performance limit for programs like drivers/handlers. Such programs must penetrate the managed/unmanaged boundary to communicate to silicon.

Managing Latency
The first test was a simple, direct interface from C# to the central-processing- unit (CPU) GPIO registers. It used �p-invoke,� as might be called by either C# or Visual Basic. In this configuration, data passes across the boundary in a buffer created and managed by the CF and via some OS-provided calls. Here, latency is significant (see Figure 2).

Although this test is fully seven times �slower� than the prior test, it�s still very fast. To put it in perspective, these program cycles�each invoking the full latency�are less than a microsecond wide. One millisecond�the typical time interval for �fast� industrial devices�is 1000 times greater. Note also that the cycles were regular and deterministic. There was no observable interaction with the CF garbage-collection function. Improvements are possible, however.

Using some features that are specific to C#, data can be exchanged between managed and unmanaged regions via memory locations. Those memory locations are specifically identified and �managed� by the program writer. A test was developed based on this methodology. The performance achieved was comparable to simple C++ code (see Figure 3).

Based on the testing, it can be concluded that C# isn�t the preferred or even unconditionally acceptable tool for all device drivers. Yet C# does seem to satisfy reasonable requirements for speed, determinism, and latency. Its performance qualifies it for many items that are tolerant of large potential but typically rare latencies. Devices that interface with I_C or SPI synchronous serial buses or many GPIO devices are well within the realm of possibility. In addition, it was found that managed code could perform equally to unmanaged code. If the engineer takes the time to eke out deterministic behavior from the CLR, he or she can easily have the performance required for a whole host of devices.

Chris Tacke, the principle author of this paper, is a Microsoft MVP and recognized expert for managed code development. Mr. Tacke, author of � Embedded Visual Basic: Windows CE and Pocket PC Mobile Applications.� He is the Director of Software Development for APplied Data Systems.

Lawrence Ricci, a Microsoft Windows Embedded MVP, works with Applied Data Systems to develop real time and secure embedded applications.