Home »

Print - Send - -

Chassis & Suspension

Interoperability is paramount for software tools

The idea of combining individual results of different programs to achieve an overall result is not new. Even at the time when computers were operated only via a command-line interface (UNIX shell), already several tools could be linked together with the 'pipe' mechanism. Thus, the output data of one was the input data for the next program. However, in those days, the necessary standardization of the mostly textual outputs was very simple, because operating system, shell and program originated from one and the same manufacturer.

However, the introduction of graphical user interfaces and the, now as then, constantly growing supply of different tools poses completely new challenges for manufacturers of development tools for quite some time now. A closer examination of cross-development tools for Windows hosts will substantiate this.

Cross-tools - this includes particularly compilers and debuggers, but also tools for modeling, calibration, test, etc. - by definition run on a different hardware platform than the actual target application. One can thereby differentiate various steps of interoperability. Meanwhile, the use of, for example, standardized file formats such as ELF/DWARF format - which contains both machine code for the target application and information for debugging - is common. The working together of different compilers and debuggers/emulators is generally not a problem and is taken for granted by the users.

XML is also being used increasingly often for the structured storage of data. With the Universal Debug Engine (UDE), a cross-debugger for 16/32-bit microcontrollers of various manufacturers, all device-specific descriptions are stored in XML format since almost two years now. The reason for this is because XML compared to proprietary formats allows, for example, a simple adding of application-specific or non-documented peripheral registers and, if necessary, even correction of the definitions by the user. Similarly, the debugger exports data - for example, recorded system parameters - in XML format. This allows simple further processing by other tools (for example, MS Excel).

Standardized interfaces

In both cases - with the use of standardized file formats as well as XML - it concerns a passive form of interoperability, in which the working together of tools at the same time is not necessary. Active solutions, in which various tools can be combined directly to a continuous workflow, are obviously much more interesting for the developer, because they are considerably more flexible. This can take place either by the participating manufacturers or even by the users themselves. However, a coupling carried out by the user generally depends on a high degree of standardization, documentation and, if necessary, training.

The goal of an active solution is that the tools used can either directly interact or else work together via a program controlling the overall process. However, the essential perquisite for this are defined and, ideally, standardized interfaces between the tools. A simple C DLL interface no longer seems to be necessarily up-to-date here. Considerably more interesting as interface basis is the Component Object Model (COM), which is sometimes also termed as ActiveX. This should not be confused with the serial interfaces (COM1, ...), which are disappearing from modern PCs. Component Object Model (COM) not only allows a programmatic utilization of C/C++ and programming languages from the .NET world such as C#. COM also is particularly provided by a multitude of script languages such as JavaScript, Phyton, Perl, Visual Basic Script or Windows PowerShell. All allows the control of COM components. The user can, thereby, create his/her own workflows without much training effort, which in turn leads to noticeable saving effects, for example, in test automation.

Since the Universal Debug Engine (UDE), which right from the beginning was equipped with COM interfaces, also uses this technology for internal scripts and application-specific windows based on HTML, users can use the functionality of the UDE without first having to additionally learn a proprietary macro language. Command of a standardized script language and knowledge of the object model are entirely sufficient. With COM, the entirety of all documented objects, methods, characteristics and data types are denoted as object model. This allows almost all aspects of the UDE, including add-ins such as UDE/MemTool for flash programming or CAN recorder, to be controlled or used internally or externally by scripts. An integrated script debugger aids the creation of correct executing automations.

Coupling of tools by two manufacturers

Just how easy a coupling of various tools based on COM interfaces can function is shown by the combining of a development environment with structogram and state diagram editors from EasyCODE and the Universal Debug Engine (UDE) from pls. The user can debug at structogram level, in other words execute individual steps, set breakpoints, start and stop the target program and view variables. The user does not have to the leave the EasyCODE editor when searching for errors at the structogram and high-level language levels. Control of the target is carried out by the UDE simultaneously in the background. Since both tools run synchronously, a change to the debugger is possible at all times in order, for example, to investigate hardware-specific problems (Figure 1).

 

For full resolution, please click here

Tool coupling by the user

How can a user now himself/herself carry out a tool coupling? A small practical example follows, which contains the steps: Starting of a debugger from an external script, programming an application in the flash of the target microcontroller, execution of the application for a set amount of time, starting MS Excel and creating a table with data from the target.

PowerShell 2.0, which is included in every Windows installation from Windows 7, serves as script environment. Download packets for Windows XP and Vista are available for installation. PowerShell 2.0 replaces the former Windows command line and Windows Scripting Host. It builds heavily on the .NET Framework 2.0 and extends the concepts of conventional shells, which process text with pipes and filters. With 'PowerShell Scripting Language', PowerShell provides a simple script language for the handling with objects of the .NET Framework und COM objects. Furthermore, a free-of-charge development environment - named 'Integrated Scripting Environment' - simplifies the creation, interactive execution and debugging of PowerShell scripts.

For full resolution, click here 

Figure 2 shows the working together of the tools as a block diagram, the PowerShell script and the display in MS Excel. In the first section (1) of the script, a debugger instance is setup as COM object and thus the debugger window is started minimized. Next, a target configuration is transferred to a newly created workspace. Subsequently, the interface with the required debugger functions is stored in the variable '$Debugger' and a successful connection with the target is awaited.

In the second block (2) of the script, an add-in of the debugger for flash programming is first activated, then an application file loaded in the debugger and this subsequently programmed in the flash memory of the microcontroller.

In the third section (3), the target is reset after the flash programming and the program execution started in the internal flash. The application on the target is stopped after 10 seconds.

In the fourth script block (4), some data are read from the target after the start of MS Excel, transferred into an Excel table and stored as a file. With corresponding design of the debugger object model - e.g. by enumerated types and suitable variable names - in this way, easy to read script code such as, for example, in the statement 'foreach ($Element in $Buffer) { ... $Element.Value ...}' can be realized. The result is shown in Figure 2. The script shown is complete and thus executable with exception of the definition of some environment-specific string variables ($WorkspaceFile, $TargetConfigFile, $ProgramFile, $ExcelFile).

Eclipse as framework for tools

A further close link between tools is when a manufacturer provides its tool functionality within the scope of a larger framework, for example, Eclipse. Whist Eclipse was originally created as IDE; since Version 3.0 only a framework for so-called plug-ins exists that provide the actual functionality. Both Eclipse itself and the plug-ins are implemented in Java. However, this does not mean that plug‑ins can not execute functionality from native code components. Eclipse's graphic interface, which is based on the Standard Widget Toolkit (SWT), also sits on top of native GUI components of the respective operating system on which the Java environment runs. Eclipse and under certain circumstance also plug-ins are thus not necessarily platform independent.

The real weak point for a successful cross-development under Eclipse is still the debugger component of CDT, which is supplemented beside high level language debugging with windows for memory, register and disassembler and is implemented as own perspective. The Eclipse Foundation propagates the use of Eclipse for embedded development; however, a Java application on a smart phone differs considerably in the debug and test requirements from that of a C application on an industrial or automotive control unit.

For the latter two use cases, the standard CDT debugger, among other things, lacks the possibility to access the memory and to update values in the debugger during the run-time of the target. Furthermore, neither a presentation of peripheral registers (mostly several hundred with modern microcontrollers) nor an analysis of trace data for code coverage and code profiling (both must be read and visualized without a stop of the target) are possible. The debugging model is solely based on observation of the target in the stopped condition. This is simply not sufficient for modern cross-debugger solutions.

In order to eliminate this dilemma, modern tools such as the Universal Debug Engine (UDE) provide, in the meantime, their complete functionality without any compromises in an own debug perspective. This is made possible by the component-oriented tool construction with strict separation of function and user interface. A relatively thin wrapper written in Java, the UDE Eclipse plug-in, connects Eclipse with the function components of the UDE. For this purpose, besides the SWT-based window and menu services of the Eclipse Workbench, the debug interface of an installed CDT as well as interfaces of the SWT to Win32 native functions are also used (Figure 3).

The UDE Eclipse plug-in is only available on Windows platforms - as is the Universal Debug Engine (UDE) itself. The installation takes place with standard mechanisms provided by the platform. Eclipse views are used for display of the debugger-specific windows and furthermore, synchronization with the open C/C++ editors is carried out. Display of the UDE windows in Eclipse views enables the user a use of all cross-debugger features, which of course far exceed the standard CDT debugger. The available functions range from configurable periodic refresh of all target memory displaying windows during run-time of the application and the graphical display of application variables, profiling and coverage functions to RTOS support and the display of peripheral registers (SFR) in clear text and trace data analysis. Even the management of several debugger instances for multi‑core debugging is supported without limitations (Figure 4).



For full resolution, click here

 

User's desires to combine tools to any imaginable own workflows confront tool manufacturers with new challenges. The use of standards is essential in order to keep the effort - both for users and tool providers - to reasonable levels. This article shows: Ultimately, it really is not difficult to combine different tools with reasonable effort to custom workflows when suitable fundamental technologies - such as Component Object Model (COM) and .NET Framework - are already taken into account during design of a tool and appropriate interfaces (as in the case of the UDE from pls) are implemented from the start.

Audi

 

NXP

 

National Semiconductor

 

Ethernet

 

Daimler

 

CAN Bus

 

Powertrain

 

Automotive

 

HEV

 

Power

 

BMW

 

Hammerschmidt

 

Ipetronik

 

Security

 

International Rectifier

 

Autosar

 

Fraunhofer

 

Linear Technology

 

Infotainment

 

MOST

 

Infineon

 

Battery

 

FlexRay

 

Bosch

 

QNX

 

E-car

 

RTOS

 

Continental

 

GPS

 

Vector Informatik