OctOS: a minimalist preemptive multi-tasking "OS" for AVR

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Last fall I wrote a multitasking system for AVR micros.  My goal is to shoehorn solid capability into a small space.   I have no specific questions, just looking for constructive comments.

 

A. The principles of OctOS are:

  1. Support multiple pre-emptive threads of execution.
  2. Emphasize small flash and ram footprint over general purpose multi-tasking features like semaphores, timers.  It is assumed interrupt masking is sufficient for dealing with critical sections.
  3. Empasize low latency task switching over supporting features like a large number of tasks and large number of task priorities, etc.
  4. Assume a single (low priority) Main task is the lone task that link to libc.  This opens the possibility where other tasks use a proper subset of the AVR register set. Context switches exclude the registers dedicated to Main.
  5. Support CPU sleeping when no task is ready.
  6. Require that user ISRs run with interrupts masked, to avoid tracking interrupts.
  7. Verfiy OS safety through model checking (e.g, with SPIN).

B. Results:

  1. Flash size is about 350 bytes.
  2. RAM size is about 50 bytes plus stack for each user task.  Most of the 50 bytes of ram is used for the idle task context, which includes space for a large number of unused registers.  Perhaps custom code for swapping the idle task might make this smaller, with cost to flash for extra code.
  3. Worst case interrupt latency is on the order of 20 cycles.  This estimate is based on a cursury inspection of the critical sections of code.

C. Notes on the design:

  1. OctOS is coded in assembly.
  2. Up to seven user tasks are supported.
  3. One system task, Task7, the lowest priority task, will either spin or put the CPU to sleep, based on user configuration.
  4. There are eight total priority levels, each priority level is associated with an associated task ID: Task7 has priority 7.
  5. There is one user main task, which can be any one of Task0 through Task6 which may use all registers.
  6. A compile time configuration option can be used to specify which registers are used for the other six user tasks.  The current default configuration includes all 32 registers in the context. 1
  7. Interrupts are not masked during the bulk the task swap operation.

1GCC accepts command-line arguments (e.g., -ffixed-r3) to refrain from using specified registers. However, many registers (e.g., r18-r31) may not be -ffixed.

 

Incomplete example code (I have run examples but they are currently outdated wrt the API.):

  ISR(RTC_PIT_vect) {
    oct_isr_ready_task(OCT_TASK_2|OCT_TASK_3); /* ready task2 and task3 */
    oct_isr_return();
  }

  #define STKSIZ2 0x40
  uint8_t task2_stk[STKSIZ2];

  void task2(void) {
    while (1) {
      oct_idle_task(OCT_TASK_2);  /* idle self */
      ...
      }
    }
  }

  #define STKSIZ3 0x40
  uint8_t task3_stk[STKSIZ3];

  void task3(void) {
    while (1) {
      oct_idle_task(OCT_TASK_3); /* idle self */
      ...
      }
    }
  }

  int main(void) {
    oct_os_init(OCT_TASK_6);  // init OS, assigning main to TASK_6
    oct_attach_task(OCT_TASK_2, task2, task2_stk, T2_STKSIZ);
    oct_attach_task(OCT_TASK_3, task3, task3_stk, T3_STKSIZ);
    oct_wake_task(OCT_TASK_2|OCT_TASK_3); /* start 'em */
    while (1) {
        ...
    }
  }

Here is code for oct_wake_task, to add one or more tasks to the ready-list and then jump to the task-swap procedure if a higher priority task is ready.

oct_wake_task:
	cli
	lds r25,rdylist
	or r25,r24
	sts rdylist,r25
	lds r24,curmask
	and r24,r25
	brne task_swap
	reti  ; sei + ret

 

Last Edited: Fri. Aug 28, 2020 - 06:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An operating system always means additional resource requirements and additional bureaucratic effort. This additional effort must be well justified, especially on small 8-bit controllers. With the interrupt system, these offer sufficient possibilities to distribute tasks and process them independently of one another. In this way you usually work more flexibly and purposefully. However, as the hardware complexity increases, an operating system becomes more and more useful.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MattRW wrote:
...

Flash size is about 350 bytes.

...

Up to seven user tasks are supported.

...

What license did you select for OctOS?

Reasons :

  1. HalfKay is about that size, likely in assembly language, and proprietary.
  2. QP-nano has eight active objects, GPLv3 with an Arduino exception

 


Appendix I: SPDX License List - specification v2.1.1 due to Linux Foundation’s SPDX Workgroup Announces New Open Compliance Standard - The Linux Foundation

License Exceptions | Software Package Data Exchange (SPDX)

HalfKay Communication Protocol | PJRC

http://web.archive.org/web/20200218120146/https://www.state-machine.com/products/

QP FRAMEWORK EXCEPTION FOR ARDUINO

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

MattRW wrote:
...

Flash size is about 350 bytes.

...

Up to seven user tasks are supported.

...

What license did you select for OctOS?

Reasons :

  1. HalfKay is about that size, likely in assembly language, and proprietary.
  2. QP-nano has eight active objects, GPLv3 with an Arduino exception

 

Have not decided yet, but may be LGPL3.

 

I see that others have smaller flash size.   I guess I need work on my AVR assembly.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

good work, I have a RTOS for, "cough, cough" ARM.

ARM Baby!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That LGPL makes no sense on embedded. I tried to figure out how to comply with it after burning some firmware on an embedded board and sending it to someone, it was not fun, the LGPL gives them rights to object files but making those available is no fun. Maybe add an exclusion allowing binary distribution without the object file, but that goes against the very nature of the LGPL.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ron_sutherland wrote:

That LGPL makes no sense on embedded. I tried to figure out how to comply with it after burning some firmware on an embedded board and sending it to someone, it was not fun, the LGPL gives them rights to object files but making those available is no fun. Maybe add an exclusion allowing binary distribution without the object file, but that goes against the very nature of the LGPL.

 

I think you are right.  My reading is that if you generate firmware with LGBL library X you need to distribute your binary minus X so that someone can relink with their own copy of X source.  So without providing the object it does not make sense to use the LGPL.  So I'm interested in other thoughts (in another thread maybe).  One needs to start with "What am I trying to accomplish with a license?" [edit] I'm not there yet.

Last Edited: Fri. Aug 28, 2020 - 11:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MattRW wrote:
[edit] I'm not there yet.
Maybe can be due to publishing a part of OctOS source code into your thread (AVR Freaks T&C); as the creator of OctOS, you can change the license.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting.  Heard of Femtoos?

http://www.femtoos.org/

 

Project has been idle for 5 years, though...

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

joeymorin wrote:
Project has been idle for 5 years, though...

 

Before you have familiarized yourself with foreign code and explored all the possibilities and all the restrictions, it is often a hundred times faster to write your own code- that precisely implements the desired application without unnecessary ballast. Third-party OS-software must simplify development or it will not serve its purpose. In addition, 8-bit controllers are more suitable for simple tasks and their hardware is not very well prepared for multitasking. Operating systems that try to do despite this are therefore often nothing more than interesting technical feasibility studies.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GermanFranz wrote:
Third-party OS-software must simplify development or it will not serve its purpose.
Concur

GermanFranz wrote:
Operating systems that try to do despite this are therefore often nothing more than interesting technical feasibility studies.
AN3007 Getting Started with FreeRTOS on megaAVR 0-series

 


An OS in a Can | The Ganssle Group

AN2783 FreeRTOS Using Percepio Trace on ATmega4809

FreeRTOS for AVR128DA | AVR Freaks

ATMEGA4809 - 8-bit Microcontrollers

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

Concur

 

Well, there is no contradiction. The question is, does the use make sense and that is where it gets very difficult with small 8-bit controllers.

FreeRTOS seems to be a famous number in microcontroller operating systems, it is used for many controller families. For someone who already uses this operating system with others (e.g. 32-bit controllers), it might make the most sense to use it on a small 8-bit avr controller too.