applications and rtoss n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Applications and RTOSs PowerPoint Presentation
Download Presentation
Applications and RTOSs

Loading in 2 Seconds...

play fullscreen
1 / 16

Applications and RTOSs - PowerPoint PPT Presentation


  • 89 Views
  • Uploaded on

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

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

PowerPoint Slideshow about 'Applications and RTOSs' - christina-stathis


Download Now 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
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

slide6
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