---

Introduction to cubeos

Features of CubeOS

1. CubeOS is a small operating system. CubeOS consists of about 30 kBytes of binary code.
2. CubeOS is an embedded operating system. It has been designed for a specific purpose, robotics. CubeOS also contains drivers for it's hardware counterpart, the RoboCube.
3. CubeOS is a realtime operating system, it contains functions that deal with time and with the timed execution of code. The RoboCube hardware also contains special functions that deal with time, the TPU.
4. CubeOS is a modular operating system. It is split into components that can be assembled almost independently and form an application specific OS core.

The API of CubeOS is split into several components. First, there's the nanocore. Its functions include low-level process handling, basic i/o prototypes, timer and debugging support. Next are the the communication, bus and network drivers which make use of the core functions.

The nanocore provides the following functions

1. hardware-dependent functions:
   1. interrupt control
   2. context switches
   3. exception processing
   4. trap handlers
2. multi-threading:
   1. scheduler
   2. create() new threads %
   3. inter-thread communication (signals, message passing)
   4. thread control (suspend, resume, kill) via signals
   5. stack management
3. interrupt management:
   1. installing interrupt handlers
   2. interrupt mask handling %
   3. delivery of interrupts to core processes via signals
4. basic data structures:
   1. iobuf data-type
   2. list data-type

The communication-, bus- and network driver system provides low-level drivers for the different communication, bus and network controllers that can be used with the RoboCube.

1. I2C driver
2. serial communication driver
3. TPU driver
4. spi driver
5. radio-link network protocol

programming with CubeOS

Programming takes place on a external host system. Running a program involves several steps including cross-compilation, linking with the CubeOS components and the Cygnus newlib libc and converting the code into the appropriate format that can be downloaded into the target, i.e. the RoboCube.

To execute these tasks, a Makefile is present in the user directory of the source tree.

the nanokernel

The nanokernel provides a simplified interface for the programmer to run arbitrary programs on the RoboCube and provides basic multi-threading structures and functions. The cube's multi-threading can be used in a preemptive and cooperative way by either calling the scheduler by an interrupt service routine connected to the clock timer interrupt or by calling it directly from the current user task. Atomic operations can be guaranteed by disabling all interrupts by two user-accessible macros, disable() and enable(). Moreover, the kernel provides more elaborate functionality like mutexes and counting semaphores to handle process concurrency. Threads can communicate via shared memory (which is trivial since all threads share a common address space), signals and messages. Furthermore, the core provides access to the system's console communication port. Additionally, a facility to catch exceptions has been introduced into the core which detects exceptions and reports them to the user.

To form a minimal running system, the nanocore needs at least one serial communication driver to be attached to the console communication port.

design philosophy

The nanokernel of CubeOS has been designed with several properties in mind:

1. Memory management is not supported by hardware. Consequently, it only makes things more complicated to introduce memory segments artificially even if their propper use cannot be enforced. So, there is no distinction between ''user'' and ''system'' processes, all processes run in the CPU's supervisor mode. Hardware access is granted either implicitly (There is only one driver for each of the \iic busmasters, and nothing else has to touch the control registers.) or explicitly by the use of semaphores/mutexes.
2. Since all processes run in the same memory segment, they're actually more like threads than like processes. Hovever, the code uses the name ''process'' to designate one concurrent execution thread of a program.
3. Since there is no dynamic load facility and no {\tt exec()} like function call, there is only one program running at a time. As a C program, it only has one namespace for global variables and functions. Care must be taken to avoid naming collisions between the operating system core and the user program.
4. There are few tasks. An embedded system is not a unix server with several hundred web-server processes being spawned every second.
5. Task live long. Usually, a task has one specific purpose, is created upon system initialisation and runs as long as the system is active.
6. CubeOS is intendet as a component-based system in which the kernel provides basic support for all other components. As soon as one kernel function is not mandatory for all systems, it is put into its own component and is only bound when used.

Therefore, the kernel contains a static process table with a fixed number of entries.

---