Paul Parkinson

Ada & C mixed language development

Last week, I downloaded AdaCore's GNAT Pro 6.2.2 and the latest GNATbench 2.3.1 release (which was announced yesterday), as I wanted to port an Ada & C mixed-language application to VxWorks 6.7.

I wanted to do this to show a customer how they can develop new Ada applications (as well as reusing existing intellectual property) and integrate them with network protocol stacks, graphics libraries and other middleware which are often implemented in C or C++.

Whilst the Ada 95 and Ada 2005 language standards provide inter-language compatibility with C and C++ respectively, close integration between the development tools is needed in order to really exploit these capabilities fully, for example being able to debug communication modules and/or tasks implemented in different languages.

My mixed language application consists of two VxWorks tasks (written in C), and two Ada tasks. One of the VxWorks tasks sends messages to an Ada task via a VxWorks message queue, and I wanted to step through the sending and receiving of the messages in a debugger to confirm that individual messages were sent and received correctly. This would not be a very user-friendly activity if I had to use two different debuggers to debug the Ada and C code separately. In addition, I also wanted to check that the inter-language calls that I had made (C function calling an Ada procedure and vice versa) had passed parameters using the correct language types and the data values were interpreted correctly.

Workbench provides an open and extensible framework based on Eclipse, so this has enabled AdaCore to integrate capabilities of GNAT Pro seamlessly through the GNATbench plugin. This enabled me to develop and run my mixed language application in Workbench. I was able concurrently debug multiple tasks in mixed languages (see below), and set task specific breakpoints on the Ada and C tasks individually and step over the calls to msgQSend() and msgQReceive() respectively, and confirm that the messages were passed correctly; and I was able to walk up and down the stackframes in the Workbench Debug View and confirm that parameters had been passed correctly between C function and Ada procedure and vice versa.

I also used Workbench's analysis tools System Viewer, Memory Analyser and Performance Profiler to verify the behaviour of Ada & C tasks at system level, and monitor memory & CPU utilisation of each of the Ada procedures and C functions in the mixed language application.

Even after many years working with these technologies, I am still excited by advances in capabilities which make the complex tasks of embedded software development easier. I just wish I was able to spend more time in Workbench and less time in PowerPoint!

Rhapsody && Coverage Analysis

I've recently been working with a customer to integrate Wind River Coverage Analysis (formerly known as CoverageScope) with Telelogic Rhapsody within their development tools framework for a mission-critical system.

At first glance, it might seem strange to integrate a code coverage testing tool with a UML design tool, as these aren't even adjacent phases in the software development life cycle (implementation being between them). However, the advent of Eclipse in recent years has helped to break down the silos which used to confine tools individual development life cycle stages and improved development work flow.

The integration enables an application to autocode-generated from Rhapsody and built with Coverage Analysis instrumentation and downloaded and run on the target processor, with coverage results being continuously streamed back to the host and displayed in the Coverage Analysis GUI. This provides immediate feedback of of the level of coverage, and the coverage trend against time (useful for confirming if the test suite tests more and more code over time, or whether it is testing the same code over and over again).

The aspect of the integration which left the biggest impression on me though, was how it enabled the customer to confirm that the right code is executed in response to an event being injected at the UML model level. This is an important aspect of system testing, and it is often difficult to demonstrate the traceability from design to implementation. This was achieved by building the application with both Rhapsody animation and Coverage Analysis instrumentation, and then run or animated on VxWorks with events being injected from Rhapsody and the executed code was shown in Coverage Analysis.

If you're interested in seeing this for yourself, the integration steps are now documented in AppNote-344 on Wind River Online Support website (login required).

Eclipse - Babel fish for engineers?

In the recent blog More Eclipse News, Alex Wilson commented on how Eclipse is becoming increasingly pervasive throughout the software development life cycle.

Alex mentioned that the seamless integration of these tools through Eclipse makes life easier for developers (which I interpreted as: single user interface (UI), consistent look & feel, improved productivity, etc., etc.), but I believe that there's also another important benefit which is perhaps less obvious.

Last year, I had the privilege of attending the Wind River Worldwide User Conference to present two papers, but I also took the opportunity to attend lots of track sessions as well. One of the presentations which really sticks in my memory, was given by Telelogic on the integration between the Rhapsody Model Driven Development (MDD) environment and Wind River Workbench. Telelogic showed the development of a UML (wikipedia) model design in Rhapsody, then performed auto code generation into an Eclipse C project, which was imported into Workbench and was compiled for a VxWorks target.

So what? That's a one way export from design to code, which has been done before...except that the demonstration didn't stop there...

Next, the UML model was executed on a target processor running VxWorks, and when the model was halted within the UML environment, Workbench halted the application at the appropriate line in the source code; and when the application ran to a specified line in the source code under Workbench control, the model was animated correspondingly in the Rhapsody.

I was impressed because this integration because it showed synchronised views of the design and implementation of the system concurrently.

It struck me that this would enable systems engineers and software engineers to observe and discuss a system from their own and their counterpart's frame of reference; and whilst we don't quite speak completely different languages, in the past I've thought that a Babel fish (wikipedia) would be useful at times.