[教学]嵌入式实时操作系统介绍 - 行业应用项目实施 - LoveUnix -- 最强AIX小机技术论坛,UNIX,Linux,存储,数据库,中间件,开发,管理 -- 蓝色的IBM技术天堂 --bbs.LoveUnix.net

carol

荣誉斑竹

幻想懒王++

UID 1859
精华 66
积分 5135
帖子 10000
活跃指数 32
LU金币 2590 个
LU金条 0 个
阅读权限 200
注册 2003-11-7

大中小

使用道具

发表于 2004-5-11 12:40 资料个人空间短消息加为好友

申明，此教程转载自 http://www.codewarrioru.com，仅作为个人学习交流之用，若触犯版权，马上删除

。稍候附上简单的中文笔记

原作者：Michael Winge user posted image

Why Use a Real Time Operating System (RTOS)?<o:p></o:p>
The main reason for using a RTOS is that the application has real time requirements. Real time requirements exist when two or more processes need to run at the same time, e.g. one process is doing some calculation while another process waits for more input; or a network communication needs to be executed while another process runs another part of a system's functionality. Doing one after the other would not be acceptable because of timing reasons.<o:p></o:p>
Many applications have these real time requirements and do not use a RTOS. In actual fact, they already implement the basic part of a RTOS i.e. a scheduler that enables the processor to deal with different processes. <o:p></o:p>
Apart from real time requirements, there are more reasons why a system designer might want to use a RTOS when developing an embedded system. A RTOS provides a standard API (application programming interface) which:<o:p></o:p>
<UL type=disc>
<LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt"><ITEM>hides implementation issues from application developers. The developer does not need to know the details of how the RTOS is implemented; an interface (API) is used to control the RTOS' functionality. </ITEM><o:p></o:p></LI>
<LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt"><ITEM>simplifies hardware changes because the RTOS provides a common API for the hardware. Hardware functionality can be used through the RTOS API that is independent of the specifics of the underlying hardware. </ITEM><o:p></o:p></LI>
<LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt"><ITEM>simplifies software system design. The RTOS interfaces give the application a structure by breaking down the application into manageable parts. It is more flexible for future scheduling changes, new processes can be included and timings can be changed through the API existing application parts remain unchanged. </ITEM><o:p></o:p></LI>
<LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l0 level1 lfo1; tab-stops: list 36.0pt"><ITEM>provides capability for software re-use. The RTOS enforces the discipline of structuring an application into manageable parts. These parts can be re-used again in future applications where the requirements are similar. </ITEM><o:p></o:p></LI></UL>
<H3 style="MARGIN: auto 0cm">What is an embedded RTOS?<o:p></o:p></H3>
Before going into the details of what a RTOS is, it should be discussed how "operating system" and "real time" can be defined, and what is special about "embedded" real time operating systems compared with others.<o:p></o:p>

carol

荣誉斑竹

幻想懒王++

UID 1859
精华 66
积分 5135
帖子 10000
活跃指数 32
LU金币 2590 个
LU金条 0 个
阅读权限 200
注册 2003-11-7

大中小

使用道具

发表于 2004-5-11 12:47 资料个人空间短消息加为好友

Embedded RTOS: What is an operating system?
An operating system manages the resources (CPU, memory, peripherals, etc…) and performs basic tasks, such as recognizing input from a keyboard or mouse, sending output to a monitor, keeping track of files and directories on disk, and controlling peripherals such as a printer. It also provides the interface between the applications being used and the hardware, providing effective communication from a high level that can be understood by the user, to a low level that can be understood by the hardware. It uses an interface for making hardware manipulation easier for the programmer who does not need to have a deep knowledge of the hardware. The operating system is a major factor in software reliability and overall productivity.< ?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>
Figure 1 illustrates the central role of the operating system.
<IMG alt="Figure 1-1: Overview of the role of an operating system" src="http://www.codewarrioru.com/coursecontent/rendered/qaregion/OSEKIntro/OSEKIntro_lesson01/OSEK_Intro_Fig01_01.jpg" type="graphic"> Figure 1-1: Overview of the role of an operating system 
<H3 style="MARGIN: auto 0cm">What is an embedded operating system?<o:p></o:p></H3>
In embedded applications mostly microcontroller are used versus pure processors, which have memory and peripherals external from the CPU (like in desktop systems). Microcontroller have memory and peripherals "on chip", means on the same chip as the CPU, and memory is usually more available as ROM (EEPROM, Flash) than as RAM. Peripherals can be for example communication interfaces, analog to digital converters, timers, pin I/O. Due to this deep integration on one chip, microcontrollers usually have less performance than pure processors. This constitutes different requirements for embedded operating systems versus desktop operating systems.<o:p></o:p>
 <o:p></o:p>
Since there is a limited amount of memory and processing capacity on chip, the OS running on such hardware must be very small and fast. In terms of user interfaces, an embedded OS usually does not have to handle complex displays and other common peripherals found on desktop computers, and the features are therefore fairly basic. In addition, many system properties can be made static and defined before runtime, which avoids performing the system setup during runtime and reduces the necessary code. With such a reduced feature set it is possible to get less overhead with reduced memory usage (both RAM and ROM) and a high performance. The code of the embedded OS and the application mostly reside in ROM due to the lack of RAM.<o:p></o:p>
 <o:p></o:p>
Furthermore, an embedded OS can save additional resources due to high scalability. It is possible to scale down size and improve performance by having only the necessary OS features for a special application. This can be reached very efficiently if the OS is available as source code and by using compiler switches. Only the necessary features will be compiled and linked together with the application. Because the OS is tailored for the application, an embedded operating system integrates the application and the OS into one unit. Typical systems that use embedded operating systems are household appliances, motor control systems etc.<o:p></o:p>

carol

荣誉斑竹

幻想懒王++

UID 1859
精华 66
积分 5135
帖子 10000
活跃指数 32
LU金币 2590 个
LU金条 0 个
阅读权限 200
注册 2003-11-7

大中小

使用道具

发表于 2004-5-11 12:53 资料个人空间短消息加为好友

Embedded RTOS: What is real time? <o:p></o:p>
The most common misconception associated with real-time performance is that it increases the execution time of your program. While this is true in some cases it is not definitive, real-time is more a question of being "on time". A real time operating system enhances your application by providing more precise and predictable system behavior. With these enhancements, you can determine the exact time when a reaction or a response to certain events will be available, thereby making it a deterministic system. A process is executed in real-time if it is processed fast enough and if it is finished on time (before the deadline). To know whether a process is on time or not, it is necessary to know the processing time (i.e. it must be predictable).<o:p></o:p>
There are two types of real time: hard and soft. The difference can be explained by the difference of cost (or impact) against processing time of a process.<o:p></o:p>
Figure 2 illustrates the differences between hard and soft real time systems.<o:p></o:p>
<v:shapetype id=_x0000_t75 stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"><v:stroke joinstyle="miter"></v:stroke><v:formulas><v:f eqn="if lineDrawn pixelLineWidth 0"></v:f><v:f eqn="sum @0 1 0"></v:f><v:f eqn="sum 0 0 @1"></v:f><v:f eqn="prod @2 1 2"></v:f><v:f eqn="prod @3 21600 pixelWidth"></v:f><v:f eqn="prod @3 21600 pixelHeight"></v:f><v:f eqn="sum @0 0 1"></v:f><v:f eqn="prod @6 1 2"></v:f><v:f eqn="prod @7 21600 pixelWidth"></v:f><v:f eqn="sum @8 21600 0"></v:f><v:f eqn="prod @7 21600 pixelHeight"></v:f><v:f eqn="sum @10 21600 0"></v:f></v:formulas><v:path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></v:path><o:lock aspectratio="t" v:ext="edit"></o:lock></v:shapetype><IMG alt="Figure 1-2: A real time system responds to input in a predictable
time duration" src="http://www.codewarrioru.com/coursecontent/rendered/qaregion/OSEKIntro/OSEKIntro_lesson01/OSEK_Intro_Fig01_02.jpg" type="graphic"> Figure 1-2: A real time system responds to input in a predictable time duration <o:p></o:p>
Hard real time systems have a strictly defined time requirement. In this type of system a process deadline (the maximal time duration where the process result has to be ready) must always be met, otherwise the system malfunctions and an unacceptable loss occurs (e.g. an airbag fires too late) which represents an infinite high cost (impact).<o:p></o:p>
In a soft real time system the time requirement is also important however, if the time requirement is not fulfilled the system will still function correctly, but some performance is lost (for example, in real time video transmission). In such a case the cost (impact) is reaching a maximum (in real time video transmission the maximum cost would be a still picture whether it is still for one minute or one hour).<o:p></o:p>
The overall system (application), not the RTOS itself, determines the real time requirements and therefore whether it is a hard or a soft real time system.<o:p></o:p>
<H3 style="MARGIN: auto 0cm">What is an embedded RTOS?<o:p></o:p></H3>
A RTOS, or real time operating system, can handle multiple simultaneous problems (processes, often called tasks). It is a predictable system where tasks execute at the same processing time at different points in time. It schedules tasks for execution by assigning priorities and provides efficient resource management. Systems with real time requirements (hard and soft) use a RTOS, and not a general-purpose operating system such as DOS and UNIX, neither of which is a RTOS.<o:p></o:p>
 <o:p></o:p>
The characteristics of an "embedded" RTOS are: very small, fast, execute from ROM, highly scalable, statically defined, basic functionality, usually without a graphical user interface.<o:p></o:p>
 <o:p></o:p>
OSEK/VDX OS fulfills all these requirements.<o:p></o:p>
<H3 style="MARGIN: auto 0cm">The Basics of a RTOS <o:p></o:p></H3>
The next pages discuss the very basics in RTOS theory: The task model, scheduling and resource management.<o:p></o:p>

carol

荣誉斑竹

幻想懒王++

UID 1859
精华 66
积分 5135
帖子 10000
活跃指数 32
LU金币 2590 个
LU金条 0 个
阅读权限 200
注册 2003-11-7

大中小

使用道具

发表于 2004-5-11 13:02 资料个人空间短消息加为好友

RTOS Basics: The Task Model (Multitasking)<o:p></o:p>
This section describes how tasks (processes) are modeled inside a RTOS.<o:p></o:p>
In a real time system a problem is subdivided into several parts, and each part is executed according to its real-time requirements. Each of these parts can be considered as a 'task' as shown in Figure 3.<o:p></o:p>
<IMG alt="Figure 1-3: A problem can be broken down into n tasks that are
processed individually" src="http://www.codewarrioru.com/coursecontent/rendered/qaregion/OSEKIntro/OSEKIntro_lesson01/OSEK_Intro_Fig01_03.jpg" type="graphic">
Figure 1-3: A problem can be broken down into n tasks that are processed individually 
Because of real time requirements, these tasks have to be processed simultaneously, a sequential processing would not meet their timing requirements. While simultaneous task execution without a RTOS would require several CPUs (one CPU per task). Only one CPU is required for simultaneous task execution with a RTOS if the processing capacity of this CPU is enough for the real time requirements of the application. In this case the tasks compete against each other for the processor and for other hardware resources (e.g. memory, or an I/O port).<o:p></o:p>
To organize the task competition for the processor, a task-state model defines task states at any point in the system runtime. It also defines when and why which task states change (task state transitions). Each RTOS defines such a task-state model.<o:p></o:p>
As an example, the OSEK/VDX OS task-state model is shown in Figure 4. It has 3 main states for a task and one optional state.<o:p></o:p>
<IMG alt="Figure 1-4: Task states and transitions" src="http://www.codewarrioru.com/coursecontent/rendered/qaregion/OSEKIntro/OSEKIntro_lesson01/OSEK_Intro_Fig01_04.jpg" type="graphic">
Figure 1-4: Task states and transitions <o:p></o:p>
The task states and transitions shown in Figure 4 are:<o:p></o:p>
<UL type=disc>
<LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l0 level1 lfo3; tab-stops: list 36.0pt"><ITEM>Suspended – This is the default state of a task at the system start. In this state the task is inactive. Through an activation, with a RTOS function, the task transitions into the Ready state. </ITEM><o:p></o:p></LI>
<LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l0 level1 lfo3; tab-stops: list 36.0pt"><ITEM>Ready – The task is active in the Ready state and waits to get the Running state. the scheduler, part of the RTOS, decides when the transition to the Running state will take place, it can also set the task back to the Ready state, dependent on special algorithms and states of other tasks.</ITEM> <o:p></o:p></LI>
<LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l0 level1 lfo3; tab-stops: list 36.0pt"><ITEM>Running – In the running state the task gets the processor to execute the task instructions, only one task can be in this state at a point in time. In this state, a RTOS function (service) can transit the task back to the Suspended state. Doing this, the task stops execution and deactivates. Another RTOS service can be used to change the task into the Waiting state, where the task also stops execution, but remains active. </ITEM><o:p></o:p></LI>
<LI class=MsoNormal style="MARGIN: 0cm 0cm 0pt; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto; mso-list: l0 level1 lfo3; tab-stops: list 36.0pt"><ITEM>Waiting – A particular task waits on an event (other RTOS service) in this state. If this event is set, the task changes to the Ready state. This is an optional state in OSEK/VDX OS tasks. </ITEM><o:p></o:p></LI></UL>

carol

荣誉斑竹

幻想懒王++

UID 1859
精华 66
积分 5135
帖子 10000
活跃指数 32
LU金币 2590 个
LU金条 0 个
阅读权限 200
注册 2003-11-7

大中小

使用道具

发表于 2004-5-11 13:11 资料个人空间短消息加为好友

RTOS Basics: Scheduling Tasks
In order to efficiently coordinate task competition for the processor, a scheduler is used to decide which task the processor executes and when. <o:p></o:p>
There are two basic scheduling strategies: preemptive and non-preemptive (cooperative) scheduling. <o:p></o:p>
In a preemptive system, a task can be preempted (i.e.interrupted) during its execution time, meaning the scheduler can switch to another task at any time dependant on the system stage. Preemption is good for tasks with long execution times; more important tasks can preempt less important tasks in order to efficiently use the existing processor capacity.<o:p></o:p>
In a non-preemptive system, each task occupies the CPU for as long as it executes. A task switch does not occur unless the task in control voluntarily relinquishes control of the processor (i.e. terminates).<o:p></o:p>
Two basic types of scheduling exist: static scheduling (time control) and dynamic scheduling (event control). With static scheduling, there is a predefined sequence in which the tasks execution will be performed. With dynamic scheduling the decision to execute a task is determined at run time based on the state of the system. The scheduler adapts to the current task situation. With dynamic scheduling the processor capacity is more efficiently used because activities are only started when necessary (when an outside event happened), and is not dependent on a static schedule.<o:p></o:p>
<H3 style="MARGIN: auto 0cm">Possible Scheduling Methods<o:p></o:p></H3>
There are many schemes for scheduling tasks. In this section we will look at three common ones: priority control, time slice, and first in first out (FIFO). Multiple schemes could be combined in a operating system.<o:p></o:p>
 <o:p></o:p>
In a priority-controlled scheduler, each task is assigned a priority by the operating system depending on its importance. Priorities allow the developer to control how fast a task is getting runtime or how often a task is running. This results in higher priority tasks being completed faster . In a possible implementation, the tasks are placed into different priority queues (in one queue all tasks have the same priority). Tasks are scheduled from the head of a given queue only if all queues of higher priority are empty. Within each of the priority queues, tasks must be scheduled as well. Since priority is the same, some other mechanism must be used to determine the ordering. This could be FIFO or some other technique. Typically, priority-control is combined with dynamic scheduling, the order of execution is not static, and combined with preemptive scheduling to allow preemption for higher priority tasks.<o:p></o:p>
 <o:p></o:p>
Time slice (also known as 'round robin') is the next method of scheduling. A small unit of time, called a time slice or quantum, is defined for each task to run. In the easiest case all time slices have the same duration, but they can also have different durations. All tasks able to run are kept in a circular queue, activated tasks are added to the tail of the queue. The CPU scheduler goes around this queue, allocating the CPU to each task for a time interval of one time slice. The end of a time slice can be a hard deadline and the task gets terminated, or the task will be stopped (preempted) and might finish running in the next time slice for this task at the tail of the queue. If the task finishes before the end of the time slice, the task itself releases the CPU voluntarily. In either case, the CPU scheduler assigns the CPU to the next task in the queue. Time-slicing is often used when there are multiple tasks of equal priority and those tasks are competing for the CPU. Time slice is one of the simplest and most widely used scheduling algorithms, but such scheduling does not use the processor capacity in the most efficient way. This is because the CPU is always running idle when a task is terminated before the end of the time slice and before the next task gets the CPU.<o:p></o:p>
 <o:p></o:p>
FIFO (First In First Out or Fist Come First Serve) queuing is the most basic queue scheduling discipline. In FIFO queuing, all tasks are treated equally by placing them into a single queue. They are serviced in the same order as they were placed into the queue. This is a very simple scheduling mechanism that is appropriate in less-complex or order-dependent systems.<o:p></o:p>
 <o:p></o:p>
An OSEK/VDX OS example using a priority based, dynamic scheduling: The software developer determines task execution sequence via task priorities and selected scheduling mechanisms. Only activated tasks become the "ready" status and get entered into the priority queues. Figure 5 illustrates a series of tasks being performed by a processor where the order of task execution is defined by the scheduler dependent on priority and activation order.<o:p></o:p>
<IMG alt="Fig 1-5. Scheduler and task priorities using FIFO
(First-In-First-Out) order to process tasks. " src="http://www.codewarrioru.com/coursecontent/rendered/qaregion/OSEKIntro/OSEKIntro_lesson01/OSEK_Intro_Fig01_05.jpg" type="graphic"> Fig 1-5. Scheduler and task priorities using FIFO (First-In-First-Out) order to process tasks. 
In OSEK/VDX OS tasks can be either preemptive or non-preemptive, depending on the task configuration<o:p></o:p>
 <o:p></o:p>

carol

荣誉斑竹

幻想懒王++

UID 1859
精华 66
积分 5135
帖子 10000
活跃指数 32
LU金币 2590 个
LU金条 0 个
阅读权限 200
注册 2003-11-7

大中小

使用道具

发表于 2004-5-11 13:18 资料个人空间短消息加为好友

RTOS Basics: Synchronizing Resource access
A RTOS typically defines a resource management to synchronize tasks while accessing resources.<o:p></o:p>
The definition of a resource in this context includes both hardware (e.g. memory, I/O port) and software (global functions and global variables). Resources are accessible to all tasks in a real time system, but obviously care must be taken to ensure that different tasks don’t attempt to use the same resource in conflicting ways. In preemptive systems, tasks can be preempted during a resource access. When that happens, another task might access the same resource and creates an inconsistent state because the resource access of the other task might be incomplete. Resource managers prevent the simultaneous access to a resource in preemptive systems by synchronizing the tasks to avoid this situation. Like task scheduling, there are several protocols for controlling resources. In this section we discuss three common ones: semaphore protocol, priority ceiling protocol, and highest locker's priority protocol.<o:p></o:p>
<H3 style="MARGIN: auto 0cm">Semaphore Protocol<o:p></o:p></H3>
With the semaphore method, a task that is about to use a resource sets a flag (semaphore) that says the resource is in use. A task can only get a resource if no other task holds this resource (assignment in FIFO-principle). While this is a valid, simple, and straightforward control system, it does have known problems. The problems with semaphores are priority inversion and deadlocks. 
<o:p></o:p> 
Priority inversion is the term for the scenario where a higher priority task fails to run when it should, but a lower priority task can run instead. 
<o:p></o:p> 
Figure 6 illustrates the priority inversion problem: Priority inversion can happen when a higher priority task (Task 3) has to wait on a resource which is occupied by a preempted low priority task (Task 1). A task with a priority between Task 1 and Task 3 (like Task 2) now has the chance to run in the meantime. By running this task, Task1 is prevented from releasing the resource which Task 3 is waiting on. The situation can only be resolved by a termination of Task2, but this means Task 2 runs before the higher priority task (priority inversion).<o:p></o:p>
 <v:shapetype id=_x0000_t75 stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600"><v:stroke joinstyle="miter"></v:stroke><v:formulas><v:f eqn="if lineDrawn pixelLineWidth 0"></v:f><v:f eqn="sum @0 1 0"></v:f><v:f eqn="sum 0 0 @1"></v:f><v:f eqn="prod @2 1 2"></v:f><v:f eqn="prod @3 21600 pixelWidth"></v:f><v:f eqn="prod @3 21600 pixelHeight"></v:f><v:f eqn="sum @0 0 1"></v:f><v:f eqn="prod @6 1 2"></v:f><v:f eqn="prod @7 21600 pixelWidth"></v:f><v:f eqn="sum @8 21600 0"></v:f><v:f eqn="prod @7 21600 pixelHeight"></v:f><v:f eqn="sum @10 21600 0"></v:f></v:formulas><v:path o:connecttype="rect" gradientshapeok="t" o:extrusionok="f"></v:path><o:lock aspectratio="t" v:ext="edit"></o:lock></v:shapetype><IMG alt="Figure 1-6: Occurrence of priority inversion" src="http://www.codewarrioru.com/coursecontent/rendered/qaregion/OSEKIntro/OSEKIntro_lesson01/OSEK_Intro_Fig01_06.jpg" type="graphic"> Figure 1-6: Occurrence of priority inversion 
 
Semaphores can also result in deadlocks. Assume two tasks share two resources and lock them in different orders. One task (Task A) locks the first resource using semaphore S1. Then, in the ordinary course of events a second task (Task

runs and locks the second resource with semaphore S2. It needs to use the first resource (S1), but cannot because it is locked by the first task (Task A). All it can do is pass control back to the first task (Task A), which then attempts to use the second resource (S2). It cannot use it because the second task (Task

has locked it, so it passes control back to the second resource. But the second resource cannot run, so it passes control back to the first task, endlessly. The two tasks are deadlocked because each is waiting on a semaphore locked by the other task. Figure 7 illustrates this situation.<o:p></o:p>
<IMG alt="Figure 1-7: Two tasks reaching deadlock" src="http://www.codewarrioru.com/coursecontent/rendered/qaregion/OSEKIntro/OSEKIntro_lesson01/OSEK_Intro_Fig01_07.jpg" type="graphic"> Figure 1-7: Two tasks reaching deadlock 
<H3 style="MARGIN: auto 0cm">Priority Ceiling Protocol<o:p></o:p></H3>
With the priority ceiling protocol, each resource gets its own ceiling priority. The ceiling priority of the resource is equivalent to the priority of the highest priority task that may use this resource. A task will get the resource’s ceiling priority during the access of that resource and get its old priority back after the access. All tasks below the ceiling priority cannot preempt other tasks, therefore all other tasks using the same resource cannot preempt. Preemption can only take place after the resource access is completed and the original task's priority is restored.
<o:p></o:p> 
This method prevents preemption, which is the primary cause of possible resource conflicts. Therefore problems like priority inversion and deadlocks cannot happen. The main disadvantage however, is that all lower priority tasks get locked out, even when they are not using the resource.
<o:p></o:p> 
OSEK/VDX OS uses this approach for resource management.<o:p></o:p>
<H3 style="MARGIN: auto 0cm">Highest Locker's Priority Protocol<o:p></o:p></H3>
This protocol is similar to the priority ceiling protocol except with the possibility that a task, not using the resource and with a lower priority than the priority of a particular resource, can preempt the tasks with original lower priority using that resource. To achieve this, the scheduler needs to consider two task priorities, the original priority and the resource priority of a task.<o:p></o:p>
<H3 style="MARGIN: auto 0cm">Summary<o:p></o:p></H3>
This section introduced you to some of the concepts involved with synchronizing access to shared resources. Some of these protocols are intricate with subtle side effects. The principal point to take away from this section is that an RTOS must control simultaneous access to shared resources, and that the mechanism used can have significant consequences with regard to how tasks are scheduled.<o:p></o:p>
 <o:p></o:p>

hsia

LU幼天使

UID 1418
精华 0
积分 29
帖子 57
活跃指数 2
LU金币 2015 个
LU金条 0 个
阅读权限 20
注册 2003-11-1
来自吉林长春

大中小

使用道具

发表于 2004-7-3 14:40 资料个人空间短消息加为好友

“稍候”中文笔记，是时候了。只是不能太简单了。

C/C++能做所有的事，我讨厌数据库。

carol

荣誉斑竹

幻想懒王++

UID 1859
精华 66
积分 5135
帖子 10000
活跃指数 32
LU金币 2590 个
LU金条 0 个
阅读权限 200
注册 2003-11-7

大中小

使用道具

发表于 2004-7-3 14:51 资料个人空间短消息加为好友

重点已经彩色标出来了

fengwy

LU小天使

UID 189
精华 0
积分 312
帖子 624
活跃指数 0
LU金币 2011 个
LU金条 0 个
阅读权限 20
注册 2003-9-28

大中小

使用道具

发表于 2004-7-5 17:09 资料个人空间短消息加为好友

急切等待中文笔记。

[广告] 记录自己的思想火花，留住每日的技术积累，尽在拥有属于自己独立域名的博客。

carol

荣誉斑竹

幻想懒王++

UID 1859
精华 66
积分 5135
帖子 10000
活跃指数 32
LU金币 2590 个
LU金条 0 个
阅读权限 200
注册 2003-11-7

#10

大中小

使用道具

发表于 2004-7-8 21:37 资料个人空间短消息加为好友

translated and noted by Carol
from www.loveunix.net
------------------------------------------
为啥要用实时操作系统呢?
最主要的原因就是：应用有实时的需求。
当两个或多个进程需要同时运行时，就存在实时的需求了，比如：一个进程在做计算而另一个进程在等待输入，或者，一个网络通讯需要执行同时另一个进程在泡另一部分的系统功能。由于时间的原因，一个挨一个的做是无法接受的。

很多应用有这样的实时需求，但并不一定使用实时操作系统。事实上，这些操作已经实现了rtos 的基本部分。比如，使处理器可以处理不同进程的调度器(scheduler).

除了实时的需求，还有许多理由使系统设计师在开发嵌入式系统的时候想要使用 RTOS. RTOS 提供了标准的API：
* 对应用开发者隐藏了实现的细节
* 因为RTOS为硬件提供了通用的 API，因此简化了硬件的改变。
* 简化了软件系统的设计
* 提供了软件重用的能力

[广告] 论坛新开【DB2产品家族】【投资理财】【行业应用】板块

carol

荣誉斑竹

幻想懒王++

UID 1859
精华 66
积分 5135
帖子 10000
活跃指数 32
LU金币 2590 个
LU金条 0 个
阅读权限 200
注册 2003-11-7

#11

大中小

使用道具

发表于 2004-7-8 22:03 资料个人空间短消息加为好友

translated and noted by Carol
from www.loveunix.net
------------------------------------------

什么是操作系统？

什么是嵌入是操作系统？
嵌入式应用中，大多式使用微控制器(microcontroller)而不是纯粹的处理器。
由于微控制器上的存储器和处理器能力有限，因此要求在上面跑的os 小而且快。就用户接口而言，embedded OS 不需要处理复杂的显示和台式机上的常用外围设备，因此都采用最基本的外围设备。
另外，很多系统特性可以是静态的，并且在运行前定义，这就可避免在运行时进行系统安装，减少必要的代码。
由于 RAM 的缺少，embedded OS 和应用的代码大多是放在 ROM 里的。

此外，embedded OS 可以针对特定的应用，只保留必需的 OS feature 来改善性能。如果 OS 有源代码，并且有 compiler switches 的话，这种方法是可以有效达到的。—— 只有必需的特性会被编译病连接到应用中去。

[广告] 论坛新开【DB2产品家族】【投资理财】【行业应用】板块

carol

荣誉斑竹

幻想懒王++

UID 1859
精华 66
积分 5135
帖子 10000
活跃指数 32
LU金币 2590 个
LU金条 0 个
阅读权限 200
注册 2003-11-7

#12

大中小

使用道具

发表于 2004-7-8 22:27 资料个人空间短消息加为好友

translated and noted by Carol
from www.loveunix.net
------------------------------------------

什么是实时？

就是要及时。on time: 准时
RTOS 通过提供更准确的，更有预测性的系统行为来改善应用。
这些改善可以使你确定准确的时间，什么时候做出反应，什么时候响应某一个事件，因此时期成为一个可确定的（deterministic）系统。
要知道一个进程是否处理及时，就需要知道处理的时间（predictable）

有两种实时：硬的，软的。
硬实时系统对时间需求有严格的定义。
软实时系统对时间要求也很重要，如果时间要求没有达到，系统的功能还是正常的，但是有些性能就丢失了。
整个应用，而不是 rtos 本身，决定了对实时的需求，并且选择是硬的还是软的。

什么是嵌入式 RTOS 呢？

RTOS 可以同时处理多任务。
通过分配优先权，提供有效的资源管理来调度要执行的任务。

Embedded RTOS 呢~ 是很小的，快的，在ROM中执行的，具有高裁减性的，静态定义的，具有基础功能的，通常没有图形界面

[广告] 论坛新开【DB2产品家族】【投资理财】【行业应用】板块