DOC PREVIEW
UNCC ECGR 4101 - Context Switch f-kalins

This preview shows page 1-2-3 out of 9 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 9 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

any different kinds of task schedulers areavailable to software developers of embed-ded and real-time systems. They rangefrom a simple cyclic executive that you canbuild “at home,” to the many priority-based preemptive schedulers that are avail-able commercially and beyond. Table 1 shows a number of task schedulers, including thesorts of software tasks and hardware device interfaces theysupport. Depending on the nature of your application andyour I/O requirements, you can choose the appropriateone from a wide spectrum of schedulers that will bedescribed here.The endless loopFor very simple embedded systems, the most basic way towrite application software is as an endless loop. The activi-ties programmed within the loop are executed in sequence.Branches and nested loops are okay, as long as when thecode is done executing, it loops back to the beginning foranother go-round. For example (in pseudocode) :DO FOREVERRequest Input Device make a MeasurementWait for the Measurement to be readyFetch the Value of the MeasurementProcess the Value of the MeasurementIF Value is ReasonableTHEN Prepare new Result using ValueELSE Result will be an Error ReportRequest Output Device deliver the ResultWait for the Result to be outputConfirm that output is OKEND DOThis style of programming works well in some simpleembedded systems, especially if the software can completethe sequence of code and loop around quickly enough. Butin other embedded systems, this style of programming willresult in performance that is too slow. Keep in mind thatinterrupts from hardware devices can’t be handled in this94 FEBRUARY 2001 Embedded Systems ProgrammingDAVID KALINSKYfeatureContext SwitchFrom the humble infinite loop to the priority-based preemptive RTOS and beyond,scheduling options are everywhere to be found. This article offers a survey and comparison.MRETURNEmbedded Systems Programming FEBRUARY 2001 95style of programming. Devices interactwith software in the loop only whenpolled.Basic cyclic executiveIn more complex embedded systems,the idea of the endless loop can beextended. These systems have hun-dreds or thousands of lines of code, sosoftware designers like to organize thecode into separate units referred to astasks. These tasks (sometimes alsocalled processes) should be as indepen-dent as possible so that they deal withseparate application issues and inter-act very little with one another.In a software design using a basiccyclic executive, these tasks execute instandard sequence within an infinitelyrepeating loop, as shown in Figure 1.This is much like the endless loopdesign, but now dealing with largetasks. These tasks can pass information toone another easily, by writing andreading shared data. That’s becauseevery task always runs to completionbefore another task begins running.So there’s no danger of a task gettingincomplete data from another task.Here too, interrupts from hard-ware devices can’t be handled. Devicesmust be polled, if they are to interactwith tasks in the loop.In some sense, this can be thoughtof as “real-time” task scheduling, if allof the software in the loop executesquickly and the loop can executerepeatedly at a very rapid rate.Time-driven cyclic executiveFor some applications, the view of“real-time” taken by a basic cyclic exec-utive is not precise enough. A basiccyclic executive tries to run its tasks asquickly and as often as possible. Inmore sophisticated applications, preci-sion of timing is often more importantthan raw speed.A time-driven cyclic executive canbegin to address this requirement. Inthis scheme, one hardware timer inter-rupt is used to trigger the execution ofall tasks. The tasks execute one afteranother, each one running to comple-tion before the next one begins. For atime-driven cyclic executive to workcorrectly, the final task in the chain oftasks must complete its executionbefore the next timer interruptarrives, as shown in Figure 2. The rateof hardware timer interrupts is therate at which the tasks must execute. For some applications, the view of “real-time” taken by a basic cyclicexecutive is not precise enough. In more sophisticated applications,precision of timing is often more important than raw speed.SKELETON STOODIOSTABLE 1 Some categories of task schedulersTask scheduler type Task execution Device I/OEndless loop No tasks Polled onlyBasic cyclic executive As often as possible Polled onlyTime-driven cyclic executive Single frequency Polled onlyMulti-rate cyclic executive Multiple frequencies, at Polled onlyhigher precisionMulti-rate executive with interrupts Multiple frequencies, at Polled and higher precision interrupt-drivenPriority-based preemptive scheduler Periodic and non-periodic Polled andtasks interrupt-drivenDeadline scheduler Periodic and non-periodic Polled andtasks interrupt-drivenFIGURE 1 Basic cyclic executiveAlthough a hardware timer inter-rupt is involved here, tasks can stillpass information to one another easily,by writing and reading shared data.Every task runs to completion beforeanother task begins running.Interrupts from hardware devices(other than the timer) cannot be han-dled in this style of programming.Devices must be polled, if they are tointeract with tasks.Multi-rate cyclic executiveThe time-driven cyclic executiveassumes that all tasks need to run atthe same rate of repetition. But insome applications, different tasks mayneed to run at different rates.A modified time-driven cyclic exec-utive, called the multi-rate cyclic exec-utive, can handle this need reasonablywell in cases where a higher rate is aninteger multiple of the “base” rate.The idea is simple. In a multi-ratecyclic executive, the base-rate tasksrun once per timer interrupt, and ahigher rate task runs a number oftimes per timer interrupt. That num-ber is the integer multiple of the baserate. The repeated executions of thehigher rate task should be as equallyspaced as possible within the sequenceof tasks following a timer interrupt.Often the base-rate period is calledthe “major cycle,” and higher ratesidentify so-called “minor cycles.” The example illustrated here showsa system of 10 tasks which execute atthe base rate (for example, 10Hz, ifthe timer delivers 10 interrupts persecond). In addition, an eleventh task,marked by a star, executes at 40Hz,four times the base rate. This is doneby having the starred task appear fourtimes in the chain of task executionwhich follows each timer interrupt, asshown in Figure


View Full Document

UNCC ECGR 4101 - Context Switch f-kalins

Documents in this Course
Load more
Download Context Switch f-kalins
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Context Switch f-kalins and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Context Switch f-kalins 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?