This software architecture has been used extensively and quite successfully, but it does have some limitations. There are inherently only two major priority levels to assign processing at, which may pose a major constraint for more sophisticated applications. This can potentially be worked around by disabling different levels of interrupts with the interrupt mask register within the ISR to allow other ISRs to preempt it, but this technique scales very poorly and is fraught with the risk of introducing unintended consequences. It also does not give the developer a very fine grained control of the background thread’s execution. By introducing SYS/BIOS to the system, the developer gets access to a very rich set of system services, including services for threading. This training module will cover the most fundamental parts of threading services, which will open the door for the more sophisticated techniques that are described in other training modules, such as software interrupts, tasks, semaphores, and events. It turns out that an application running on top of the SYS/BIOS schedule will initially look quite similar to the foreground/background implementation. When the application starts executing, it will perform some initialization very similar to before. It will then call the BIOS_start() function to actually start the SYS/BIOS scheduler. Once the BIOS scheduler starts, it will begin executing the highest priority thread that is ready to run. If there is no higher priority thread, then the Idle loop, which always operates at the lowest priority, is the thread that runs. What the Idle loop runs is completely up to the developer, who simply statically configures various functions to execute in an endless loop. Just because the idle loop executes at the lowest priority does not mean that the functions run from there are unimportant. Typical uses for the idle loop include user interface code and built in system tests; it is also especially good for activating low power modes of the device or system since it is assured at that point of not interfering with any fundamental processing. Note that the Idle loop either needs to be invoked explicitly by the application calling the Idle_run() api, or more commonly, by a Task running at priority zero. For more information about this, please view the on-line training module on Tasking. Previously, this module talked about interrupt processing being done in a generic interrupt service routine. But now, instead of running plain interrupt service routines, SYS/BIOS applications run those threads from what is called a BIOS hardware interrupt, or “Hwi”. These Hwi’s will preempt the Idle thread in the same way that a foreground process preempts a background process.