Site search Advanced


Workflows combined on the basis of the modular design principle

Published: 12 January 2016 - Lisa Peake

In order to continue to be able to reasonably efficiently test and debug complex embedded systems in future, it is essential that the development tools of different vendors can be easily combined to a specific workflow

Heiko Riessland, Product Marketing Manager, PLS Programmierbare Logik & Systeme

Since the beginning of electronic data processing, it is already well understood, that it is beneficial when the results of different programs can be combined to obtain an overall result. 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. However, in those days, operating system, shell and programs all still originated from one and the same manufacturer, which naturally greatly simplified the standardization of outputs.

Today, in the age of graphical user interfaces and numerous vendors of different tools, the manufacturers of development tools see themselves confronted with far greater challenges. This quickly becomes clear as can be seen from the example of cross-development tools for Windows hosts.

Cross-tools run on a different hardware platform than the actual target application. Most cross-compiler packets generate data in ELF/DWARF format, which contains both the machine code for the target application as well as information for debugging. ELF/DWARF format is largely standardized so that the working together of compilers and debuggers/emulators of different manufacturers is generally not a problem. In addition, XML is also being used increasingly often for the structured storage of data. Since 2008, with the Universal Debug Engine (UDE), a cross-debugger for 16/32-bit microcontrollers of various manufacturers, all data is stored in XML format. 

In practice, active solutions, with which tools can be combined together directly to a continuous workflow, are much more interesting than the possibilities provided so far. This can be carried out either by the participating manufacturers or even by the users themselves. Coupling carried out by the users themselves typically requires a high degree of standardization, documentation and, if necessary, training. In turn, such solutions are characterized by a wide range of applications and flexibility. The tools can directly interact or work together via a program controlling the overall process.

Component Object Model (COM) ? sometimes also referred to as ActiveX, is an interesting interface basis for this. COM does not have anything in common with the serial interfaces (COM1), which are disappearing from modern PCs, but rather allows programmatic utilization via C/C++ and other programming languages. In particular, COM opens up for tools the wide field of script languages, which run in Windows Scripting Host (WSH), and allow the control of COM components. JavaScript, Phyton, Perl, Visual Basic Script or Windows Power Shell are just a few examples of this. Users can thus create their own workflows with relatively little prior training effort. 

A concrete example of coupling on the basis of COM interfaces performed by the manufacturer is the combination of LieberLieber Software’s UML Debugger and PLS’ Universal Debug Engine (UDE). Both tools have an object model and provide each other with functionality. Users can debug on the Unified Modeling Language (UML) model level, in other words, execute single steps, set breakpoints, start/stop the target program and view the variables. Control of the target is carried out in the background by the UDE. 

To conclude, in order to be able to combine tools to almost any own workflows, developers of complex embedded systems will in future be more reliant than ever on standardized approaches to solutions such as the Component Object Model (COM), which offers a user-friendly basis technology for Windows platform, .NET Framework and thus modern programming and scripting languages. But the important thing is that appropriate interfaces, as was the case with the Universal Debug Engine (UDE), are already taken into consideration during the design of a tool. Only then can various types of combinability of tools also easily and without much additional effort be covered later.

Source: Electronics

Search for a product/supplier:
-December 2020+