Notes - MIECT
Sistemas Operativos E De Tempo-real
Notes - MIECT
Sistemas Operativos E De Tempo-real
  • Sistemas Operativos e de Tempo-real
  • Basic Concepts About Real-Time Systems
    • Preliminaries
    • Definitions
    • Objective of the Study of RTS
    • Requirements of Real-Time Systems
  • Real Time Model
    • Real Time Model
    • Temporal Control
    • Task states and execution
    • Kernel/RTOS Architecture
      • Time Management Functions
    • Examples of RTOS
  • Practical Class 01
    • Real-Time Services in Linux
    • Using the Linux real-time services
  • Scheduling Basics
    • Basic concepts
    • Scheduling Algorithms
      • Basic algorithms
    • Static Cyclic Scheduling
    • Exercise
  • Fixed Priority Scheduling
    • Online scheduling with fixed priorities
    • Schedulability tests based on utilization
      • Deadline Monotonic Scheduling DM
    • Response-time analysis
  • Practical Class 2
    • Xenomai brief introduction
    • API
    • Developing an application
  • Dynamic Priority Scheduling
    • On-line scheduling with dynamic priorities
    • Analysis: CPU utilization bound
    • Analysis: CPU Load Analysis
    • Other deadline assignment criteria
  • Exclusive Access to Shared Resources
    • The priority inversion problem
    • Techniques for allowing exclusive access
    • Priority Inheritance Protocol
    • Priority Ceiling Protocol
    • Stack Resource Policy
    • Notes
  • Aperiodic Servers
    • Joint scheduling of periodic and aperiodic tasks
    • Aperiodic Servers
    • Fixed Priority Servers
    • Dynamic Priority Servers
  • Limited preemption, release jitter and overheads
    • Non-preemptive scheduling
    • Impact of Release Jitter
    • Accounting for overheads
    • Considerations about the WCET
  • Profiling and Code Optimization
    • Code optimization techniques
      • CPU independent optimization techniques
      • Cache impact
      • Optimization techniques dependent on memory architecture
      • Architecture-dependent optimization techniques
    • Profiling
  • Multiprocessor Scheduling, V1.2
    • Introduction
    • Definitions, Assumptions and Scheduling Model
    • Scheduling for Multicore Platforms
    • Task allocation
Powered by GitBook
On this page
  • What is Xenomai?
  • For what is it used?
  • Architecture
  • Co-kernel: Cobalt
  • Single (Linux) kernel: Mercure
  • Task migration: Cobalt only
  • Real-Time Driver Model
  1. Practical Class 2

Xenomai brief introduction

What is Xenomai?

Xenomai is a RTOS-to-Linux Portability Framework.

It comes in two flavors.

  • As a dual-kernel / co-kernel extension for (patched) Linux.

    • Allows more stringent real-time requirements.

    • More complex installation.

  • As libraries for native Linux (including PREEMPT-RT)

    • Less predictable.

    • Can be used on standard Linux.

For what is it used?

Many areas:

  • Machine control systems, PLCs.

  • Printing machines (manroland).

  • Printers / copying machines.

  • Network switches (e.g. Ruggedcom).

  • Magnetic resonance tomographs (Siemens Healthcare).

  • OROCOS (OSS robotics framework).

  • Many robotic research projects.

  • And many others ...

Architecture

Co-kernel: Cobalt

Supplements Linux with a real-time co-kernel running side-by-side with it.

Cobalt extension built into the Linux kernel and deals with all time-critical activities (e.g. interrupts, scheduling).

The Cobalt core has higher priority than native kernel activities.

Best real-time performance, but requires kernel patch (Adeos) and compilation.

What is a co-kernel architecture

Based on Adeos: nanokernel hardware abstraction layer (HAL), or hypervisor, that operates between computer hardware and the operating system.

Single (Linux) kernel: Mercure

Uses only the native real-time capabilities of the native Linux kernel.

PREEMPT-RT enhances the real-time behavior.

  • Not mandatory.

  • Depends on app requirements with respect to latency/jitter.

All the non-POSIX RTOS APIs that Xenomai provides are emulated over the native Linux threading.

  • “Skins” are also supported

Task migration: Cobalt only

Every cobalt thread is also a Linux task.

Thread states are shared/synchronized among domains.

Only one can run at a time.

  • Migration to RT:

    • On syscall xnshadow_harden().

    • Linux task suspended; Cobalt thread resumed.

  • Migration to Linux.

    • On syscall xnshadow_relax(), or fault/trap, signal.

    • Cobalt thread suspended; Linux task resumed.

Real-Time Driver Model

Goals and principles.

  • Provide environment for co-kernel real-time drivers.

  • Service interface towards applications and other drivers.

  • Low-level primitives from implementing drivers.

  • Linux for non-RT purposes: setup / shutdown, resource discovery and claiming, etc.

PreviousResponse-time analysisNextAPI

Last updated 2 years ago