Software
It's all about the tools
Next-generation programming tools come of age By Kumaravel Pandurangan
The landscape of software development is changing. It’s no longer just creating new software from the ground up. In today’s programming environment, engineers are often taking an existing software application and updating it with new features and functionality. However, there’s a catch. These new features are being added along with the addition of new application requirements such as updated hardware, a new programming language, or a new operating system or RTOS. This method of updating software is beneficial in that it’s allowed for applications to advance at an accelerated pace. However, the arsenal of tools needed by software engineers on today’s projects is much different from what was required in the past.
The software world is at a new level. The availability of softw are has increased exponentially within the past 3 decades. This has spawned a need for dif ferent skill sets for software engineers for a cou- ple of reasons.
First, as new hardware vendors introduced new hardware platforms and semiconduc- tors, they often provided software as demo code to show off the various capabilities of the hardware. Over time, this demo code evolved and became more complex, con- taining startup code, advanced demos, and initialization routines. Then more middle- ware vendors started supplying softw are only, and the creation of middleware pack- ages and library code was introduced. Of course, the Web helped to make much of this code available to almost anyone. This availability and sharing gained mainstream traction through the open source mo ve- ment. It is now possible to f ind enough “pieces” of code to create a solid starting point for almost any project.
Second, there is a shift to softw are inte- gration rather than al ways writing an application from the ground up. As many in the embedded defense industry know, commercial and go vernment projects often do not “start from scratch.” After money, time, and effort are spent build- ing and debugging a software application, it is often the mandate from management and project leaders that software develop- ers start new projects using software from existing projects already deployed. These projects aren’t reconstructed by start- ing over, but are essentially “deb ugged into existence.” This occurs when ne w parameters – including hardw are, new features, a new language, new middle- ware, or a new RTOS – are introduced to an existing, working code base. The team is required to take the existing code and make it run using the newly defined oper- ating parameters.
12 VME and Critical Systems / Spring 2011
Let’s look at the three k ey elements of this new coding integration paradigm and examine where modern programming tools fit in:
1. Debugging into existence, not debugging for errors
2. Maintaining a minimal level of performance before optimizing 3. Eliminating unproductive work
Debugging into existence Compare “debugging into existence” to “debugging for errors.” When first writing a software application, programmers spend a certain amount of time deb ugging the program, while checking for operational issues and functionality that comply with the original written specifications. When integrating software, they are debugging to
make the application run in the new envi- ronment with new hardware or a new oper- ating system or R TOS. This integration approach demands a different method of debugging, because it requires a familiar- ity with all the new components. This is a problem because all that learning adds a lot more time to the development schedule. In this situation, the use of language con ver- sion or porting tools to handle some of the code transition can save weeks, months, or even years.
Let’s look at a simple example of task creation in an application. Here is a sam- ple call to a common RTOS application function.
void SampleCreateTask( void* parameters)
Figure 1 | A graphical view generated from a graphical profiling tool, showing the number of times functions have been called
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32