Welcome!

AvRtos is a small, preemtive, priority based real time operating system for Atmel AVR and ARM microcontrollers. It was written in C.
AvRtos provides message queues and semaphores for task synchronization. It uses a static memory allocation scheme.

AvRtos is nearly the smallest RTOS out there. Even pico]OS is much bigger.

AvRtos can be compiled using gcc compiler. There is a AvrStudio 4 and Eclipse project file to get the example code working very quickly.

Introduction

It was my intention to develop a new real time operating system for AVR microcontrollers because current existing RTOS's do not really fit my expectation of a tiny and easy to use RTOS.
This is because most RTOS's for AVR are written in assembler. This makes it really difficult to read and understand the written source code and it is not easy to find bugs.
Also my expectation is to make it easier to integrate it into an existing project so that the whole RTOS fits into a small amount source and header files.
I tried to develop a RTOS that fits a 1 kByte source code and to minimize the overhead of RAM for task control structures and task synchronization elements. As a result AvRtos uses the following system resources:

• 1 kByte of flash memory for code
• 11 Byte RAM for each task control block
• 5 Byte RAM for each semaphore control block
• 13 Byte RAM for each queue control block

Currently AvRtos supports following task synchronization elements:

• Mutexes
• Semaphores
• Queues

Source code organization

The Folder "Projects/XXXX" contains all project specific source files, where XXXX defines the CPU or Harwareplatform.
AvRtosConfig.h is located in "Projects/XXXX/Include"

The folder "Source" contains the hardware independent kernel sources.
The subfolder "Source/Hardware/XXXX" contains the CPU-Core dependend stuff for switching the kernel context and provide system tick interrupt.
XXXX defines the CPU-Core.

All declarations in the header file "Source/AvRtos.h" could be used and represent the user API of the kernel.

All declarations in the header file "Projects/XXXX/Include/AvRtosConfig.h" can be adapted by the user and represent the the kernel configuration.

Functions beginning with an underscore are internal kernel functions and shouldn't be used outside the kernel.

Customization

The kernel needs a system tick interrupt. Currently this interrupt is configured for a 10ms tick rate. For most systems this tick rate is fast enough but you can increase this tick rate to about 1kHz if desired. While the overall system load will be increased a fast reaction to events could be achieved.
The system tick interrupt configuration is platform dependent.

In the function kernelSetupTimerInterrupt() you have to configure the timer.
The interrupt function MUST be declared naked because the processor context will be saved and restored by the macros SAVE_CONTEXT() and RESTORE_CONTEXT().
If you change the tick interrupt please make sure that this interrupt is working correctly. If this interrupt is not working correctly, no context switch can be performed.

For AVR controllers TIMER0 is used but you could also use this timer for some other system functions.
In this case you must provide another tick interrupt. For example you can also use TIMER1.
Therefore you have to change the interrupt vector from TIMER0_COMP_vect to TIMER1_COMP_vect but do not change the source code of the interrupt function.

The ARM7TDMI platform uses the PIT timer of the AT91SAM7 as tick interrupt.
Maybe you have to provide an other timer interrupt, if you use a other CPU.

The ARM Cortex platforms uses the CPU-Core timer as tick interrupt.
For this platforms nothing has to be adapted, because the SysTick interrupt will be configured with the CMSIS API, provided by ARM.

Interrupt service routines

If you use interrupts in your software, you should use the redefined macro from "Source/Hardware/XXXX/AvRtosHw.h".
The benefit to use this macro is that OS functions can recognize the current running context and perform a context switch if necessary.
If you declare the interrupt service routine directly a possible context switch can only be performed at the next system tick. This increases the latency maybe.
Please see the example in the file main.c, how you can do this.