Applications and rtoss
This presentation is the property of its rightful owner.
Sponsored Links
1 / 16

Applications and RTOSs PowerPoint PPT Presentation


  • 67 Views
  • Uploaded on
  • Presentation posted in: General

Applications and RTOSs. System Layers. Everything above hardware is software Layered Architecture. Application(s)/Programs. Firmware. Hardware. Command and Control App. This kind of application shows up over and over again in Embedded Systems Simple Command Shell May use serial port

Download Presentation

Applications and RTOSs

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Applications and rtoss

Applications and RTOSs


System layers

System Layers

  • Everything above hardware is software

  • Layered Architecture

Application(s)/Programs

Firmware

Hardware

Instructor: G. Rudolph, Summer 2008


Command and control app

Command and Control App

  • This kind of application shows up over and over again in Embedded Systems

  • Simple Command Shell

    • May use serial port

    • May use internet if you assume network stack is operational

Instructor: G. Rudolph, Summer 2008


Command representation

Command Representation

Name

  • Handler

  • Optional Parameters

  • Shell must build an internal representation of any legal command

  • One structure entry per command

  • In C, we link names to function pointers

  • In OO systems, we would typically link a command to an object rather than a method

Instructor: G. Rudolph, Summer 2008


Command table

Command Table

  • In text, all commands are in a single file

    • Single place to look in the code

  • In Java, we “can’t” do that the same way, but we can do other things

    • Put all command objects in the same package

    • Modularity is usually better in long run than monolithic files

  • Lejos JVM is written in C for efficiency and convenience. But JVM is an OS, not an application.

Instructor: G. Rudolph, Summer 2008


Applications and rtoss

RTOS

  • Embedded System May or may not use an OS

  • Many RTOS’s available

  • RTOS is NOT democratic!

  • Highest priority task that is ready to run gets all the time it needs

  • If other tasks starve, it’s the programmer’s fault

Instructor: G. Rudolph, Summer 2008


Reasons to use an rtos

Reasons to Use an RTOS

  • If not using an RTOS, use alternate software framework

    • Make writing programs easier

  • Multi-tasking

  • Scheduling

  • Timers

  • Inter-task communication

  • Isolate/manage software changes WRT hardware

Instructor: G. Rudolph, Summer 2008


Os kernel

OS Kernel

Scheduler

  • FIFO

  • Shortest task first

  • Priority

  • Round Robin

  • Intertask Communication Mechanisms

    • Pipes

    • Queues

    • Shared Memory [Variables (Mutex’s)]

  • Instructor: G. Rudolph, Summer 2008


    Real time scheduling algorithms

    Real-time Scheduling Algorithms

    • Many tasks have deadlines, some may not

    • Real-time Executive

    • Earliest deadline First

    • Minimal Laxity First

    • Resource Reservation

    • Which algorithm you choose depends upon your goals

    • Critical timing constraints MUST be met

    • Most RTOSs use preemptive multitasking scheme

    Instructor: G. Rudolph, Summer 2008


    Scheduling points

    Scheduling Points

    • Task Creation

    • Task deletion

    • Clock Tick

    • Task Block

    • Task Unblock

    Instructor: G. Rudolph, Summer 2008


    Tasks threads

    Tasks/Threads

    • States: Ready, Running, Waiting, Dead

      • See Fig 10-4 pg. 180 of text

    • Current task will run until

      • it terminates

      • a higher task is ready to run

      • it blocks waiting for external event or resource

    • Scheduler most often uses a Priority Queue for each non-running state to keep track of tasks

    • Each task has its own Call Stack and Context

    Instructor: G. Rudolph, Summer 2008


    Task starvation

    Task Starvation

    Problems

    • Processor overload

    • Low-priority tasks never get to run

    • A bug in the code

      Solutions

    • Faster Processor

    • Different algorithm

    • Fix all bugs

    Instructor: G. Rudolph, Summer 2008


    Task behavior

    Task Behavior

    • Code becomes a collection of tasks

    • Don’t know in which order tasks will be executed

    • Use “Run-to-completion” semantics when writing code

    Init task-specific

    resources

    Wait for event

    Handle Event/Do Work

    Instructor: G. Rudolph, Summer 2008


    Intertask communication

    Intertask Communication

    • Goal: Avoid disabling interrupts

    • Mutex (binary flag) and Semaphore (counter)

      Dangers

    • Deadlock

    • Priority Inversion

    Instructor: G. Rudolph, Summer 2008


    Message queue

    Message Queue

    • Pass messages between tasks using a Queue

    • Tasks + Message Queues + Eventsform the basis for coding reactive FSM frameworks

    Instructor: G. Rudolph, Summer 2008


    Really real time

    Really Real-time

    • Tasks have deadlines—a late answer is as bad as a wrong one

      • best, worst and average interrupt handling times

    • Deterministic

      • Can calculate worst-case execution time of any system call

    • Time Used for Context Switch

    Instructor: G. Rudolph, Summer 2008


  • Login