The software world is at a new level. The availability of software has increased exponentially within the past 3 decades. This has spawned a need for different skill sets for software engineers for a couple of reasons.
First, as new hardware vendors introduced new hardware platforms and semiconductors, 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, containing startup code, advanced demos, and initialization routines. Then more middleware vendors started supplying software only, and the creation of middleware packages 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 movement. It is now possible to find enough “pieces” of code to create a solid starting point for almost any project.
Second, there is a shift to software integration rather than always writing an application from the ground up. As many in the embedded defense industry know, commercial and government projects often do not “start from scratch.” After money, time, and effort are spent building and debugging a software application, it is often the mandate from management and project leaders that software developers start new projects using software from existing projects already deployed. These projects aren’t reconstructed by starting over, but are essentially “debugged into existence.” This occurs when new parameters – including hardware, new features, a new language, new middleware, 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 operating parameters.
Let’s look at the three key elements of this new coding integration paradigm and examine where modern programming tools fit in:
- Debugging into existence, not debugging for errors
- Maintaining a minimal level of performance before optimizing
- 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 debugging 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 environment with new hardware or a new operating system or RTOS. This integration approach demands a different method of debugging, because it requires a familiarity 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 conversion 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 sample call to a common RTOS application function.
void SampleCreateTask( void* parameters)
This call is passing a pointer to a control block that holds the individual parameters for the task. When switching from one RTOS to another, the programmer must have knowledge not only of how many times this function is called, but they must also have a deep understanding of both task structures in each RTOS. When you extend this knowledge out to all of the components of an RTOS – initialization, tasks, scheduling, mailboxes, queues, and so on – the use of a language conversion tool to automate the transitions makes sense.
Maintaining minimal pre-optimization performance
During the initial development of a software application, much work is put into the optimization and performance. Often times, many hours are spent tweaking the software application to be as small as possible or to run as fast as possible. When updating or integrating projects, the initial goal isn’t to make the application run as fast as possible, but to run at least as fast as the prior version of the application. How is this done? Using hooks inside the code for timing and execution speed, and then also using graphical profiling tools to help indicate the bottlenecks in the new code.
For profiling the application, a programmer can manually insert hooks into the code. This normally includes searching through the application code and inserting appropriate profiling functions on the entry and exit of the function call. When the application consists of thousands of functions and millions of lines of code, this method is overwhelming. When using an advanced profiling tool with the application and an RTOS, there is the ability to automatically insert hooks into the RTOS and application code. The end result is a graphical view of many important timing and performance metrics, including the number of function calls made, time spent inside a function, memory usage, and so on. Figure 1 shows a sample report from a graphical profiling tool used to automate the process.
Elimination of unproductive work
When one of the components in the application is changed – such as an RTOS or hardware component – some work can be automated and some can’t. For instance, using Search and Replace to update function names is error prone and tedious. When changing the programming language, the error-prone work exists when programmers attempt to manually convert one language to another. The controversy comes in because many software developers consider important all the work they do. However, in reality, there are tools that exist that can help automate much of the software work when moving the software application to a new RTOS or new hardware.
For example, consider the C/C++ and Ada languages. Both are very powerful and used in many military software applications. Many existing applications today are integrating both Ada code and C/C++ code. The problems occur when programmers attempt to integrate or translate code by hand. The differences between the two languages are huge, and a simple example can illustrate some of the many differences. Table 1 shows the various operators in C/C++ and Ada. Trying to convert code by hand is an example of unproductive work because there are tools like MapuSoft’s Ada-C/C++ Changer, a language conversion tool that can do this automatically. A programmer’s time is better spent elsewhere on the project. Further, imagine trying to debug the software application if there is a tiny mixup in hand-converted code. It seems better to rely on automated tools for this type of work. The use of an automated tool could condense weeks and months of manual code conversion down to a few hours.
The changing role of programming and tools
The role of the programming has changed dramatically over the past few years. The bulk of the work now is on integration and changing code for new situations, rather than creating new software from the ground up. Thus, engineers must be equipped with a new arsenal of tools, including those that render the ability to debug into existence, maintain minimal pre-optimization application performance levels, and eliminate unproductive manual procedures. MapuSoft Technologies’ conversion tools, including its OS PAL product, help accommodate this change. CS
251-665-0280
www.mapusoft.com