kaOS operating system and loader using atmega32

Introduction

We have created a real-time, multithreaded, preemptive operating system called kaOS for the Atmel Mega32 microcontroller, which loads and executes programs from a Secure Digital or MMC card.
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.

About Us

We are two engineering students at Cornell University taking ECE 476: Designing with Microcontrollers (Spring 2005). Both of us are graduating in May and beginning work for Microsoft in August. Nick Clark is an Electrical and Computer Engineering major and Adam Liechty is a Computer Science major.

High Level Design

The design of kaOS was broken up into two major components: the operating system itself and the card reader and program loader.
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.
kaOS operating system and loader
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 Yltalo. 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.

Hardware Design

We ran kaOS on an Atmel Mega32 on an STK500 development board, which are available in the lab. In addition, we built a circuit to connect to the SD/MMC card. We connected it to the STK500 with a 10-pin jumper cable to PORTB, which contains the Mega32’s SPI interface. We wired the SD card connector’s clock, DataIn, and ChipSelect pins to PORTB’s pins 7, 5, and 0, respectively, and the DataOut to PORTB pin 6.
The three inputs to the card were each fed through separate step-down circuits to decrease the voltage from the power supply’s 5V to the 3.3V required by the card. Likewise, the output from the card was fed through a step-up circuit before going to B.6. The designs of these step-down and step-up circuits were taken from the final project by Peter D’Antonio and Daniel Riiff. To obtain the 3.3 volts needed for the HIGH voltage for the card, we used a simple voltage regulator. We employed the voltage regulator after we found voltage dividers by themselves to be worthless, since the card acts as a load on the 3.3V, drawing some current. With the voltage dividers, the 3.3V was pulled down to 2.6V with the card’s load. Our regulator, however, was able to sustain a voltage of about 3.26V with the card’s load, which is well within the card’s specifications.
We had 3 unused pins on PORTB after connecting to the card reader, so we added a pushbutton with a pull-up resistor and connected it to pin 1. This button is used as a reset, which causes the OS to load the program from an SD/MMC card, if one is inserted, and run it.
The SD connector we used included an ejector, which makes inserting and removing cards easy. Pushing the card into the slot clicks it into place. Pushing it again ejects it with a spring.

For more detail: Keyboard mania


About The Author

Ibrar Ayyub

I am an experienced technical writer holding a Master's degree in computer science from BZU Multan, Pakistan University. With a background spanning various industries, particularly in home automation and engineering, I have honed my skills in crafting clear and concise content. Proficient in leveraging infographics and diagrams, I strive to simplify complex concepts for readers. My strength lies in thorough research and presenting information in a structured and logical format.

Follow Us:
LinkedinTwitter

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top