2018年IEEE小型嵌入式系统RTOS标准：μT-Kernel关键特性与应用

版权申诉

5星 · 超过95%的资源 102 浏览量更新于2024-07-02 收藏 7.47MB PDF 举报

IEEE Standard for a Real-Time Operating System (RTOS) for Small-Scale Embedded Systems - 2018 是由IEEE Standards Committee发起并针对小型嵌入式系统设计的一种实时操作系统规范。该标准特别关注那些拥有16位CPU、内存资源有限（如ROM/RAM）且可能不配备内存管理单元（MMU）的系统，如单芯片微计算机。标准的核心目标是确保这些小型设备能够提供可靠、高效的实时性能，以满足苛刻的时间敏感任务需求。标准定义了一种名为μT-Kernel的实时操作系统，它专为这类小型系统设计，旨在简化开发过程并增强系统在执行定时任务、中断处理、以及应用程序编程接口（API）调用时的响应速度。μT-Kernel强调了以下几个关键特性： 1. **硬件兼容性**：该RTOS支持16位CPU架构，这意味着它能够有效地与各种低成本、低功耗的微控制器和嵌入式处理器集成，满足不同应用场景的需求。 2. **资源管理**：针对内存资源受限的情况，μT-Kernel提供了高效的记忆管理和资源分配策略，确保系统的稳定性和内存利用率。 3. **报警处理**：对于实时性要求高的任务，μT-Kernel提供了强大的报警处理机制，确保关键事件能够得到及时响应，如定时器中断或外部输入信号处理。 4. **API设计**：标准定义了一套清晰易用的应用程序编程接口，使得开发者可以快速开发出功能丰富且运行高效的实时应用，降低了软件开发的复杂度。 5. **标准化与授权**：IEEE Std 2050™-2018 是一个受版权保护的成果，其使用权限仅限于指定机构——University of Kentucky，下载自IEEE Explore平台，且可能存在使用限制。 IEEE Standard for a Real-Time Operating System (RTOS) for Small-Scale Embedded Systems-2018 是一个重要的技术指南，为小型嵌入式系统的实时性控制和高效能设计提供了统一的标准，有助于推动这类系统在物联网、工业自动化、消费电子等领域的广泛应用。

IEEE Std 2050-2018

IEEE Standard for a Real-Time Operating System (RTOS) for Small-Scale Embedded Systems

3.1.10 Implementation-defined

Implementation-defined means that something is not standardized in the µT-Kernel specification, but must

be defined for each implementation. The specifics of the implementation should be described clearly in the

implementation specifications. In application programs, the portability for the portion dependent on

implementation-defined items is not assured.

3.1.11 Implementation-dependent

Implementation-dependent means that in the µT-Kernel specification, the behavior of something varies

according to the target systems or system operating conditions, and cannot and/or should not be specified.

The behavior should be defined for each implementation. The specifics of the implementation should be

described clearly in the implementation specifications. In application programs, the portion dependent on

implementation-dependent items needs to be modified when porting in principle.

3.2 Task states and scheduling rules

3.2.1 Task states

Task states are classified into the following five states. Of these, waiting states are further classified into

three states. Saying that a task is in a runnable state means it is in either a RUNNING state or a READY

state.

3.2.1.1 RUNNING state

The task is currently being executed. When a task-independent portion is executing, except when otherwise

specified, the task that was executing prior to the start of task-independent portion execution is said to be in

a RUNNING state.

3.2.1.2 READY state

The task has completed preparations for running, but cannot run because a task with higher precedence is

running. In this state, the task is able to run whenever it becomes the task with the highest precedence

among the tasks in a READY state.

3.2.1.3 Waiting states

The task cannot run because the conditions for running are not in place. In other words, the task is waiting

for the conditions for its execution to be met. While a task is in one of the waiting states, the program

counter and register values, and the other information representing the program execution state, are saved.

When the task resumes running from this state, the program counter, registers, and other values revert to

their values immediately prior to going to the waiting state. This state is subdivided into the following three

states:

a) WAITING state

Execution is stopped because a system call was invoked that interrupts execution of the invoking

task until some condition is met.

Authorized licensed use limited to: UNIVERSITY OF KENTUCKY. Downloaded on August 27,2018 at 16:14:07 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 2050-2018

IEEE Standard for a Real-Time Operating System (RTOS) for Small-Scale Embedded Systems

b) SUSPENDED state

Execution was forcibly interrupted by another task.

c) WAITING-SUSPENDED state

The task is in both WAITING state and SUSPENDED state at the same time. WAITING-

SUSPENDED state results when another task requests suspension of a task already in WAITING

state.

μT-Kernel makes a clear distinction between WAITING state and SUSPENDED state. A task cannot go to

SUSPENDED state on its own.

3.2.1.4 DORMANT state

The task has not yet been started or has completed execution. While a task is in a DORMANT state,

information presenting its execution state is not saved. When a task is started from a DORMANT state,

execution starts from the task start address. Except when otherwise specified, the register values are not

saved.

3.2.1.5 NON-EXISTENT state

A virtual state before a task is created, or after it is deleted, and is not registered in the system.

Depending on the implementation, there may also be transient states that do not fall into any of the

preceding categories (see 3.5).

When a task going to a READY state has higher precedence than the currently running task, a dispatch may

occur at the same time as the task goes to READY state, and it may make an immediate transition to

RUNNING state. In such a case the task that was in RUNNING state up to that time is said to have been

preempted by the task that goes to RUNNING state anew. Note also that in explanations of system call

functions, even when a task is said to go to READY state, depending on the task precedence it may go

immediately to RUNNING state.

Task starting means transferring a state from DORMANT state to READY state. A task is therefore said to

be in “started” state if it is in any state other than DORMANT or NON-EXISTENT. Task exit means that a

task in started state goes to DORMANT state.

Task wait release means that a task in WAITING state goes to READY state, or a task in WAITING-

SUSPENDED state goes to SUSPENDED state. The resumption of a suspended task means that a task in

SUSPENDED state goes to READY state, or a task in WAITING-SUSPENDED state goes to WAITING

state.

Task state transitions in a typical implementation are shown in Figure 1. Depending on the implementation,

there may be other states besides those shown here.

Authorized licensed use limited to: UNIVERSITY OF KENTUCKY. Downloaded on August 27,2018 at 16:14:07 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 2050-2018

IEEE Standard for a Real-Time Operating System (RTOS) for Small-Scale Embedded Systems

Table 1 —State transitions distinguishing invoking task and other tasks

Operations in invoking tasks

(transition from RUNNING state)

Operations on other tasks

(transitions from other states)

Task transition to a waiting state

(including SUSPENDED)

tk_slp_tsk

RUNNING state

→ WAITING state

tk_sus_tsk

READY state, WAITING state

→ SUSPENDED state,

WAITING-SUSPENDED state

Task exit

tk_ext_tsk

RUNNING state

→ DORMANT state

tk_ter_tsk

READY state, WAITING state

→ DORMANT state

Task deletion

tk_exd_tsk

RUNNING state

→ NON-EXISTENT state

tk_del_tsk

DORMANT state

→ NON-EXISTENT state

NOTE 1— WAITING state and SUSPENDED state are orthogonally related, in that a request for transition to

SUSPENDED state cannot have any effect on the conditions for task wait release. That is, the task wait release

conditions are the same whether the task is in WAITING state or WAITING-SUSPENDED state. Thus, even if

transition to SUSPENDED state is requested for a task that is in a state of waiting to acquire some resource (semaphore

resource, memory block, etc.), and the task goes to WAITING-SUSPENDED state, the conditions for allocation of the

resource do not change but remain the same as before the request to go to SUSPENDED state.

NOTE 2— The reason the μT-Kernel makes a distinction between WAITING state (wait caused by the invoking task)

and SUSPENDED state (wait caused by another task) is that these states sometimes overlap. By recognizing these

overlapped states as WAITING-SUSPENDED states, the task state transitions become clearer and system calls are

easier to understand. On the other hand, since a task in WAITING state cannot invoke a system call, different types of

WAITING state (e.g., waiting for wakeup, or waiting to acquire a semaphore resource) will never overlap. Since there

is only one kind of waiting state caused by another task (SUSPENDED state), the μT-Kernel treats repeated entries to

SUSPENDED state as nesting, thereby achieving clarity of task state transitions.

3.2.2 Task scheduling rules

The μT-Kernel adopts a preemptive priority-based scheduling method based on priority levels assigned to

each task. Tasks having the same priority are scheduled on a FCFS (first come first served) basis.

Specifically, task precedence is used as the task scheduling rule, and precedence among tasks is determined

as follows based on the priority of each task. If there are multiple tasks that can be run, the one with the

highest precedence goes to RUNNING state and the others go to READY state. In determining precedence

among tasks, of those tasks having different priority levels, that with the highest priority has the highest

precedence. Among tasks having the same priority, the one that entered runnable states (RUNNING state or

READY state) first has the highest precedence. It is possible, however, to use a system call to change the

precedence among tasks having the same priority.

When the task with the highest precedence changes from one task to another, a dispatch occurs

immediately and the task in RUNNING state is switched. If no dispatch occurs (during execution of a

handler, during dispatch disabled state, etc.), however, the switching of the task in RUNNING state is held

off until the next dispatch occurs.

3.2.2.1 Additional notes and examples for task scheduling rules

According to the scheduling rules adopted in the μT-Kernel, so long as there is a higher precedence task in

runnable states, a task with lower precedence will simply not run. That is, unless the highest-precedence

task goes to WAITING state or for other reason cannot run, other tasks are not run. This is a fundamental

difference from TSS (time sharing system) scheduling in which multiple tasks are treated equally.

Notes in text, tables, and figures of a standard are given for information only and do not contain requirements needed to implement

this standard.

Authorized licensed use limited to: UNIVERSITY OF KENTUCKY. Downloaded on August 27,2018 at 16:14:07 UTC from IEEE Xplore. Restrictions apply.

IEEE Std 2050-2018

IEEE Standard for a Real-Time Operating System (RTOS) for Small-Scale Embedded Systems

It is possible, however, to issue a system call changing the precedence among tasks having the same

priority. An application can use such a system call to realize round-robin scheduling, which is a typical

kind of TSS scheduling.

Examples in the following figures illustrate how the task that first goes to runnable states (RUNNING state

or READY state) gains precedence among tasks having the same priority. Figure 2 shows the precedence

among tasks after Task A of priority 1, Task E of priority 3, and Tasks B, C, and D of priority 2 are started

in that order. The task with the highest precedence, Task A, goes to RUNNING state.

When Task A exits, Task B with the next-highest precedence goes to RUNNING state (Figure 3). When

Task A is again started, Task B is preempted and reverts to READY state; but since Task B went to

runnable states earlier than Task C and Task D, it still has the highest precedence among tasks with the

same priority. In other words, the task precedence reverts to that in Figure 2.

Next, consider what happens when Task B goes to WAITING state in the conditions in Figure 3. Since task

precedence is defined among tasks that can be run, the precedence among tasks becomes as shown in

Figure 4. Thereafter when the Task B waiting state is released, Task B goes to runnable states after Task C

and Task D, and thus assumes the lowest precedence among tasks of the same priority (Figure 5).

To summarize, immediately after a task that goes from READY state to RUNNING state reverts to

READY state, it has the highest precedence among tasks of the same priority; but after a task goes from

RUNNING state to WAITING state and then the wait is released, its precedence is the lowest among tasks

of the same priority.

Note that after a task goes from SUSPENDED state to runnable states, it has the lowest precedence among

tasks of the same priority.

Figure 2 —Precedence in initial state

Figure 3 —Precedence after Task B goes to RUNNING state

Authorized licensed use limited to: UNIVERSITY OF KENTUCKY. Downloaded on August 27,2018 at 16:14:07 UTC from IEEE Xplore. Restrictions apply.

剩余332页未读，继续阅读

汽车通信技术

粉丝: 2w+
资源: 74

2018年IEEE小型嵌入式系统RTOS标准：μT-Kernel关键特性与应用

Real-Time Operating Systems

Real-time Operating Systems Book 2 – The Practice

Free Real-Time Operating System

What-is-a-Real-Time-Operating-System.zip_LABVIEW 实时

PaulOS：8051实时操作系统（Paul P. Debono）PaulOS: An 8051 Real-Time Operating System (Paul P. Debono)

Real-Time-System-MCTE-4324-:aimannaufalReal-Time-Systems-MCTE-4324-

COTS Real-Time Operating Systems in Space.pdf

Performance Tuning Towards a KVM-based Embedded Real-time Virtualization System

嵌入式实时操作系统-----small-RTOS

Real-Time-System:MCTE 4324实时系统每周分配

最新资源