Commonly, embedded developers will start out with no RTOS and begin using one when their design requires it. There are a myriad of reasons why a developer would end up using an RTOS. One big motivation to implement software using multiple threads is that it benefits both the organizational complexity of the code and the way the code can be developed. If threads can be written that are largely independent of one another, this tends to make the end application more modular and less “spaghetti-like”. It also allows the work to be partitioned among multiple people in an easier way. Using a standard set of software services like an RTOS can really help with portability and software life cycle costs. This is particularly true for an RTOS like SYS/BIOS, which runs on a very diverse set of TI devices such as a number of different DSP architectures as well as the ARM9, ARM Cortex M3 and MSP430 microcontrollers. In the previous slide it was discussed how more complex applications can lead to the need for more complex threading models. Simple embedded apps are typically implemented using a super-loop, but this can lead to problems as the application grows. SYS/BIOS offers a very wide set of thread types which will be introduced in forthcoming tutorials, including hardware interrupts, software interrupts and tasks. This allows users quite a bit of flexibility in how they implement their applications. Peripheral devices being used in embedded systems are getting more complex all the time, so the code that drives these peripherals is also getting more complex, including the use of sophisticated DMA and buffering schemes. SYS/BIOS delivers a number of services to aid in implementing device drivers and also an I/O model so that the application can pass data to and from these devices in a standard and uniform way. Finally, SYS/BIOS provides a number of services to help developers debug their application that go above and beyond what they would normally get. This includes methods for applications to throw assertions from within their code, logging in both the application and down in the RTOS so that the developer can see what is happening while the program is executing, and also some real time analysis tools so that the software can stream debugging data to the host, often without even stopping the processor to do so.