[教学]嵌入式实时操作系统介绍(页 1) - 行业应用项目实施 - LoveUnix 最强AIX小机技术论坛,UNIX,Linux,存储,数据库,中间件,开发,管理

2004-5-11 12:40 carol

申明，此教程转载自 <a href='http://www.codewarrioru.com，' target='_blank'>http://www.codewarrioru.com，</a> 仅作为个人学习交流之用，若触犯版权，马上删除 <img src='style_emoticons/default/awkard.gif' border='0' style='vertical-align:middle' alt='awkard.gif' /> 。稍候附上简单的中文笔记 原作者：Michael Winge <img src='http://www.codewarrioru.com/faculty/OSEK_author.jpg' border='0' alt='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>

2004-5-11 12:47 carol

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> &nbsp;<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> &nbsp;<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>

2004-5-11 12:53 carol

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> &nbsp;<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> &nbsp;<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>

2004-5-11 13:02 carol

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>

2004-5-11 13:11 carol

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> &nbsp;<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> &nbsp;<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> &nbsp;<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> &nbsp;<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> &nbsp;<o:p></o:p> &nbsp;

2004-5-11 13:18 carol

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>&nbsp; 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>&nbsp; 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 &nbsp; 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 <img src='style_emoticons/default/cool.gif' border='0' style='vertical-align:middle' alt='cool.gif' /> 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 <img src='style_emoticons/default/cool.gif' border='0' style='vertical-align:middle' alt='cool.gif' /> 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>&nbsp; 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>&nbsp; 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> &nbsp;<o:p></o:p>

2004-7-3 14:40 hsia

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

2004-7-3 14:51 carol

<img src='style_emoticons/default/icon_redface.gif' border='0' style='vertical-align:middle' alt='icon_redface.gif' /> 重点已经彩色标出来了

2004-7-5 17:09 fengwy

急切等待中文笔记。

2004-7-8 21:37 carol

translated and noted by Carol from www.loveunix.net ------------------------------------------ 为啥要用实时操作系统呢? 最主要的原因就是：应用有实时的需求。 当两个或多个进程需要同时运行时，就存在实时的需求了，比如：一个进程在做计算而另一个进程在等待输入，或者，一个网络通讯需要执行同时另一个进程在泡另一部分的系统功能。由于时间的原因，一个挨一个的做是无法接受的。 很多应用有这样的实时需求，但并不一定使用实时操作系统。事实上，这些操作已经实现了rtos 的基本部分。比如，使处理器可以处理不同进程的调度器(scheduler). 除了实时的需求，还有许多理由使系统设计师在开发嵌入式系统的时候想要使用 RTOS. RTOS 提供了标准的API： * 对应用开发者隐藏了实现的细节 * 因为RTOS为硬件提供了通用的 API，因此简化了硬件的改变。 * 简化了软件系统的设计 * 提供了软件重用的能力

2004-7-8 22:03 carol

translated and noted by Carol from www.loveunix.net ------------------------------------------ 什么是操作系统？ 什么是嵌入是操作系统？ 嵌入式应用中，大多式使用微控制器(microcontroller)而不是纯粹的处理器。 由于微控制器上的存储器和处理器能力有限，因此要求在上面跑的os 小而且快。就用户接口而言，embedded OS 不需要处理复杂的显示和台式机上的常用外围设备，因此都采用最基本的外围设备。 另外，很多系统特性可以是静态的，并且在运行前定义，这就可避免在运行时进行系统安装，减少必要的代码。 由于 RAM 的缺少，embedded OS 和应用的代码大多是放在 ROM 里的。 此外，embedded OS 可以针对特定的应用，只保留必需的 OS feature 来改善性能。如果 OS 有源代码，并且有 compiler switches 的话，这种方法是可以有效达到的。—— 只有必需的特性会被编译病连接到应用中去。

2004-7-8 22:27 carol

translated and noted by Carol from www.loveunix.net ------------------------------------------ 什么是实时？ 就是要及时。on time: 准时 RTOS 通过提供更准确的，更有预测性的系统行为来改善应用。 这些改善可以使你确定准确的时间，什么时候做出反应，什么时候响应某一个事件，因此时期成为一个可确定的（deterministic）系统。 要知道一个进程是否处理及时，就需要知道处理的时间（predictable） 有两种实时：硬的，软的。 硬实时系统对时间需求有严格的定义。 软实时系统对时间要求也很重要，如果时间要求没有达到，系统的功能还是正常的，但是有些性能就丢失了。 整个应用，而不是 rtos 本身，决定了对实时的需求，并且选择是硬的还是软的。 什么是嵌入式 RTOS 呢？ RTOS 可以同时处理多任务。 通过分配优先权，提供有效的资源管理来调度要执行的任务。 Embedded RTOS 呢~ 是很小的，快的，在ROM中执行的，具有高裁减性的，静态定义的，具有基础功能的，通常没有图形界面

2004-7-8 22:37 carol

接下来是 RTOS 的基础知识，三部分： 任务模式：multitasking 调度 资源管理 待续吧。。。

2004-7-8 23:04 无双

偶过来鼓掌了<img src='style_emoticons/default/rose.gif' border='0' style='vertical-align:middle' alt='rose.gif' /> carol做的事都不错的

2004-7-8 23:06 carol

<div class='quotetop'>QUOTE(无双 @ 2004-07-08 23:04:01)</div><div class='quotemain'> 偶过来鼓掌了<img src='style_emoticons/default/rose.gif' border='0' style='vertical-align:middle' alt='rose.gif' /> carol做的事都不错的 </div> 唉~~~~ 累s偶了~ 但愿偶也能学到点东西吧~

2004-8-20 11:47 icewood

Carol mm休息一下，我来翻译这段： RTOS Basics: The Task Model (Multitasking) 任务模型 这一部分描述在一个实时操作系统中任务的编模方式 在一个RTOS中，一个课题被分成几个部分，每一个部分根据他们对实时性的需求被执行。每一个部分可以被当作一个任务，如图三所示 因为实时的需要，这些任务需要并发处理。一个序列性的处理方法不能满足他们对实时性的需求。然而，如果没有RTOS，并发的任务处理将会需要多CPU。然而，在RTOS当中，只要CPU能力足够满足应用需要，我们就只需要一颗CPU来进行并发的任务处理。 为了处理好任务之间对处理器需求的兑争关系，我们用task-state模型定义在系统运行期间内任何一个时间点的任务状态。它同时也描述了什么时候因为什么原因哪一个任务的状态发生了变化（任务状态变迁）。任何RTOSf都会定义这样一个task-state模型。 示例，OSEK/VDX OS的task-state模型如图4所示。对每一个任务而言，这个模型定义了三个主要的状态和一个可选的状态。 我们在图4中看到任务有如下4种状态： Suspended 这是系统启动后的默认状态。在这种状态下，任务为inactive。通过RTOS的激活，任务状态可以过渡为Ready. Ready 任务在这种状态下是活动的并且等待进入Running状态。我们用RTOS的scheduler来决定在什么时候将处于Ready的任务过渡到Running状态，我们也用Scheduler来决定是否将任务变回到Ready状态，这取决于RTOS固有的算法以及其他任务的状态。 Runnig- 在这种状态下任务得到了CPU时间来执行它的指令。在同一个时间点，只有一个任务能够处于这种状态。我们用RTOS的一个Function来将这种状态下的任务变回Suspended状态，这样任务就停止执行并且deactivated.我们用另一个RTOS的Function来这种状态下的任务变到Waiting状态，这时任务同样停止了执行，但是保持活动状态。 Waiting – 在这种状态下的任务在event（RTOS的另外一个service）进行等待。如果这个event被设置了的话，任务就变回Ready状态。这是OSEK/VDX OS中任务的一个可选状态。

2004-8-20 11:48 icewood

每天翻一段

2004-8-20 13:01 carol

<img src='style_emoticons/default/laugh.gif' border='0' style='vertical-align:middle' alt='laugh.gif' /> 哈哈~~~ 好极了，偶也可以坐享其成了~ 谢谢 icewood

2004-8-23 13:43 icewood

今天翻译这一段： 任务调度 为了有效地协同不同任务在竞争处理器时的关系，我们用scheduler来决定处理器在什么时候执行什么任务。 Scheduler在处理任务之间关系时，有两种策略：preemptive（和cooperative。在一个preemptive系统中，一个任务在它的执行时间里被赋予了优先权，这意味着scheduler能够根据系统所处的阶段将处理器分配给其他的任务。对于需要长执行时间的任务来说，赋予优先权是一个非常好的方法；重要性更高的任务将比重要性低的任务更有效地利用处理器。 在一个cooperative系统中，每一个任务在它的执行时间里独占CPU。除非任务自动放弃对处理器的控制，否则任务间的切换不会出现。 有两种基本的调度方式：静态调度（根据时间来进行调度），和动态调度（根据事件来调度）。在静态调度方式下，提前定义了任务的执行顺序。在动态调度的方式下，一个任务在运行其间是否被执行由系统状态来决定。Scheduler(调度器)根据当前的任务状态进行调整。在动态调度方式下，只有当存在实际需要时(出现一个外部事件)，处理器才执行任务，处理器的能力将得到更有效的利用(这与静态调度方式无关)。 可能的调度方式 有许多不同的任务调度方法。在这部分中我们将看到三个通常用到: priority control(优先权控制法)，time slice(时间片法)，FIFO(first in first out,先来先出法?)。多种方法可以组合到一个操作系统中。 在一个priority-controlled scheduler(优先权控制调度器)中，OS根据每一个任务的重要程度赋予它一个优先级。开发者可以利用优先级来控制一个任务执行的速度和频率。这意味着拥有更高优先权的任务将被更快的执行完毕。可能有这样一种实施方式，所有任务位于不同优先级的队列中（在同一个队列中的任务拥有同样的优先权）。 当所有拥有更高优先权的队例为空（被调度执行完毕），特定队例中位于前面的任务将被调度执行。在同一个优先权队列内部，任务同样需要调度。因为优先权相等，需要某种其他的机制来决定不同任务的先后调度顺序。比如说FIFO(先来先出)或者其他技巧。具有代表意义的是，优先权控制法一般与动态调度结合在一起，执行顺序非静态；和preemptive调度结合以允许拥有更高优先权的任务优先执行。 Time slice(时间片法,also known as ROUND ROBIN)是另外一种调度方法。一个小的时间单元，我们称之为时间片或时间量，被定义用来执行任务。一个最简单的情况就是所有的时间片拥有同样的时间长度，不过他们也可以拥有不同的长度。所有将被执行的任务列成一个环形的队列，新激活的任务被添加到这个环形队列的尾部。 CPU调度器浏览整个队列，为每一个任务分配时间片。对于任务而言，时间片末端点是一个期限，任务将被终止或暂时停止，在队列结束该任务的下一个时间片继续执行直至结束。如果任务在时间片结束前完成，那么它将会主动释放掉处理器。 在这两种情况中,CPU调度器将处理器分配给队列中的下一个任务。当同时出现多个拥有同样优先级的任务竞争使用CPU时，经常要用到时间片法。时间片法是最简单的，也是应用得最广的CPU调度算法之一，但是这种调度方法并没有以一种最有效的方法来利用CPU能力。因为当一个任务在时间片末端点之前结束的话，在下一个任务执行之前，CPU总是处理空闲状态。 FIFO（firsr come first server,先来先服务）排序法是最基本的队列调度原则。在FIFO排序法中，所有的任务被平等的置于一个队列中。他们按照在队列中的顺序被执行。在复杂程度较低或对顺序性要求较高的系统中，这是一种非常简单而合适的调度机制。 OSEK/VDX OS的一个基于优先权和动态调度的例子如下所示： 软件开发人员通过任务优先权和事先选择好的调度机制来决定任务的执行顺序。只被激活的任务才进行Ready状态并且进入拥有一定优先权的队列。图5说明了在调度器根据优先权以及激活顺序定义好了执行顺序以后，一个处理器是如何执行这一系列任务的。（在OSEK/VDX OS中，任务既可能是preemptive，也可能是cooperative的，这取决于任务自身的设置）

2004-8-23 18:16 zdygk

一个崇拜者，又诞生了。 <img src='style_emoticons/default/happy.gif' border='0' style='vertical-align:middle' alt='happy.gif' />

2004-8-23 22:45 icewood

<div class='quotetop'>QUOTE(zdygk @ 2004-08-23 18:16:29)</div><div class='quotemain'>一个崇拜者，又诞生了。 <img src='style_emoticons/default/happy.gif' border='0' style='vertical-align:middle' alt='happy.gif' /> [right][snapback]384040[/snapback][/right] </div> 还有最后一段，明天翻译完

2004-8-24 10:24 icewood

RTOS基础：同步资源访问 RTOS通常会定义一个资源管理方法以协调不同任务对资源的访问。我们这里所说的资源，包括硬件资源，比如内存，I/O端口，和软件资源，比如全局函数的全局变量。 在RTOS中，资源对所有任务而言都是可以访问的，但是显而易见的，我们必须注意不同的任务不能在访问同一种资源时产生冲突。在preemptive系统中，任务可以在访问资源时抢先。当这种情况发生时，其他任务可能同时在访问同样的资源，这样，一种不一致的状态就出现了，因为其他任务还没有完成对资源的访问。 在preemptive系统中，资源管理器通过同步任务以阻止这种情况下对资源的并发访问。 就像任务调度一样，RTOS拥有一些资源控制协议。在这一部分中，我们讨论三个比较常见的：旗语协议(semaphore)，优先权限制协议，最高锁定者优先权协议 旗语协议 通过旗语标记的方法，某一个任务在使用某资源时就会对该资源设置一个标记，表示该资源正在使用。只有某一资源没有被其他任务占用时，它才可能被某任务获得。在一个简单有效的控制系统中，它不会出现我们已经知道的某一些典型问题。旗语协议的问题就是优先权颠倒，以及死锁。 优先权颠倒就是一个更高优先权的任务没有在它应当运行时执行，相反，执行了一个一个较低优先权的任务。图6演示了优先权颠倒的问题：当一个拥有更高优先权的任务（任务3）不得不等待被抢先运行拥有较低优先权的任务1占有的资源时，这种优先权颠倒的情况就发生了。 某一个优先权介于任务1 和任务3 之间任务在这其间有机会执行。任务2在执行时，任务1 没能够释放任务3急需的资源。这种情况只有在任务2结束时才能够解决。但是这就意味着任务2在具有比它更高优先权的人任务3之前运行（优先权倒置） 旗语协议同时也有可能导致死锁。假定两个任务必须用到两个资源，它们用不同的顺序锁定这两个资源。任务A用标志S1锁定第一个资源。接着，和正常的情况一样，任务B正在运行并用标志2锁定了第二个资源。任务B需要用到第一个资源，然而它已经被任务A锁定了。 任务B所能做的就是将对处理器的控制权传给任务A，然后任务A试图访问第二个资源。但是失败了，因为任务B锁定它了。于是任务A重新将处理器控制权传给任务B，但是任务B同样不能执行，于是处理器控制权又被传给任务A，就这样陷入死循环。这两个任务被锁死了，因为它们在同时等待被对方锁定的资源。图7演示了这种情况： 优先权限制协议 在优先权限制协议中，每个资源有自己优先权限制。该优先权限制等于可以访问该资源的所有任务中所拥有的最高优先权。任务在访问该资源过程中，将会获得该资源所具有优先权，访问完毕以后，恢复原有的优先权。所有优先权低于资源优先权限制的任务都不可能优先占有该资源，因此，所有其他试图访问某资源的任务都不能优先占有该资源。优先占有的情况只有在某一任务对该资源的访问结束，并且原任务优先权恢复以后，才会出现。 这种方法防止了优先占有资源情况的出现，这通常是导致资源访问冲突的主要原因。因此，像优先权倒置和死锁的现像就不会发生了。但是，这种协议的缺点就是，所有优先权低于该优先权限制的任务将会被排斥在外，即使他们不会使用该资源。OSEK/VDX OS 使用这种资源管理模式。 最高锁定者优先权协议 该协议类似于优先权限制协议，有区别的是，一个没有占有资源，拥有比资源的优先权限制低的任务，能够比正在使用资源的某一更低优先权的任务优先占用该资源。为了达到这个目的，调度器需要考虑两种任务优先权，初始优先权和资源优先权。 概要 这一部分介绍了涉及同步对共享资源访问的一些概念。这其中的一些协议由于一些精妙的作用而变得比较复杂。从这一章中，我们能得到的一个主要观点就是，RTOS必须控制对共享资源的并发访问；我们可能用到的资源调度机制有十分重要的意义。 由于时间仓促，翻译得有一些直板 <img src='style_emoticons/default/icon_redface.gif' border='0' style='vertical-align:middle' alt='icon_redface.gif' />

2004-8-24 10:47 carol

icewood 好厉害`~~ 翻译是件辛苦活哦

2004-8-24 12:43 icewood

<div class='quotetop'>QUOTE(carol @ 2004-08-24 10:47:56)</div><div class='quotemain'>icewood 好厉害`~~  翻译是件辛苦活哦 [right][snapback]384151[/snapback][/right] </div> 干苦力活可是俺的特长 <img src='style_emoticons/default/tongue.gif' border='0' style='vertical-align:middle' alt='tongue.gif' />