If you ask any embedded software developer whether they would like access to the source code for the real time operating system that they have selected, the answer would almost certainly be yes. Likewise for any other software IP. This article investigates whether this is a sensible answer in all cases and looks at when and why source code is needed and why sometimes it may be less useful than anticipated.
Why source code?
There are a number of key criteria that engineers apply when selecting a real time operating system (RTOS). Many of them – cost, functionality, licensing, support – make a lot of sense. However, another one – availability of source code – may be less logical, but is always rated as a strong factor.
Source code being available does not mean that it is supplied automatically and free of charge. This may be the case with some commercial products, and, of course, open source products intrinsically include source code. However, other vendors may choose to charge for source code or not make it available at all.
The reasons for wanting source code need to be examined in some detail so its suitability as a selection criterion may be assessed.
The Hardware example. There are many similarities between the way hardware developers operate and how software development is performed. This is particularly true in an age when most electronic design is done using high-level design languages (HDL), like VHDL and Verlog. So, where do they stand on source code?
Historically, a hardware engineer would have selected an integrated circuit to incorporate into their design. That selection would have been based on the data sheet, which specified functionality, pin-out, power requirements, etc. There would have been no expectation that a complete circuit diagram for the IC would be provided.
An engineer today who is developing an ASIC or deploying an FPGA is likely to employ some licensed intellectual property (IP) – a pre-packaged functional unit that provides a specified set of capabilities. Once again, the selection would be based on the data sheet with no expectation that the original HDL for the IP would be supplied. The approach of using “black boxes” is well established in the world of hardware design.
Security. Any technology that is incorporated into a product needs to be selected with future supply and support possibilities in mind. Again, hardware designers have a clear view: sourcing ICs from single suppliers is avoided whenever possible, as multiple sources mitigate against an interruption in supply.
The issue is different when using IP, whether hardware IP or software IP (like an RTOS). Ongoing supply is not a concern, but continuing support must be considered. Clearly, diligent assessment of the vendor is necessary. Are they going to continue to support the IP? Indeed, are they likely to be still in business throughout the lifetime of your product?
If the source code for the IP is available, this gives the possibility of addressing any problems with the software even if the vendor is no longer able to offer support. For this reason, many purchasers of RTOSes, etc., like to have the source code on the shelf, even if they never look at it, “just in case”.
Software configuration. A key difference between embedded systems and desktop computers is variability. Most PCs are similar to numerous others: Windows, Mac, or Linux. Embedded systems, on the other hand, are incredibly variable – different CPUs, memory configurations, and peripherals. As a result, software IP needs to be flexible so that it may be deployed on as many different systems as possible. Although many products like RTOSes are supplied in binary form – typically a library that is linked with the application code – it can be challenging for a vendor to maintain and support numerous variations.
Supplying the IP in source form addresses many of these issues. The user can build the code for the specific CPU, link for the memory map of the device, and add in custom device drivers, as necessary. In some cases, the IP is configured by conditional compilation – typically a header file is edited to define the configuration.
Certification. For some types of applications, such asmilitary/aeronautical and medical, embedded software needs to be certified for safety against various recognized standards. This process is complex and expensive and normally entails inspection of every line of code. Therefore it is not normally possible to purchase “pre-certified” software IP, as it is the entire application that is subject to scrutiny. So, a developer of a safety critical application is most likely to seek IP that is available with source code so that the complete inspection may be performed.
What is Source Code?
It may seem an odd question to ask, but, after all this discussion about why you might or might not want/need source code, it would be good to identify what is actually meant by the term.
The answer may seem to be obvious: the source code for some software is a set of files containing the high level or assembly language instructions that can be compiled/assembled to produce the functioning binary instructions. That is all true, but not complete. I can think of at least three forms in which “source code” may be delivered (I am just assuming C language for this explanation):
- Lines of C code that will compile successfully, with no comments or particularly meaningful identifier names.
- C code which is “scrambled” to make it unreadable by humans, but still acceptable to a compiler. This is done by using totally meaningless identifier names and removing all comments and syntactically unnecessary whitespace.
- Well commented C code, with good layout and clear identifier naming conventions.
All of these forms are used by suppliers of software IP.
- #1 is typically used when a vendor want to deliver the bare minimum, which may be (just) good enough for certification.
- #2 has been used to protect the IP from prying eyes. It means that the software gains the configurability advantages of source code, but nothing else.
- #3 is what most purchasers expect to obtain and what many vendors do, indeed, provide. However, when making a purchasing decision, if you do require the source code, it is essential to ensure that this is the form of source code that the vendor will deliver. If in doubt, just ask to see some.
Source code disadvantages
There is a big disadvantage to having source code readily available: it leads to temptation. Every developer wants to make their software as good as possible. So, for example, if an RTOS API does not work in exactly the way that would be optimal for an application, the availability of the source code provides the opportunity to change it.
Although this might appear to make the application optimal, there is a long term support issue thereafter. What if there is a problem with the RTOS functionality? The vendor will not be prepared to support a modified product. What if a new version of the RTOS is released? Incorporating it into the design might require considerable time spent re-doing the modifications, which may need a complete redesign for the new release.
Having looked at all the situations in which source code might be desirable, useful, or essential, it must be stressed that it is not required in all situations. If you are purchasing from a trusted, well-established vendor who can offer long term support, the availability of source code is not relevant and may even be a distraction.
Colin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with the Mentor Graphics Embedded Software Division and is based in the UK. His regular blog is located here . He may be reached by email at .