Hardware Reference
In-Depth Information
You would have noticed by now how slow this version of Android is. Recall that all graphics rendering is now
done in software. This means more CPU cycles used on a very limited machine. There is not much more you can
really do with the Android operating system on the Raspberry Pi. Without an officially supported image with full
GPU support, Android is not usable. It is unfortunate that the operating system that first pops into everyone's head
when you say ARM is the one that works the least. Not to worry: this chapter will be filled with other very interesting
operating systems that do work better.
RISC OS
You could not have a chapter on other operating systems for an ARM system without talking about RISC OS. What
has RISC OS got to do with ARM? Read on to find out.
A History of RISC OS
RISC OS was originally created by Acorn Computers back in 1987 and takes its name from the type of architecture that
the operating system was designed to run on. That architecture was RISC (Reduced Instruction Set Computing) and
that is exactly what the ARM is. RISC OS was developed to run on the very first ARM CPUs developed for the Acorn
line of computers. Over many years RISC OS has become somewhat less important and as such it has suffered in the
amount of machines you can run it on, emulators excluded. It's now nice to know that RISC OS has been ported to run
on your Raspberry Pi and is provided at no extra cost. It would seem only fitting after all for a computer that makes
reference to the BBC Micro to be running RISC OS at least once.
RISC OS Considerations
It's a good idea to talk about the key features or differences of RISC OS before you jump into installing it. The first
thing you may want to know is that RISC OS, unlike Linux, is a single-user operating system. A single-user operating
system is an operating system that only one user can use at any one point, unlike Linux where you can have more than
one user logged into the system, say, via SSH or even via a physical terminal. This makes RISC OS less than ideal for
a headless terminal.
One of the most interesting parts of RISC OS is the way it achieves its multitasking. Most operating systems that
you will have come in contact with (including Linux) multitask very differently from RISC OS. They use a system called
preemptive multitasking, or PMT for short. Under PMT the operating system calculates a time slice for each running
process. This time slice may be calculated from a hardware timer or another timing source. When a process enters the
running state the operating system starts counting how long it has been running. At this point two things can happen:
either the process will finish executing by itself or the operating system pauses the process after a fixed period and lets
another process run for its allocated slice. This ensures that all processes get an equal chance to be in a running state
on an active CPU. The downside is that no one process can sit in a running state until it's finished. For most users this
would not be an issue but for anyone with a latency-sensitive application this can be a problem. So, for example, a
place where PMT falls down is aircraft controls. Sometimes you must have a certain process run regardless of current
running processes: after all you don't want the autopilot being interrupted by a nonimportant running service.
RISC OS uses a very different system called cooperative multitasking, or CMT. Unlike PMT, CMT is controlled by
the processes themselves. In a CMT environment each process should regularly talk to the operating system. When
it talks to the operating system a process will indicate if it needs to gain more time on the active CPU or if it can yield
time on the active CPU to another process. The reason why it's called cooperative is that each process should inform
the operating system as soon as it can about its state and all processes cooperate to ensure that no one process hogs
time on the active CPU. Unfortunately this aspect of CMT is also its downfall. If you have one process that spends too
much time on the active CPU, every other process will fail to respond in a timely manner, effectively locking up your
entire system. Now if you can't control that process your operating system will eventually crash. On the other hand
if you are in total control of that application you may want it to have full access on the CPU and run until completed,
