We wrote this OS and created the SD/MMC card reader as a final project for Cornell's ECE 476 class taught by Professor Bruce Land. Our reason for choosing this particular project is that we were unable to find any OS for the Mega32 that doesn't have to be statically compiled in with a user program. In contrast, kaOS waits for a card to be inserted and a reset button to be pressed, at which point a program is loaded from the card and executed. At any time, a new card with a new program can be inserted and run. Executing a new program doesn't require reprogramming the Atmel processor.
The card reader is accessed via the Atmel's SPI interface by the program loader, which places the program into flash memory. These programs can be written similar to a standard Atmel Mega32 program, except that it must include the kaos.h header file, which provides an interface to the threading and messaging calls to the OS. The program loader resides in the Mega32's bootloader section of flash. This gives it write access to other portions of flash memory so that it can write executables to program space. Once kaOS loads a program, it creates a thread for it and jumps to its main() method.
The operating system is real-time, multithreaded, and preemptive. It supports creation of up to 8 threads, which can be prioritized. Threads with the same priority are alternately preempted to give both equal processing time. kaOS also supports messaging between threads as a means of inter-thread communication.
While the idea for this project was born out of the lack of a true OS for the Mega32 that dynamically loads programs, we must give some credit to aOS, created by Anssi Ylätalo. In particular, we used his context-switching code to swap processor states when changing threads. Also, portions of our code used to read from SD/MMC cards were adapted from code written by Radig Ulrich. Additional information about SD card communication and the SPI protocol were obtained from SanDisk's SD card manual.
In designing the operating system, we considered various library functions that we could add to increase functionality, such as LCD and keypad drivers, events, and support for multiple programs on a single card with a menu system to choose between them. These features, although useful bells and whistles, were cut from the design because they were extraneous to our core vision of creating a dynamically-loading OS, added unnecessary complexity, and consumed extra flash and RAM, which might be needed for some user programs.