Applications and RTOSs - PowerPoint PPT Presentation

Applications and rtoss
Download
1 / 16

  • 81 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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

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