AC OB S. Multi-threaded FW framework (OS) for embedded ARM systems Torsten Jaekel, June 2014

Similar documents
Real-Time Programming

Lecture notes Lectures 1 through 5 (up through lecture 5 slide 63) Book Chapters 1-4

Process Coordination and Shared Data

AUTOBEST: A United AUTOSAR-OS And ARINC 653 Kernel. Alexander Züpke, Marc Bommert, Daniel Lohmann

Review: Program Execution. Memory program code program data program stack containing procedure activation records

Review: Program Execution. Memory program code program data program stack containing procedure activiation records

Tasks. Task Implementation and management


Chapter 6: Process Synchronization

Threads and Too Much Milk! CS439: Principles of Computer Systems January 31, 2018

Precept 2: Non-preemptive Scheduler. COS 318: Fall 2018

Threads and Too Much Milk! CS439: Principles of Computer Systems February 6, 2019

Grundlagen Microcontroller Interrupts. Günther Gridling Bettina Weiss

Micrium µc/os II RTOS Introduction EE J. E. Lumpp

Threads and Concurrency

Threads and Concurrency

INF 212 ANALYSIS OF PROG. LANGS CONCURRENCY. Instructors: Crista Lopes Copyright Instructors.

SMD149 - Operating Systems

Review: Program Execution. Memory program code program data program stack containing procedure activation records

Preemptive Scheduling

Modern Embedded Systems Programming: Beyond the RTOS

Processes and Non-Preemptive Scheduling. Otto J. Anshus

Lecture 3. Introduction to Real-Time kernels. Real-Time Systems

ZiLOG Real-Time Kernel Version 1.2.0

Zilog Real-Time Kernel

FreeRTOS. A Brief Overview. Christopher Kenna. October 1, Avionics. FreeRTOS 1 / 34

Dr. Rafiq Zakaria Campus. Maulana Azad College of Arts, Science & Commerce, Aurangabad. Department of Computer Science. Academic Year

Embedding OS in AVR microcontrollers. Prof. Prabhat Ranjan DA-IICT, Gandhinagar

Back to RTOS. CSE466 Autumn 00-1

THREADS ADMINISTRIVIA RECAP ALTERNATIVE 2 EXERCISES PAPER READING MICHAEL ROITZSCH 2

CS370 Operating Systems Midterm Review

(5) Question 2. Give the two most important factors for effective debugging. Jonathan W. Valvano

EECS 482 Introduction to Operating Systems

Review: Program Execution. Memory program code program data program stack containing procedure activation records

Today s Topics. u Thread implementation. l Non-preemptive versus preemptive threads. l Kernel vs. user threads

Lecture 3: Processes. CMPUT 379, Section A1, Winter 2014 January 13, 15 and 17

CS/ECE 6780/5780. Al Davis

Page 1. Lab 5 Logistics. Implicit Threads. Explicit Thread Semantics. Problem not enough interrupt pins CS/ECE 6780/5780. Al Davis

GLOSSARY. VisualDSP++ Kernel (VDK) User s Guide B-1

2. Introduction to Software for Embedded Systems

Timers 1 / 46. Jiffies. Potent and Evil Magic

RT3 - FreeRTOS Real Time Programming

Processes Prof. James L. Frankel Harvard University. Version of 6:16 PM 10-Feb-2017 Copyright 2017, 2015 James L. Frankel. All rights reserved.

CIS233J Java Programming II. Threads

Embedded Operating Systems

Efficiency and memory footprint of Xilkernel for the Microblaze soft processor

Interrupts and Time. Real-Time Systems, Lecture 5. Martina Maggio 28 January Lund University, Department of Automatic Control

COMP 7860 Embedded Real- Time Systems: Threads

Interrupts and Time. Interrupts. Content. Real-Time Systems, Lecture 5. External Communication. Interrupts. Interrupts

CSL373: Lecture 5 Deadlocks (no process runnable) + Scheduling (> 1 process runnable)

What s An OS? Cyclic Executive. Interrupts. Advantages Simple implementation Low overhead Very predictable

Interrupts on the 6812

Designing Responsive and Real-Time Systems

Operating System. Hanyang University. Hyunmin Yoon Operating System Hanyang University

CODE TIME TECHNOLOGIES. Abassi RTOS. Porting Document. ARM Cortex-M0 Atollic

EECS 482 Introduction to Operating Systems

Programming in Parallel COMP755

EE 472 Embedded Systems. Name solutions. Instructions:

Please do not handin a.doc file, a.zip file, a.tar file, or anything else

Main Points of the Computer Organization and System Software Module

OS Structure, Processes & Process Management. Don Porter Portions courtesy Emmett Witchel

System Building. Events, Co-routines, Continuations and Threads - OS (and application) Execution Models. Event Model. Events

[537] Locks. Tyler Harter

Processes, PCB, Context Switch

Process Scheduling Part 2

Process- Concept &Process Scheduling OPERATING SYSTEMS

Putting it All Together

1 Execution of main program is suspended. 2 All registers are pushed onto the stack. 3 The ISR, or background thread, is executed.

Process Synchronization and Communication

V. 2. ( Copyright 2004, 2006 Yuri Tiomkin

Operating Systems CMPSCI 377 Spring Mark Corner University of Massachusetts Amherst

ECE/CS 5780/6780: Embedded System Design

Dept. of CSE, York Univ. 1

Predictable Interrupt Management and Scheduling in the Composite Component-based System

Quadros. RTXC Kernel Services Reference, Volume 1. Levels, Threads, Exceptions, Pipes, Event Sources, Counters, and Alarms. Systems Inc.

Implementing Scheduling Algorithms. Real-Time and Embedded Systems (M) Lecture 9

Virtual Machine Design

Cooperative Multitasking

CS370 Operating Systems

Synchronization Spinlocks - Semaphores

Implementation of the ART Real Time Micro Kernel

MARUTHI SCHOOL OF BANKING (MSB)

LDR R0,=0x L: LDREX R1, [R0] ORR R1, #4 STR R1, [R0] (5) Part a) Why does the 9S12 code not have a critical section?

ECE 7650 Scalable and Secure Internet Services and Architecture ---- A Systems Perspective. Part I: Operating system overview: Processes and threads

Processes. Process Management Chapter 3. When does a process gets created? When does a process gets terminated?

Review: Program Execution. Memory program code program data program stack containing procedure activation records

* There are more than 100 hundred commercial RTOS with memory footprints from few hundred kilobytes to large multiprocessor systems

CS A331 Programming Language Concepts

OPERATING SYSTEMS CS3502 Spring Processor Scheduling. Chapter 5

What is a Process? Processes and Process Management Details for running a program

CODE TIME TECHNOLOGIES. Abassi RTOS. Porting Document. ARM Cortex-M3 CCS

Chapter 2 Processes and Threads. Interprocess Communication Race Conditions

Locks. Dongkun Shin, SKKU

Lecture #16 Cooperative & Preemptive Context Switching Embedded System Engineering Philip Koopman Wednesday, 16-Mar-2016

NuttX Realtime Programming

Introduction to Embedded Systems. Lab Logistics

The Real Time Thing. What the hack is real time and what to do with it. 22C3 30. December Erwin Erkinger e.at

Computation Abstractions. Processes vs. Threads. So, What Is a Thread? CMSC 433 Programming Language Technologies and Paradigms Spring 2007

Chapter 5: Process Synchronization. Operating System Concepts 9 th Edition

Concurrent Programming

Transcription:

AC OB S Multi-threaded FW framework (OS) for embedded ARM systems Torsten Jaekel, June 2014

ACOBS ACtive OBject (operating) System Simplified FW System for Multi-Threading on ARM embedded systems ACOBS is not a full blown Operating System It is: A framework to support Event Driven Programming and Multi-Threading It is Non-Preemptive (cooperative) An Active Object (AO) behaves like a concurrent task It is based on Run-To-Completion (RTC) approach Idea is inspired by QP : http://www.state-machine.com/qp/ Very small foot print (approx. 4KB for core functions) Intended for Cortex-M processors No need for Critical Sections, Semaphores, Task Message Queues, Inter-Task Synchronization etc.: a very simple multi-task (AO) Scheduler and Context Switcher (simple assembly code, all other in C) Object Oriented Design and Programming in C

ISR AO n AO 1 RTC RTC RTC RTC AO 0 SYS main, idle RunRequest Release (yield CPU) Context Switch Event ISR SYS Activate Event (activate, suspend) AO AO Shared Code Stack Private Data Shared Code Stack Retained RAM segments Endless Loop Private Data

Active Object (AO) When active they run through an atomic code sequence, as Run-to- Completion (RTC) They yield the CPU via dedicated System Calls which enters the AO scheduler (switch the context to the next active or requested AO in list) AOs have to be fair (cooperative): they have to yield the CPU at a certain time (RTC sequence done) - large code sequences have to be split into atomic code sequences Can be suspended by itself or by another AO Can be activated via a run request, e.g. triggered by an INT seen or by another AO ( event to handover/activate another AO ) AOs can exit and can be re-launched (start over, re-initialize an AO, e.g. for SW error recovery, fatal FW issues) ISRs are very short, mainly just acknowledge INT and set flag for AO RunRequest (non-preemptive) main() is the Idle AO (always active, running as background/housekeeping task, needed to keep scheduler alive) main() can enter WFI if not any AO is in RunRequest or Active state A background cyclic timer interrupt (SysTick) could activate the idle AO or the next Event INT will kick off the scheduler again *

AO Scheduler Save and Restore Context and activate next AO (Round Robin list, currently no priorities - can be extended, e.g. Event AO with higher prio and running first, IPC AO with lower prio RTC for event handling with higher prio) Task switch just on dedicated System Calls (non-preemptive): Deterministic Real-Time Worst Case Latency No need for event queuing: every event can be associated with an AO (also sharing the code with private data), the AOs are queued implicitly The AO context switch is very fast, the scheduler is very simple (Round Robin, just iterate to next active or requested AO in list, directly indexed, not using concatenated lists, simplified dynamic memory management: MemPools ) Power Optimized AOs All entities of an AO can be placed on segmented, retained memory regions (AO stack, local variables, private data and code hosted on inactive memory segments, when AO is inactive - minimize powered RAM segments) OOP Single inheritance in C derive specific AOs from a hardware independent base class Simple polymorphism virtual functions, call AO functions via generic base class *

Define AOs during compile time No dynamic AO creation and instantiation, defined static with active or suspended state during compile time Define the stack location and size (better trim of SRAM size, decoupled, re-start AOs on fatal issues, long jump inside AO code possible) Inherit from AO Base Class (scheduler acts on generic base class) Example Derive a new class for the AO, inherit the AO Base Class (typedef, structs) Define the data array for the derived AO (initialized member variables) Create the stack region (and size) for local variables Define (and initialize) the Scheduler Context Storage table: set start SP, entry address (start PC), stored registers... This array is used to store and restore AO context with current and cold start settings Define the scheduler AO Management table: assign a unique AO ID (implicit via array index) define the cold start state (Active, RunRequest) and the reference to Scheduler Context Storage table entry Code the AO function body: cold start sequence = Constructor endless task loop with a system call to yield CPU after RTC yield the CPU when an atomic sequence has been done

#include "active_object.h #include "fifo_ao.h //AO definition with inherited AO base class static void FIFO_AO(void); //prototype static unsigned long FIFO_AO_Stacks[(EFIFOChannel)MCP_IPC_NUM_CMD_FIFOS][FIFO_AO_STACK_SIZE + SP_LR_OFF]; static TFIFOAOData FifoAOData[(EFIFOChannel)MCP_IPC_NUM_CMD_FIFOS] = /* initialize the base */ MCP_IPC_CONV_FIFO2IND(AP_SEC2MCP) + 1}, /* initialize the FIFO AO members */ AP_SEC2MCP, }; }, // MCP2AP_SEC //base class member //new sub-class members static TAOContext FIFO_AO_Context[(EFIFOChannel)MCP_IPC_NUM_CMD_FIFOS + 1] = /* main_ao_context - main() is always the idle AO */ /* AOContext */ 0, /* PC of main will be stored here */ 0, 0, 0, /* main will store SP here, SP is already set */ 0,0,0,0, 0, /* not used on main object */ 0, /* not used on main object */ 0 /* data Ptr, not used here */ }, /* AOContext */ /* cold start parameters as constant copy, used to restart */ FIFO_AO,0,0,&FIFO_AO_Stacks[MCP_IPC_CONV_FIFO2IND(AP_SEC2MCP)][FIFO_AO_STACK_SIZE], 0,0,0,0, /* the current AO state, stored context */ FIFO_AO, /* Entry */ &FIFO_AO_Stacks[MCP_IPC_CONV_FIFO2IND(AP_SEC2MCP)][FIFO_AO_STACK_SIZE], /* Stack Pointer */ &FifoAOData[MCP_IPC_CONV_FIFO2IND(AP_SEC2MCP)] /* Data Pointer */ }, // };

/* global, used by AO scheduler */ TAOMngt /* EXPORT */ AO_Mngt[(EFIFOChannel)MCP_IPC_NUM_CMD_FIFOS + NUM_EVENT_AO + 1 + 1] = /* main AO - we have to have always and it has to be active */ /* AO_ID: 0 - main main has to be always AO ID 0 */ /* state */ Active, /* request */ NoRunRequest, /* AOContext */ &FIFO_AO_Context[0] /* main (idle AO) has ID 0 */ }, /* now the actual AOs the index on array is the AO ID */ /* AO_ID: 1 - AP_SEC2MCP */ /* state */ Active, /* request */ NoRunRequest, /* AOContext */ &FIFO_AO_Context[MCP_IPC_CONV_FIFO2IND(AP_SEC2MCP) + 1] }, //. }; Remarks The AO management table is global and used by name in scheduler The order (index) in list is used as unique AO ID (main has to be the first, ID 0) An AO can be active at startup time (their AO constructor will be called) or inactive (launched via request, constructor called when requested)

void FIFO_AO(void) /* * Local Variables bear stack size in mind */ TFIFOAOData *dataptr; TpIPCMsg pipcmsg, prspmsg; EMCP_API_MsgErr ipcmsgerr; //reference to private data /* * Constructor - initialize the AO - register the AO on Context and set dataptr */ dataptr = (TFIFOAOData *)AO_DEF_START; //cold start init context storage and data reference pointer /* * Endless Task Loop of the thread */ while (1) ipcmsgerr = mcpipc_receivecmd(dataptr->cmdch, &pipcmsg); if (ipcmsgerr!= NO_ERR) /* incomplete command - wait and yield CPU */ AO_suspend_self(); //system call, yield the CPU } /* it needs a new interrupt to be triggered and to continue here! */ continue; } else /* * now do as RTC */ //. } } //end while Task Loop Remarks Code as reentrant (thread-safe) shared code Use private data members for different states Use AO ID or indexes to differentiate what to do

void EXT00_IRQ_Handler(void) /* clear the interrupt */ mcp_fifointclear(ap_sec2mcp); } /* activate the associated AO */ FIFO_setIntRcvd(AP_SEC2MCP); //do some AO specific stuff and call system function to request AO void FIFO_setIntRcvd(EFIFOChannel ch) /* increment the counter on the lower layer FIFO, here for SM FIFO, on APB FIFO it is empty call */ sfifo[ch].setintrcvd(ch); // virtual, polymorph member function call } /* call system function to request to activate AO */ AO_runRequest((int)MCP_IPC_CONV_FIFO2IND(ch) + 1); //system call request to activate AO Remarks The ISR will just acknowledge INT reason (clear it) and do System Call to set flag for scheduler keep it as short as possible On next System Call with CPU yielded the scheduler will find requested AO and let it run The ISR itself does not change the context no race condition, no need for semaphores and critical sections INT latency (real time constraint) is determined by AO code design (RTC sequences) deterministic behavior

ACOBS uses standard C Very few lines of assembly code for context save and restore Multi-threading based on Active Objects and Run-to-Completion Ported and tested on ARM Cortex-M0/M0+, M3/M4 Supporting some OOP features such as single inheritance ACOBS is intended for deterministic real-time firmware