Approaches to Reducing the Embedded Software Development Effort

Its quite a complicated matter to assess the effects of diverse aspects of embedded software development project in cutting the entire investment of time and staff during the project. Therefore, its almost impossible to exactly respond the question “How to save 30 per cent of efforts for embedded software development?” Still, in this survey we will introduce a number of aspects of embedded software development project which en bulk may substantially decrease its development effort by approximately 10 to 50 per cent.

Decrease the amount of Software to be developed. Its a generic approach to decrease software development effort – to develop only the needed amount of software components. First of all, avoid “requirements creep” as it tends to add increasingly more must-have functionalities to embedded software in the course of development, leading to excessive expenses, even more than was originally planned.

Another way to develop the least software, is to purchase “off-the-shelf” products for some components of embedded software system, instead of writing all the software from the ground up. Whereas the repeated utilization of existing software does not cut development efforts to zero, it is indeed more effective than writing new code with features similar to what others have already developed, debugged and field-tested.

Accelerating the Learning Curve for an RTOS

As the decision is made to use an RTOS, a development team must learn the RTOS and the way it works. It5s one of the causes that re-use of conventional software like RTOS is not infinitely efficient. For a usual up to date RTOS, it may take several months before software engineers master the RTOS.

This all is because of the vast number of operating system abstractions and options to learn, and the trade-offs among them. For example, lots of RTOSs have a diversity of inter-task communication and synchronization procedures including message queues, pipes, event flags etc. A software engineer must learn and understand all these aspects, compare its strong and weal suits, before he learns to use RTOS optimally. So, the lasting learning is conditioned by the variety of choices. However, the learning time can be substantially reduced by avoiding some of these abstractions and options from consideration in the embedded software design. This can be attained by ruling out some RTOS features from consideration, or through selecting an RTOS with a simpler, easier-to-understand set of features.

Circa 90 to 95 per cent of all RTOS service requests will be restricted to several services, thus resulting in a simple and easy-to-learn API to the RTOS.

Transparent Interprocessor Communication

Next, the efficiency of development can be gained if to use the same RTOS API for both inter-task communication between tasks within a single processor and also inter-task communication between tasks running on separate processors.

Some real-time operating systems provide “off-the-shelf” RTOS component “link handler” that is used exactly for this purpose. Link handlers enable to use the same simple asynchronous message-passing API for both inter-task communication between tasks within a single processor, and also inter-task communication between tasks running on separate processors. These link handlers available for different processor architectures from high-end communication processors through smaller microcontrollers and digital signal processors.

Optimized Debugging Support

Another supplementary key factor in the process of efficient software development is debugging support. Multitasking software is well known for its non-reproducible bugs, often caused by deficient design of shared memory or unprotected sensitive section of code. RTOSs offer facilities to eliminate these bugs, but it is often complicated to determine if the RTOS is used correctly and if it will eliminate such problems.

There exist special RTOS-aware debuggers which can provide this kind of insight. But, the bulk of RTOS-aware debuggers must distribute their services thinly over a wide variety of inter-task communication and synchronization mechanisms as well as other RTOS services. This is yet another reason to opt for RTOS designed specifically to offer a simpler, easier-to-understand set of features. RTOS-aware debuggers for RTOS can provide greater concentration and go deeper in exploring application software’s usage of its simpler API.

Bottom line

The above does not give an exact answer to the question “How to save 30 per cent of efforts for embedded software development?”, but here were given some aspects of embedded software development that aggregated may significantly reduce its development effort. To summarize the above, it can be named – do it all smart, easy and simple.