RTOS deployment

Since the earliest days of computers, they have been used for real time control applications. In the 1960s and early ‘70s, it was common to use a small mainframe or a mini-computer to control machinery or instrumentation. These computers typically ran under the control of a specialized operating system, which was designed for real time use. Examples include RSX-11 and RT-11, which were used on DEC PDP-11 machines.

These “real time operating systems” were typically interactive and worked similarly to those used for data processing applications. An operator command would start, control and stop the real time application programs. They could also be configured to be “turn key”, so that switching on the computer would cause the OS to be booted, which would then start the applications automatically. With the advent of microprocessors and, hence, embedded systems, a new approach was needed …

Although early embedded systems were quite simple and did not have any need for an operating system [or, indeed, have any memory to spare to accommodate one], by the late 1980s 16- and 32-bit devices were beginning to be employed for quite complex applications. Many developers created their own multi-tasking kernels and the first commercial RTOS products began to appear. Possibly the first was VRTX from Hunter and Ready [later Ready systems, which was acquired by Microtec Research, which, in turn, was acquired by Mentor Graphics].

Early commercial RTOS products were commonly supplied as PROM chips, pre-programmed with the code. They were almost viewed as components like the other electronic parts. The kernel was written in position independent code, enabling the user to place the image at any convenient location in the microprocessor’s address space. The RTOS API used a “trap” mechanism [instead of subroutine calls], so the user just needed establish the trap vector to link to the PROM address. The PROMs contained the entire, “monolithic” RTOS image, but, as the range of facilities was rather limited, a user was quite likely to be using all the functionality, so this approach was not wasteful [i.e. there was no unused, redundant code].

As RTOS products became more sophisticated and flexible, the monolithic image approach became less manageable and an alternative was needed. This resulted in the invention of the scalable RTOS. Although scalability may be implemented in a variety of ways, it was most commonly achieved by supplying the RTOS as a small module of code [the scheduler etc.] and a library of functions that implement the API calls. Thus, the only functions, which are incorporated in the final image, are those actually used by the application. Now, the user deployed the RTOS by simply linking the library etc. in with their application code to create a single memory image.

This approach has served embedded developers well over the last couple of decades, and continues to do so. However, in recent years, as complexity of systems has increased exponentially, new challenges with RTOS deployment have arisen, which mean that the “bring up” time has stretched from a few hours to days or even weeks. An approach to addressing this problem comes from vendors having a clear understanding of what users are trying to achieve and the type of applications they are attempting to implement.

Most RTOS vendors now offer a smart installation package for the software, which is a combination of software IP [kernel and middleware components], configuration tools and application code. As long as the latest device drivers are available, this approach can enable an OS to be completely configured for a new hardware platform in minutes or a few hours, instead of days.

This entry was posted on Tuesday, March 15th, 2016 at 4:02 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.