EMBEDDED OS

PROJECT REPORT

Submitted By-
Ashish Singhal
Kumar Ankit
Siddharth Singhal
DELHI COLLEGE OF ENGINEERING
 ACKNOWLEDGEMENT

We extend our sincere thanks to Dr. Ravi Mehrotra and Mr. Ashish Ranjan for their
able guidance and support throughout the project without which we could not have
reached so far.
 PROBLEM STATEMENT
This project requires researching various embedded OSes that can be deployed on
ATMEL AVR series of microcontrollers. Some examples are: TinyOS, KaOS,
microLinux etc. It involves more of researching and deploying rather than delving into
core intricacies of OS.
 VARIOUS TASKS
Task 1:
Prepare a comparison chart of all the comparative small OSes capable of running
on microprocessor on the basis of at least the following parameters:
1.1.ATMEL support
1.2.Memory or any other minimal hardware requirements
1.3.License - no hinderance for commercial plans?
1.4.Maturity of:
Documentation
Mailing list/Support
Programming Model
Other Features list such as concurrency etc
1.5.End Result of Task: Report submission

Task 2:
Embedding the selected OS in ATMEL
2.1.OS on simulator
2.2.Running Simple Programs in nesC
2.3.Using OS- IDE Programming Environment for nesC (plugin for nesC in
Eclipse)
2.4.Running OS on ATMEL
2.5.Running custom programs
2.6.Serial communication
Task3:
Peripheral devices
3.1. ADC etc with OS
DETAILED DESCRIPTION OF THE
VARIOUS OSes STUDIES
 FreeRTOS

Introduction
FreeRTOS is a small and portable real-time operating system. It is an open source project
that was started up by Richard Barry. Compared to other embedded operating systems
such as µClinux and even PC-XINU, FreeRTOS™ is quite simple, providing only the
basic kernel features.
Due to its simplicity, size and extensibility, FreeRTOS™ is a suitable candidate operating
system for embedded applications on a wide range of hardware platforms. FreeRTOS™
has been ported to a number of such platforms like PIC18, AVR and ARM7 etc.
microprocessors.
FreeRTOS is supplied as source code. The source code should be included in your
application project. Doing so makes the public API interface available to your application
source code.

Atmel Support
The FreeRTOS real time kernel has been ported to a number of different microcontroller
architectures including AVR. The Atmel AVR port was chosen for due to:

• The simplicity of the AVR architecture.

• The free availability of the utilized WinAVR (GCC) development tools.
• the low cost of the STK500 prototyping board

Memory Requirements
RAM Requirement

This depends on your application. Below is a guide based on:

• IAR STR71x ARM7 port.

• Full optimization.
• All components other than co-routines and trace compiled in.
• Four priorities.

Item Bytes Used

236 bytes (can easily be reduced by using smaller data
Scheduler Itself
types).
For each queue you create,
76 bytes + queue storage area
add
For each task you create, 64 bytes (includes 4 characters for the task name) + the task
add stack size.

Note these figures are much lower for 8 and 16 bit architectures!

ROM Requirement

This depends on your compiler and architecture.

The kernel itself required under 4KBytes of ROM space when using IAR STR71x ARM7
platform.

IDE
WinAVR development tools - WinAVR is a free Windows to AVR cross compiler based
on GCC.

License Details
FreeRTOS is licensed under a modified GPL and can be used in commercial applications
under this license.

License feature comparison

Modified GPL Commercial

license license
Is it free? Yes No
Can I use it in a commercial application? Yes Yes
Is it royalty free? Yes Yes
Do I have to open source my application code? No No
Do I have to open source my changes to the kernel? Yes No
Do I have to document that my product uses
Yes No
FreeRTOS.org?
Do I have to offer to provide the FreeRTOS.org Yes No
code to users of my application?
Can I receive support on a commercial basis? No Yes

As a special exception, the copyright holder of FreeRTOS gives you permission to link
FreeRTOS with independent modules that communicate with FreeRTOS solely through
the FreeRTOS API interface, regardless of the license terms of these independent
modules, and to copy and distribute the resulting combined work under terms of your
choice, provided that

1. Every copy of the combined work is accompanied by a written statement that

details to the recipient the version of FreeRTOS used and an offer by you to
provide the FreeRTOS source code should the recipient request it.
2. The combined work is not itself an RTOS, scheduler, kernel or related product.
3. The combined work is not itself a library intended for linking into other software
applications.

Documentation
You can purchase an exact copy of this entire WEB site as a single Windows help file
(.chm file) - a convenient way of viewing all the documentation on your local computer.
Cost of this documentation is $35

FreeRTOS Mail List: You can be kept up to date with any bug fixes or enhancements
by sending an email to "list AT FreeRTOS.org" (obviously form this into a valid email
address) with subject ADD. Emails are fairly infrequent and kept brief. For active
community support uses the forum.

Programming Model
A goal of FreeRTOS is that it is simple and easy to understand. To this end the majority
of the RTOS source code is written in C, not assembler.

Advantages
1. RTOS
2. Under GPL license it is free along with the source code.
3. Written in C so easy to implement
Disadvantages
1. Paid documentation
2. Not very active forums to discuss practical problems.

References
Site: http://www.freertos.org
 KaOS
INTRODUCTION
KaOS is a real-time, multithreaded, preemptive operating system for the Atmel Mega32
microcontroller, which loads and executes programs from a Secure Digital or MMC card.
It was developed by two students of Cornell University.

Key Features
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.

ATMEL SUPPORT
Supports Atmega 32 microcontroller.

Memory Requirements:
Not mentioned on the site

IDE
CodeVision AVR Studio

License
There is no possibility of conflict of interest in creating this project as all the code and
circuit design is offered to the public domain.
There is no requirement of license.

Programming Model
The real complexity of design of KaOS is in the software. The biggest software challenge
faced was getting the bootloading to work. All programs on the Atmel have to be
contained in flash memory, but only the bootloader can write to flash memory. Thus, it
was decided to put the OS in the bootloader section of flash. This decision also helped
avoiding address conflicts with user programs because the bootloader resides at the
highest addresses of flash memory.
The maximum boot loader size is 2048 instructions. KaOS is too big to fit in this space,
so we fixed some functions in high flash addresses next to the boot loader, keeping the
functions that program the flash actually in the boot loader.

PROGRAM LOADER
When KaOS boots, it begins waiting for an SD card and a reset signal. At this point, it
begins reading the contents of the card into small RAM buffers, which are subsequently
transferred to flash. Because RAM is limited, it was decided to do some clever
repurposing of memory when transitioning between loading a program and executing it
under the OS. The buffers used to read data from the card overlap with OS data structures
that are not used until after the program is loaded. Since loading and executing never
overlap, we can use the same memory for both.

Documentation
As this OS was developed by two students of Cornell University, there is no
documentation available.

Advantages
1. RTOS
2. This OS is SD or MMC card bootable.
3. Same memory area can be used for loading as well as executing the OS.

Disadvantages
1. One major limitation of kaOS is that user programs cannot currently take
advantage of hardware interrupts. The reason is that the interrupt vector table can
reside either in the boot loader or at the lower end of flash.
2. No documentation available.
3. Due to lack of thorough testing, this operating system should not be used in
critical applications.
References
Site:
http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2005/acl34/kaos/index.html
Salvo – the RTOS that runs on tiny places ™
Introduction
Salvo 2.0 was the first commercial release of Pumpkin Inc. ‘s cooperative priority- based
multitasking RTOS. Salvo 1.0 was an internal release, written in assembly language and
targeted specifically for the Microchip PIC17C756 PICmicro in a proprietary, in-house
data acquisition system.

Salvo 1.0 provided most of the basic functionality of 2.0. It was decided to expand on
that functionality by rewriting Salvo in C. In doing so, opportunity arose for many
configuration options and optimizations, to the point where not only is Salvo more
powerful and flexible than its 1.0 predecessor, but it is completely portable too.

Key features
1. Salvo has modest ROM and miniscule RAM requirement.
2. You can have event – driven, priority-based, multitasking application in nearly any
single-chip microcontroller, with plenty of room left for your application.
Memory requirement
1) Salvo ROM requirement depends on how much of its function you call and its
RAM requirement depends on how much task and resources you create. Salvo was
specifically designed for processor with limited memory requirement and so it
require only small fraction of what a typical multitasking kernel would normally
require.
2) Using library that support multitasking ,delays and events (binary and counting
semaphores, as well as messages) ,an application will need
a. 10 bytes of RAM for Salvo’s global variable
b. 5 bytes of RAM per task
c. 3 bytes of RAM event

The compiler will require some additional RAM to handle local variable, interrupt save
and restore etc. But the number above represents how little Ram Salvo need to implement
its functionality.

Key Features
1) Require 5 to 100 times less memory than other RTOS
2) It runs on just about any processor form PIC to Pentium
3) Salvo is a cooperative multitasking RTOS with full support of events timer and
services.
4) Salvo is written in ANSI C

IDE
IAR Embedded Workbench V4.20 for Atmel AVR

IAR Embedded Workbench provides a suite of development tools for AVR—the

intregrated development environment offers a continuous workflow, efficient code
generation and ease of use

Key components
• Integrated development environment with project management tools and editor
• Highly optimizing AVR compiler supporting C and C++
• Configuration files for all AVR Classic, ATmega and FPSLIC families, including
devices with the enhanced core
• JTAGICE mkll debugger support
• Run-time libraries
• Relocating AVR assembler
• Linker and librarian tools
• C-SPY debugger with AVR simulator and support for RTOS-aware debugging on
hardware
• Example projects for AVR and code templates
• User and reference guides, both printed and in PDF format
• Context-sensitive online help

Programming Model
Salvo is written in ANSI C

Distribution
Salvo is supplied on CD or downloadable over the Internet as a Windows
95/98/ME/NT/2000/XP install program.

LICENCE
There is freeware version of Salvo called Salvo LITE.
Processor and compiler specific freeware libraries are also provided as a part of
each Salvo LITE distribution. Each freeware library supports a limited number of task
and events. All the default functionality is included in the freeware libraries. If you need
more task and/or events or you need access to Salvo’s advance functionality then you
should consider purchase Salvo LE or Pro.
Source Code is only available with salvo Pro.

COST
Salvo LE for Atmel AVR and MegaAVR... $750.00

One-Year Subscription: A one-year subscription to Salvo includes unlimited distribution

(subject to the terms of the Pumpkin Salvo License Agreement) of software with one year
of free upgrades & support. Each initial subscription automatically expires after one year.
Once it has expired, you may continue to use any version of Salvo previously registered
to you as long as you wish. A one-year subscription to the Salvo Full Version includes:
Unlimited software distribution of your embedded products, Unlimited priority technical
support for one year, Software upgrades for one year, including major releases, Access to
all of Pumpkin's online help and documentation, and Product news and support via
electronic mailing lists (forums). Per Seat/Developer Subscription: All Salvo
subscriptions and subscription renewals are priced per seat/developer, i.e. a single
registered programmer creating embedded applications with Salvo.

Salvo Pro for Atmel AVR and MegaAVR... $1250.00

One-Year Subscription: A one-year subscription to Salvo includes unlimited distribution

(subject to the terms of the Pumpkin Salvo License Agreement) of software with one year
of free upgrades & support. Each initial subscription automatically expires after one year.
Once it has expired, you may continue to use any version of Salvo previously registered
to you as long as you wish. A one-year subscription to the Salvo Full Version includes:
Unlimited software distribution of your embedded products, Unlimited priority technical
support for one year, Software upgrades for one year, including major releases, Access to
all of Pumpkin's online help and documentation, and Product news and support via
electronic mailing lists (forums). Per Seat/Developer Subscription: All Salvo
subscriptions and subscription renewals are priced per seat/developer, i.e. a single
registered programmer creating embedded applications with Salvo.

Documentation
1) Excellent documentation (about each topic related) by the company itself i.e.
Pumpkin Inc.
2) Salvo compiler Reference Manual contains information on compiler specific
information
3) Besides all this there is a fairly active forum for the support on AVR platform
which address all kind of practical issues.
4) The company itself provides technical support on all issues.

Advantages
1. Low RAM and ROM requirements.
2. RTOS
3. Written in C language, so easy to understand and implement.
4. Comprehensive documentation and excellent support.

Disadvantages
1. Only one version is free to use, rest two version are very costly.
2. Source code is available only with the paid version.

References
Site: http://www.pumpkininc.com
 Tiny OS
Introduction
TinyOS is a flexible, application-specific operating system for sensor networks, which
form a core component of ambient intelligence systems.
Sensor networks consist of (potentially) thousands of tiny, low-power nodes, each of
which executes concurrent, reactive programs that must operate with severe memory and
power constraints. The sensor network challenges of limited resources, event-centric
concurrent applications, and low-power operation drive the design of TinyOS. Our
solution combines flexible, fine-grain components with an execution model that supports
complex yet safe concurrent operations. TinyOS meets these
challenges well and has become the platform of choice for sensor network research; it is
in use by over a hundred groups worldwide, and supports a broad range of applications
and research topics. We provide a qualitative and quantitative evaluation of the system,
showing that it supports complex, concurrent programs with very low memory
requirements (many applications fit within 16KB of memory, and the core OS is 400
bytes) and efficient, low-power operation. We present our experiences with TinyOS as a
platform for sensor network innovation and applications.
Four broad requirements motivate the design of TinyOS:
1. Limited resources
2. Reactive Concurrency
3. Flexibility
4. Low Power

Features
1. Real-time
a. Real-time query and feedback control of physical world.
b. Little memory for buffering – data must be processed on the fly.
c. No buffering in radio hw: missed deadline
lost data.
d. Yet TinyOS provides NO real-time guarantees!
2. Power efficient
3. Efficient modularity
4. Small memory footprint
5. Application specific
6. Concurrency-intensive operations
a. Multiple, high-rate data flows (radio, sensor, actuator)
b. TinyOS: must process bit every 100 µs

CPU Supported
ATMEGA128 support.
Memory requirement
1. TinyOS operating system is less than 400 bytes and associated C runtime
primitives (including floating-point libraries) fit in just over 1 KB.
2. Most applications fit in less than 16 KB, while the largest TinyOS application,
TinyDB, fits in about 64 KB

Memory Model

The memory map of a TinyOS application is similar to the structure of an executable

image on the Unix OS. The Harvard architecture of a COTS Mote (i.e. the Atmel MCU)
partitions the memory into two segments: the static program flash memory and the
dynamic data SRAM. Each segment has it's own bus. The advantage of this architecture
is it allows data and executable code to be fetched in parallel and allows many
instructions to execute in one CPU cycle. The Mica2 generation of COTS Motes consists
of 128k of program flash and 4k of SRAM. The memory image is as follows:

i. In the 128K Program Flash

o "text" section - Executable Code
o "data" section - Program Constants
ii. In the 4K SRAM
o "bss" section - Variables
o The rest of the bss is free space - fixed (no dynamic memory)
o stack - grows down in the free space

IDE
Currently to compile TinyOS programs requires an editor such as WordPad and a
command prompt such as cygwin. This IDE is an attempt to integrate these two separate
processes along with some wizard support.

This Integrated Development Environment has been tested on Windows XP and Fedora
Core 4. It requires a TinyOS installation and Eclipse.

There is a plugin of nesC for Eclipse made by Richard Tynan.

Some features:

• Integrated editing and compilation.

• Windows and Linux compatible
• Syntax Highlighting
• Wizard for creating new projects
• Support for CVS based TinyOS Projects
 • Flexible implementation allows for customized make targets and extras
• Error parsing for fast problem location
• Incremental Project Builder
• Separated build and install parameters
• TinyOS project nature

License:
BSD License

Description: BSD licenses represent a family of a permissive free software licenses. The
original was used for the Berkeley Software Distribution, a Unix-like operating system
for which the license is named. The original owners of BSD were the Regents of the
University of California because BSD was first written at the University of California,
Berkeley. The first version of the license was revised, and the resulting licenses are more
properly called modified BSD licenses. Permissive licenses, sometimes with important
differences pertaining to license compatibility, are referred to as "BSD-style licenses".

The licenses have few restrictions compared to other free software licenses such as the
GNU GPL or even the default restrictions provided by copyright, putting it relatively
closer to the public domain. The BSD licenses have been referred to as copycenter, as a
comparison to standard copyright and copyleft free software: "Take it down to the copy
center and make as many copies as you want."

Documentation
1. A good documentation is available on the site http://www.tinyos.net and
http://ttdp.org/tpg/html/book/
2. TinyOS was started as a research project in University of California, Berkeley so
there is support available of the university site.
3. A lot of research is done for using TinyOS as an embedded OS for wireless sensor
network.
4. There is an active yahoo group which addresses almost all practical issues.

Mail list: http://www.tinyos.net/scoop/special/support

Programming Model
TinyOS ’s programming model, provided by the NesC language, centers around the
notion of components that encapsulate a specific set of services, specified by interfaces.
TinyOS itself simply consists of a set of reusable system components along with a task
scheduler. An application connects components using a wiring specification that is
independent of component implementations. This wiring specification defines the
complete set of components that the application uses.

Advantages
1. Small memory footprint
a. Non-preemptable FIFO task scheduling
2. Power efficient
a. Put microcontroller and radio to sleep
3. Efficient modularity
a. Function call (event, command) interface between components
4. Concurrency-intensive operations
a. Event-driven architecture
b. Efficient interrupts/events handling (function calls, no user/kernel
boundary)

5. Good documentation

Disadvantages
1. NO real-time guarantees or overload protection
a. Non-preemptable FIFO task scheduling

References
Site: http://webs.cs.berkeley.edu/tos/
http://www.tinyos.net
 µC/OS-II
Introduction
µC/OS-II, the Real-Time Kernel is a highly portable, ROMable, very scalable,
preemptive real-time, multitasking kernel (RTOS) for microprocessors and
microcontrollers. µC/OS-II can manage up to 255 tasks and provides the following
services:

• Semaphores
• Mutual Exclusion Semaphores (to reduce priority inversions)
• Event Flags
• Message Mailboxes
• Message Queues
• Task Management (Create, Delete, Change Priority, Suspend/Resume etc.)
• Fixed Sized Memory Block management
• Time Management
• Timer Management
• µC/OS-II is Certifiable for use in Safety Critical Systems

CPUs Supported
The µC/OS-II KA assumes that you have µC/OS-II V2.62 or higher. The IAR Embedded
Workbench that are compatible with µC/OS-II KA are as follows (note that µC/OS-II KA
will work will all of them without change). The reason why some of the targets not
currently supported is because IAR needs to add Kernel Awareness to C-SPY for those
targets:

Manufacturer Processor
ARM All licensees
Atmel AVR
Hitachi H8
Intel 8051
Mitsubishi M16C/80
Mitsubishi M32C
Texas Instruments MSP430
 AVR Support:
1. ATmega103

2. ATmega128

3. ATmega256

Memory requirement
µC/OS-II can be scaled to only contain the features you need for your application and
thus provide a small footprint. Depending on the processor, µC/OS-II can be reduced to
little over 2K bytes of code space and 200 bytes of data space (excluding stacks).

Performance
The execution time for most of the services provided by µC/OS-II is both constant and
deterministic. This means that the execution times do not depend on the number of tasks
running in your application. µC/OS-II is also very fast. The scheduler in µC/OS-II
contains only four simple lines of C.

Documentation &Support
The Micrium (parent company) web site contains a lot of content in support of µC/OS-II
which includes following things:

1. Application notes
2. Ports to different processors
3. Answers to frequently asked question (FAQs)
4. Links to recommended books
5. Third party packages (compilers, TCP/IP stacks, file systems, GUIs) and more

Large User Base: µC/OS-II has been used in hundreds of products from companies all
around the world.

Colleges & Universities

Many colleges and Universities around the world are also using µC/OS-II in courses
teaching about real-time systems. This ensures that new Engineers are trained and ready
to use µC/OS-II in your products. Each IAR development kit contains a µC/OS-II
project and a µC/TCP-IP project where applicable with all the source code.

Note
A Validation Suite(tm) developed for µC/OS-II provides all of the documentation
necessary to deliver µC/OS-II as a pre-certifiable software component for safety critical
systems, including avionics RTCA DO-178B and EUROCAE ED-12B, medical FDA
510(k), and IEC 61058 standard for transportation and nuclear systems. The very
affordable Validation Suite(tm), is available through Validated Software. It is
immediately certifiable for the highest criticality systems, including DO-178B Level A,
Class III medical devices, and SIL3/SIL4 IEC-certified systems.

IDE for µC/OS-II

µC/OS-II Kernel Awareness (KA) for WinIDE allows you to display µC/OS-II's internal
data structures in a convenient series of Windows integrated with the WinIDE Debugger.
This provides you with information about each of the active tasks in the target
application, about each semaphore, mutex, mailbox, queue and event flag group along
with a list of all the tasks waiting on these kernel objects, and more. This can become
very useful to the embedded developer when testing and debugging applications.

The iSystem WinIDE is a powerful Integrated Development Environment (IDE) that

allows you to develop and manage a complete embedded application project for a variety
of target processors in a convenient Windows interface. This IDE is the framework where
all necessary tools are integrated: a C compiler, an assembler, a linker, an editor, a project
manager, and a Debugger.

Source Code
µC/OS-II comes with ALL the source code. In fact, the source code is probably the
cleanest and most consistent code of any RTOSs. All services provided by µC/OS-II
starts with the prefix 'OS'. This makes it easier to know that the functions refer to kernel
services in your application. Also, the services are neatly grouped by categories:

1. OSMbox???() relate to message mailboxes

2. OSQ???() relate to message queues
3. OSSem???() relate to semaphore management etc
Licensing
Specifically, if you design a new product using ANY version of µC/OS, you will need to
obtain an object code distribution license. The new policy is as follows:

µC/OS and µC/OS-II source and object code can be used by accredited Colleges and
Universities without requiring a license, as long as there is no commercial application
involved. In other words, no licensing is required if µC/OS and µC/OS-II is used for
educational use.

You need to obtain an 'Object Code Distribution License' to embed µC/OS or µC/OS-
II in a product that is sold with the intent to make a profit or if the product is not used for
education or 'peaceful' research. Please indicate the processor type(s) you will be using
(i.e. 68HC11, 80x86, AVR, etc.).

You also need to obtain an 'Source Code Distribution License' to distribute µC/OS or
µC/OS-II in source code form

No Royalties
µC/OS-II is licensed on a per-product basis and allows you to sell any number of units of
the licensed product. The µC/OS-II KA is licensed on a per-developer basis. In other
words, you are allowed to install µC/OS-II KA on multiple PCs as long as the PC is used
by the same developer. If multiple developers are using µC/OS-II KA then each needs to
obtain their own copy.

Programming model
µC/OS-II Kernel Awareness Plug-In allows you to display µC/OS-II's internal data
structures in a convenient series of Windows integrated with the C SPY Debugger within
the IAR Embedded Workbench. This provides you with information about each of the
active tasks in the target application, about each semaphore, mutex, mailbox, queue and
event flag group along with a list of all the tasks waiting on these kernel objects, and
more. This can become very useful to the embedded developer when testing and
debugging applications.

The IAR Embedded Workbench is a powerful Integrated Development Environment

(IDE) that allows you to develop and manage a complete embedded application project
for a variety of target processors in a convenient Windows interface. This IDE is the
framework where all necessary tools are integrated: a C/EC++ compiler, an assembler, a
linker, an editor, a project manager, and the C SPY Debugger.
Advantages
1. RTOS
2. Certifiable for use in Safety Critical Systems.
3. Low memory requirements.
4. Very fast speed.
5. Comprehensive documentation and support.
6. Very well documented source code.
7. It is free as long as it used for educational and peaceful research.
8. Source code comes with the OS.
9. It is royalty free.
10. Easy implementation in C language.

Disadvantages
1. License fee is to be paid is it is used for commercial purpose.

References
Site: http://www.micrium.com

C/OS-II, The Real-Time Kernel, 2nd Edition

Jean J. Labrosse
R&D Technical Books, 2002
ISBN 1-5782-0103-9
 XMK
Introduction
XMK was designed from the ground up to be very small with respect to ROM, RAM and
CPU processing resources. The original targeted platforms were 8bit microcontrollers
with only 4K to 8K of ROM and 512 bytes of RAM. XMK has since been scaled up to
16bit and 32bit platforms. Originally it was only a preemptive scheduler with thread
synchronization primitives. Now it includes such features as mailboxes, memory pools,
file descriptors, hardware device drivers, and TCP/IP networking. Even as XMK has
expanded its functionality and scope, it has maintained its extreme minimal philosophy
and footprint. Its minimum size is still less than 340 bytes of ROM and 18 bytes of RAM.

XMK is 100% configurable, from a no frills thread scheduler to a full featured RTOS
with TCP/IP networking.

Features

The major justifications for XMK's "eXtreme" moniker are:

1) Compared to other non-chip specific kernels, both commercial and open source, XMK
is one of the smallest if not the smallest.
2) For Microcontrollers that are C friendly, XMK's C source is almost as efficient as
assembler.
3) XMK's design is responsible for its minimal footprint, not the implementation
language. If another kernel design has defined a Thread-Control-Block (TCB) to be 16
bytes, its going to have a larger footprint than XMK which only has a 3 byte TCB,
regardless of the implementation language. Granted, the same kernel design written in
pure assembler is always going to be smaller than a C or C/ASM hybrid implementation.

Supported Hardware Platforms

XMK Scheduler APL
Vendor Proccesor Family Compilers Verified Targets Networking Abstract Hardware
Devices Devices
Atmel AVR GCC STK300-ATmega103
STK500-AT90s8515
STK501-ATmega128 uartA, uartB uartA, uartB

Hitachi/ H8/300, GCC, HEW2 EDK38024 uartA uartA,

Renesas H8/300L,H8/300SLP EDK3664 uartA uartA
H8/300HN, H8/300 HEW2 EDK3664 uartA uartA
Tiny
H8s/Advance Mode GCC, HEW2 EDOSK2674 uIP, lwIP uartA uartA, eth0/uIP,
eth0/lwIP
ESP-HBDB01 uIP, lwIP uartA, uartB uartA, uartB,
eth0/uIP,
eth0/lwIP
M16C and NC30 SKP16C62P uartA, uartB uartA, uartB
R8C/Tiny*1 SKPCOMMS*2 uartA, uartB uartA, uartB

Memory Requirements
• Original targeted platforms were 8bit microcontrollers with only 4K to 8K of
ROM and 512 bytes of RAM
• XMK is then extended to support up to 16bit and 32bit platforms
• Minimum size is still less than 340 bytes of ROM and 18 bytes of RAM.
• XMK can realistically run on a micro that has at least 512Bytes of RAM and 8K
of ROM

IDE
BENV - a multiple host, multi-target build environment.

License
The source can be used freely for commercial and proprietary applications (BSD
licensing agreement).

Two versions of XMK are available which are as follows

Full Version
The full release contains not only the source tree, but a large number of example projects
as well as non-XMK board/chip specific example projects. The full release contains:

• The XMK source tree and documentation.

 • All of the XMK example projects (using BENV as the build
environment).
• A Collection of board/chip specific non-XMK example projects (using
BENV as the build environment).
• BENV - a multiple host, multi-target build environment.

Compact Version
The compact releases contain only the source tree and a very small set of example
programs for a very small set of the supported platforms. The idea to demonstrate XMK
without overwhelming the potential users. The Compact release was created out of the
confusion caused (and rightly so) by the sheer number of files in the full releases. The
compact release uses only traditional GNU Makefiles or vendor specific IDE project
files.

Note: If you are new to XMK, it is recommended that you start with the one of the
compact releases, since it contains significantly fewer files and is easier to navigate.

Advantages
1. RTOS
2. Small. XMK was specifically designed to run on microcontrollers using on the
only onboard ROM and RAM.
3. Configurable. The application only includes the kernel services that are needed.
4. Scalable. XMK will run on virtually any platform, 8bit, 16bit, and 32bit
processors.
5. Portable. XMK is written in C with only a small amount of target specific
assembler for speed and efficiency.
6. Free. The source can be used freely for commercial and proprietary applications
(BSD licensing agreement).

Disadvantages
1. NOT a Debug/Run-time environment. Targets must be loaded and debugged with
the tools supplied by their respective development system.
2. NOT a C/C++ Run-time Library replacement. If the C/C++ Run time libraries are
needed, they must be provided by the target's development system.
3. NOT a very good support and documentation available
Programming Model
The majority of the XMK source code is written in C to be portable across
microcontrollers. XMK does resort to assembler for access to the underlying hardware
registers, and for speed and efficiency for implementing context switches.

References
Site: http://www.shift-right.com/xmk
 AvrX
Introduction
It is a lightweight Real Time Operating System (RTOS) for the Atmel AVR family of
micro-controllers.

AvrX is a Real Time Multitasking Kernel written for the Atmel AVR series of micro
controllers. AvrX contains approximately 40 API in the following Six categories:
Tasking
o Semaphores
o Timer Management
o Message Queues
o Single Step Debugging support
o Byte FIFO support with synchronization.

Supported Targets
As the name suggests, it supports AVR family of microcontroller and has been ported to
Atmega 32, Atmega 128 etc. by some programmers.

Memory requirements
It makes very efficient use of RAM It can run three significant tasks on a processor with
only 128 bytes of RAM. About 700-1000 words of code space needed for all features

IDE
IAR and GCC C compilers

License
The source code is available for download but its not free to use for commercial purpose.
Programming Model
AvrX is a Real Time Multitasking Kernel written for the Atmel AVR series of micro
controllers. AvrX contains approximately 40 API in the following six categories:

• Tasking
• Semaphores
• Timer Management
• Message Queues
• Single Step Debugging support
• Byte FIFO support with synchronization

AvrX can be programmed in C.

Documentation
It is poorly documented OS. There are only two sources of documentation. These are as
follows:
Website: http://www.barello.net
Yahoo group: www.yahoogroups.com/group/avrx

Advantages:
1. Small memory requirement.
2. Easily ported to AVR
3. RTOS
4. Can be programmed in C

Disadvantages:
1. Poor documentation
2. NOT free

References:
http://www.barello.net
NOTE:
AvrX 2.3 has been rewritten to support 16 bit pointers and interface directly with C
compilers. The number of tasks, semaphores, messages and timers is limited only by
system SRAM.

1. The internal data representation was changed to little-endien to make Avrx data
structures compatible with C. This allows extensions to AvrX to be written in C.
An added bonus is that astudio.exe, Atmel's debugger, can display and trace Avrx
data structures such as linked lists of running tasks.
2. Explicit in-line code (Epilog() in particular) has been replaced with #define
macros. The inline construct was causing astudio some grief. Actually, due to
optimization issues with IAR I just got rid of Epilog() macro and now tasks can
call it like any other entry point. It is a little slower and a little fatter, but in the
overall scope it isn't an issue. The GCC version still uses a macro to "rjmp
_Epilog".
3. All register usage has been changed to use nicknames, defined in
"avrxctoasm.inc" This file allows the code to be portable between IAR and GCC.
4. Two AvrX api have changed: AVRX_TASK and AVRX_DEFTASK. Now they
are AVRX_IAR_TASK and AVRX_GCC_TASK and AVRX_IAR_DEFTASK
and AVRX_GCC_DEFTASK, respectively. The issue here is that IAR C uses a
second stack for parameters passing and automatic variable allocation. The task
stack is declared in these two API and that required that the API change. See
example code for usage. Naturally, if you only use one or another compiler you
would only use the appropriate API.
5. To paper over differences between IAR and GCC in how chip variants are
specified and how interrupt handlers are dealt with I added two new files: avrx-
io.h, avrx-signal.h, and included a file that will be added to IAR C compiler in a
June release: avrio.h. If one sticks with the GCC compiler, these files are not
needed. If one sticks with IAR they replicate the GCC techniques, which are
needed for efficient SRAM usage. If one uses the IAR interrupt support, the stack
usage will be considerably larger.
6. A new mechanism has been incorporated to set the kernel stack. It involves a new
API. See samples and test cases for details. The API is "AvrXSetKernelStack()"
 Project Overview

We started with the simulation of KaOS as it was specifically designed for Atmega32, the
same microcontroller on which we had to work. While going on with the simulations we
got hanged up in between as there was no documentation available for this OS. Another
problem we encountered was less development of the particular OS as it was developed
by two students only. Because of al these problems encountered it could not serve the
purpose.

After failing to do simulations with KaOS we took up AVRX. We downloaded its IDE
names IAR but again we had the same problems which we encountered while dealing
with KaOS. It was also very poorly documented. Moreover it was also not free and we
were somewhat more focused towards working on a free OS as we had to use the
minimum resources.

Then finally we took up FreeRTOS. We downloaded the code from its website and
thoroughly studied its documentation. We studied how the various concepts of a real time
OS were implemented into it. Then we deployed the OS on the simulator to simulate its
behavior on Atmega323. Further we also designed some basic LED blinking applications
to be implemented on the microcontroller. For example we successfully implemented the
common trail-light problem on the simulator.

Finally, it was concluded that FreeRTOS is the most suitable OS according to the project
requirements and thus it was adopted and implemented.