free rtos seminar

( 주 ) 우리별 : www.wooribyul.-

co.kr

조경형 : [email protected]

co.kr

핵심기술 ( 핵심 SW) 세미나

2014. 07. 09.

FreeRTOS™

Contents

Concept of Real-Time system

FreeRTOS™ Overview

FreeRTOS™ Demo S/W 구조

FreeRTOS™ Task

Task Creation API

Task Control API

Public Scheduler Control API

Public Task Utilities

TASK API 예제

CoRoutine API 예제

Public Queue Management

Message Queue API 예제

Semaphore

Semaphore API 예제

Memory Management

시스템 하드웨어를 관리할 뿐 아니라 응용 소프트웨어를 실행하기 위하여 하드웨어 추상화 플랫폼과 공통

시스템 서비스를 제공하는 시스템 소프트웨어이다 . 운영 체제는 실행되는 응용 프로그램들이 메모리와

CPU, 입출력 장치 등의 자원들을 사용할 수 있도록 만들어 주고 , 이들을 추상화하여 파일시스템 등의

서비스를 제공한다 . 또한 멀티태스킹을 지원하는 경우 , 여러 개의 응용 프로그램을 실행하고 있는 동안 ,

운영 체제는 이러한 모든 프로세스들을 스케줄링하여 마치 그들이 동시에 수행되는 것처럼 보이는 효과를

낸다

Kernel: Kernel 은 일반인이 일반적으로 보지 못하는 낮은 수준의 프로세스를 제어한다 . 얼마나 메모리를 읽고 쓸 것인지 , 어느 프로세스를 실행할 것인지 , 모니터 , 키보드 , 마우스와 같은 장치를 통해 어떠한 정보를 주고받을 것인지 , 네트워크를 통해 받은 정보를 어떻게 해석할 것인지를 제어한다

UI: 컴퓨터 사용자가 직접 프로그램을 제어하고 사용할 수 있게 하는 운영 체제의 기능이다

목적– 사용자에게 컴퓨터의 프로그램을 쉽고 효율적으로 실행할 수 있는 환경을 제공한다– 컴퓨터 시스템 하드웨어 및 소프트웨어 자원을 여러 사용자 간에 효율적 할당 , 관리 , 보호하는 것– 운영 체제는 제어 프로그램으로서 사용자 프로그램의 오류나 잘못된 자원 사용을 감시하는 것과 입출력 장치 등의 자원에 대한 연산과 제어를

관리

구성요소

Operating System (OS)

Concept of Real-Time system

– Kernel– Mode– Multitasking– 네트워킹

– Interrupt– 가상메모리– 장치 드라이버– UI, GUI

– 프로그램 실행– 메모리 관리– 디스크 접근 및 파일시스템– 보안

Real-Time System 이란 사용할 수 있는 자원이 한정되어 있는 상황에서 작업 수행이 요청되었을 때 , 이를 제한된 시간안에 처리해 결과를 내주는 것을 말한다 . 즉 , 작업의 요청에서 수행결과를 얻기까지의 시간적인 제약이 존재하는 시스템으로 그 제약의 엄격함에 따라서 hard real-time system 과 soft real-time system 으로 나뉜다 .

hard real-time system작업의 실행 시작이나 완료에 대한 시간 제약조건을 지키지 못하는 경우 시스템 치명적인 영향을 주는 경우를 가리킨다 . 예로 무기제어 , 발전소제어 , 철도자동제어 , 미사일 자동조준 등을 들수 있다 . 보장되는 컴퓨팅과 시간의 정확성과 컴퓨팅에 대한 예측성을 가지게 해주어야 한다 .

soft real-time system작업실행에 대한 시간 제약이 있지만 , 이를 지키지 못하더라도 전체 시스템에 큰 영향을 끼치지 않는 시스템을 말한다 . 그 예로 동영상을 들 수 있다 . 초당 일정한 프레임(Frame) 이상의 영상을 재생해야 한다는 제약이 있으나 , 통신부하나 시스템의 다른 작업으로 인하여 프레임 (Frame) 이 건너뛰어져도 동영상을 재생하고 있던 시스템에는 큰 영향을 끼치지 않는다 .

Real-Time System 이란 ?

Concept of Real-Time system(cont.)

단위프로그램

단위프로그램

Foreground/background system소형이면서 복잡하지 않은 시스템은 옆의 그림과 같이 설계한다 . 이런 시스템을 foreground/background system 또는 super-loop 라고 한다 .

Foreground process 는 interrupt level background process 는 task level 이라고 부른다 .

일정한 시간 내에 수행해야 할 중요한 동작은 반드시 ISR 에서 처리해야 한다 . ( 원래의 수행시간보다 길어지는 경향 )

Task level response time: ISR 이 BP 에 정보를 전달하여 처리하는데 걸리는 시간

Foreground/Background Sys-tem

단위프로그램

ISR

단위프로그램

단위프로그램

ISR

ISR

Background process

Foreground process

Time


RTOS 는 아래와 같은 이유로 사용한다 .

Abstract out timing information

Maintainability/Extensibility

Modularity

Cleaner interfaces

Easier testing (in some cases)

Code reuse

Improved efficiency?

Idle time

Flexible interrupt handling

Mixed processing requirements

Easier control over peripherals

Why use an RTOS


Task

Task 1Stack

Task 2Stack

Task NStack

status

SP

Priority

TCB

status

SP

Priority

TCB

status

SP

Priority

TCB

Memory CPU

SP

Register


Task Status(µC-OS-II)

DORMANT

READYRUN-NING

ISRRUN-NING

WAT-ING


Task Status

Ready-State : Task 는 실행 가능 상태이지 만 우선순위가 높거나 같은

다른 Task 가 현재 실행상태에 있으므로 정지된 상태

Running-State : Task 가 실행중인 상태

Blocked-State : vTaskDelay() 함수와 같은 타이머등의 외부 이벤트를 기다리며 정지된 상태 , 이때는

우선순위 가 낮은 Task 가 활동하거나 활동중 인 Task 가 없는 경우에도 Scheduling 대상에서 제외

Suspended-State : vTaskSuspend() 함수등 을 통해 중지상태에 머물게 되며

vTaskResume() 의 API 가 호출되기전까지 스케줄링 대상에서 제외


Critical Section이 영역은 실행 중에 나뉘어져서는 안 된다는 의미이다 . Critical Section 은 실행 전에 Interrupt 를 비활성화하고 실행 후에 활성화 한다 .

ResourceTask 가 사용하는 모든 요소 . I/O 장치 , 변수 , 구조체 등 ...

Shared Resource여러 Task 가 사용할 수 있는 Resource. Mutual exclusion 독점적 공유 자원 액세스

Multitasking여러 Task 가 번갈아서 CPU 를 사용할 수 있도록 task 의 순번을 정하고 task의 수행을 전환하여 처리하는 것을 말한다 . 여러 개의 background 프로세스를 가진 fore/back-ground system 과 비슷하다 . 장점으로 CPU 를 최대한 활용할 수 있고 모듈화를 쉽게 해준다 . Real-Time system 을 복잡함을 쉽게 처리 할 수 있게 함

Terminology


Context SwitchingMultitasking kernel 이 다른 task 를 실행하고자 결정하면 , Kernel 은 단순히 현재 Task 의 context(CPU register set) 를 현재 Task stack 에 저장하고 새로운 다른 Task 의 stack 에 저장되어졌던 context 를 CPU register 로 복귀시키는 과정을 Context switching 이라고 한다 .

KernelKernel 은 multitasking system 의 한 부분으로 , Task 관리와 그 Task 들 간의 통신을 책임진다 . Context switching, Semaphore, Mailbox, Queue, Timedelay 와 같은 서비스를 지원한다 .

SchedulerDispatcher 라고도 한다 . Kernel 의 일부이며 다음에 실행할 task 를 결정하는 일을 수행한다 . 대부분의 Real-time kernel 은 Priority 에 의해 실행할 Task를 결정한다 . (Preemptive-kernel or Non-Preemptive-kernel)

Terminology


Reentrant Function데이터의 손상 없이 여러 Task 들이 공통으로 사용할 수 있는 함수 . Reentrant function 은 항상 Interrupt 를 허용한다 . 가능한 local 변수를 사용하며 전역 변수를 사용할 때는 데이터를 보호하는 방법을 사용해야 한다 .

Round-Robin Scheduling2 개 이상의 Task 가 같은 Priority 를 가지고 있을 때 , Kernel 은 quantum이라 불리는 미리 정해진 시간간격동안 하나의 Task 를 실행한 뒤 , 다른 한 Task 를 실행한다 . 이런 과정을 Time-slicing 또는 Round-Robin Schedul-ing 이라고 한다 .

Static Scheduling / Dynamic Scheduling– 정적 스케줄링 (Static Scheduling) : 프로세스에 부여된 우선순위가 바뀌지 않는다 .

고정우선순위 스케줄링이라고도 한다 . 컴파일시 우선순위가 배정되고 프로그램 수행 중에 우선순위가 변경되지 않는다 .

– 동적 스케줄링 (Dynamic Scheduling) : 스케줄링 과정에서 프로세스의 우선순위를 변동시킨다 . 유동우선순위 스케줄링이라고도 한다 . 우선순위는 프로그램 수행 중에 바꿀 수 있어 Priority Inversion 문제를 해결할 수 있다 .

Terminology


Non-preemptive Kernel

Non-preemptive kernel 에서는 각 Task 가 CPU 의 제어권을 넘겨주기 위해 명시적으로 어떤 동작을 해야 한다 . 그리고 동시에 여러 task 가 동작하는 것처럼 보이려면 이런 동작을 자주 실행해야 한다 .

Cooperative Multitasking 각 Task 는 CPU 를 공유하기 위해 서로 협력한다 .

ISR 로 비동기적 이벤트를 처리하고 가장 Priority 가 높은 task 를 ready 상태로 한 후 항상 수행하던 task 로 되돌아 온다 .

Interrupt Latency 가 짧다 .

Task level 에서 Non-reentrant function 을 사용할 수 있다 . 공유 데이터를 보호할 필요성이 줄어든다 .

Preemptive 보다 scheduler 호출 빈도가 낮고 context switching 에 의한 오버헤드가 적다

Task level response time 은 길어질 수 있다 .


Preemptive Kernel

Preemptive kernel 에서는 Task level response time 을 최소화 할 수 있다 .

ISR 로 비동기적 이벤트를 처리하고 가장 Priority 가 높은 task 로 CPU 제어권이 넘어간다 .

Mutual Exclusion Semaphore 를 이용하여 함수의 독점적인 Access 를 보장하지 않은 상태에서 Task level 의 Non-reentrant function 을 사용할 수 없다 .

Low Prior-ity Task

High Prior-ity Task

ISR

Time

Mid Prior-ity Task


Priority Inversion

Task 1(H)

Task 2(M)

Task 3(L)

Task 3 세마포어 획득

Task 1 실행

Task 1 세마포어 요청

Task 2 실행 Task 2 종료Task 3 실행

Task 3 세마포어 양도 Task 1 실행

Priority Inversion


Priority Inheritance

Task 1(H)

Task 2(M)

Task 3(L)

Task 3 세마포어 획득

Task 1 실행

Task 1 세마포어 요청Task 3 의 우선순위는 Task 1 의 우선순위로 변경

Task 2 종료Task 3 실행Task 3 세마포어 양도

Task 3 우선순위 원래대로Task 1 실행

Task 1 완료

Priority Inversion


Scheduling 알고리즘 평가 기준

CPU 사용률 (CPU Utilization) : 전체 시스템 시간 중 CPU 가 작업을 처리하는 시간의 비율 .

처리량 (Throughput) : CPU 가 단위 시간당 처리하는 프로세스의 개수 .

응답 시간 (Response Time) : 대화식 시스템에서 요청 후 응답이 오기 시작할 때까지의 시간 .

턴어라운드 시간 (Turnaround Time) : 프로세스가 시작해서 끝날 때까지 걸리는 시간 .

대기 시간 (Waiting Time) : 프로세스가 준비 큐 내에서 대기하는 시간의 총합 .

신뢰도 (Reliability): 작업의 결과를 얼마나 정확하고 믿을 수 있는가의 요인 .


Mutual Exclusion

Task 간 가장 쉬운 정보 교환은 공유 데이터를 통해서 구현한다 .

데이터의 손상을 막기 위해 데이터의 독점적이 액세스를 보장해야 한다 .

Mutual Exclusion 구현 방법

– Interrupt 비활성화 : Interrupt 비활성화 시간이 길면 System Response Time 이 길어진다 .

– Test-And-Sets: Resource 를 액세스하기 전에 Global access 변수를 Set 한다 . Resource 를 사용하는 동안 Interrupt 는 활성화된다 . 단 access 변수에 접근할 때 interrupt 는 비활성화된다 .

– Scheduler 비활성화 : Task 가 Resource 를 ISR 과 공유하지 않을 때 Task 간 Resource 공유를 막기 위해 사용된다 .

– Semaphore 사용


Semaphore

세마포어 (Semaphore) 는 에츠허르 데이크스트라가 고안한 , 두 개의 원자적 함수로 조작되는 정수

변수로서 , 멀티프로그래밍 환경에서 공유 자원에 대한 접근을 제한하는 방법으로 사용된다 . 이는

철학자들의 만찬 문제의 고전적인 해법이지만 모든 교착 상태를 해결하지는 못한다

공유자원간의 액세스 제어 (mutual exclusion)

이벤트 발생을 알려줌 (signaling)

두 Task 간의 동작 동기화 (synchronization)

Binary Semaphore, Counting Semaphore

Operation: Initialize(Create), Wait(Pend), Signal(Post)– Semaphore 초기화 시에 Ready 상태의 Task 는 없다고 가정한다 .– Semaphore 를 획득하고자 하면 Wait Operation 을 수행– Semaphore 가 유효하면 (0 보다 큰 경우 ) Semaphore 값은 감소되고 Task 복귀 실행– Semaphore 가 0 이면 Task 는 Wait state 로 감 . (Timeout 을 설정할 수 있음 )– Signal Operation 을 통해 Semaphore 를 반환한다 .– 어떤 Task 도 Wait 상태가 아니면 Semaphore 값은 증가되고 Task 복귀 실행– Wait 상태의 Task 가 있다면 Semaphore 값은 그대로 그 Task 는 Ready 상태로 간다 .

가장 우선순위가 높은 Task 가장 먼저 Semaphore 를 기다리기 시작한 Task


Deadlock교착상태는 동일한 자원을 공유하고 있는 두 개의 컴퓨터 프로그램들이 , 상대방이 자원에 접근하는 것을 사실상 서로 방해함으로써 , 두 프로그램 모두 기능이 중지되는 결과를 낳는 상황을 말한다 .

Synchronization– Semaphore 를 사용하여 ISR 또는 다른 Task 와 함께 동기화할 수 있다 .– Semaphore 를 동기화 도구로 사용할 때 0 으로 초기화한다 .

ISRISR TaskTaskPOST PEND

TaskTask TaskTaskPOST PEND

TaskTask TaskTask

POST PEND

POSTPEND

일방집결 양방집결


Event Flag

Task 를 여러 개의 Event 발생에 대해 동기화 할 필요가 있을 때 사용

ISRISRTaskTask

POST PENDTaskTask

OROR

Semaphore이벤트

분리동기화

ISRISRTaskTask

POST PENDTaskTask

ANDAND

Semaphore이벤트

결합동기화


Intertask CommunicationTask 나 ISR 이 다른 Task 로 정보를 전달하는 것을 말한다 .전역변수나 메시지를 이용하여 전달할 수 있다 . (ISR 로는 전역변수로만 )전역변수를 사용할 경우 독점적 액세스를 보장

Message Mailbox

TaskTask TaskTaskPOST PEND

Message Queue

10

MailBox

TaskTask1010 TaskTask

POST PEND

5

Queue


Interrupt

비동기적인 event 가 발생한 것을 CPU 에게 알려주는 하드웨어 메커니즘

Interrupt 가 감지되면 CPU register 를 저장하고 ISR 을 수행한다 .

Interrupt 비활성화 시간은 가능한 짧게 ISR 수행시간도 짧게 ( 시그날링과 비교 필요 )

Interrupt Latency– 인터럽트가 비활성화된 최대시간 + ISR 에서 최초

명령을 실행하려는 시간

Interrupt Response– 인터럽트를 받는 순간부터 인터럽트 사용자 코드가 시작되는 순간까지의 시간– 인터럽트를 처리하기 위한 모든 Overhead 를 포함– Interrupt Latency + Context switching Time + 커널의 ISR 진입함수 실행시간 ( 선점형 )

Interrupt Recovery– ISR 을 수행한 후 커널 코드를 다시 수행하는 데 걸리는 시간– Interrupt 로부터 복귀명령 실행 시간 + Context switching Time + High Priority 결정 시간 ( 선점형 )


Clock Tick

정기적으로 발생되는 Timer Interrupt 이다

커널로 하여금 Clock Tick 주기의 정수 배 만큼 Task 를 지연시키고 , 이벤트 Timeout

을 제공한다 .

Tick 발생속도가 빠르면 시스템에 오버헤드가 부과된다 .

Clock Delay 는 Task Priority 에 따라 다소 차이가 있고 정확한 Delay 시간을

제공하지는 않는다


Richard Barry 에 의해 작성된 Open Source 의 RTOS( http://www.freertos.org/ )

Free RTOS kernel - preemptive, cooperative and hybrid configuration options

The SafeRTOS derivative product provides a high level of confidence in the

code integrity

Includes a tickless mode for low power applications

Tiny footprint

Official support for >30 embedded system architectures

FreeRTOS-MPU supports the ARM Cortex-M3 Memory Protection Unit (MPU)

Designed to be small, simple and easy to use. Typically a RTOS kernel binary

image will be in the region of 4K to 9K bytes

Very portable source code structure, predominantly written in C

Supports both real time tasks and co-routines

Innovative event group (or event flag) implementation

Features

FreeRTOS™ Overview

http://www.freertos.org/

http://www.freertos.org/

Queues, binary semaphores, counting semaphores, recursive semaphores and

mutexes for communication and synchronisation between tasks, or between

real time tasks and interrupts

Mutexes with priority inheritance

Efficient software timers

Powerful execution trace functionality

Stack overflow detection options

Pre-configured RTOS demo applications for selected single board computers al-

lowing 'out of the box' operation and fast learning curve

Free monitored forum support, or optional commercial support and licensing

No software restriction on the number of real time tasks that can be created

No software restriction on the number of task priorities that can be used

Features

FreeRTOS™ Overview(cont.)

No restrictions imposed on task priority assignment - more than one real time

task can be assigned the same priority

Free development tools for many supported architectures

Free embedded software source code

Royalty free

Cross development from a standard Windows host

Features


Licensing


FreeRTOS™ 는 변경된 GNU General Pub-lic License 를 따른다

FreeRTOS™ demo application source 에는 3rd party 가 제공하는 별도의 source 를 포함한다 . 이것은 FreeRTOS™ 라이선스를 따르지 않고 별도의 라이선스가 부여된다

– silicon manufacturers and tool vendor 가 제공하는 소스의 라이선스

– uIP TCP/IP stack 라이선스

– lwIP TCP/IP stack 라이선스

Folder Organization

FreeRTOS™ Demo S/W 구조

Libraries

이 directory 에는 STM32 graphical library, hardware abstraction layer, the standard peripheral li-

braries, the host and device libraries, the STM32 USB OTG driver, the CMSIS files 과 the STM32

standard peripheral driver 들을 포함한다 .

이 directory 에는 STMicro 에서 Release 된 라이브러리들을 이 경로 아래에 둔다 .

라이브러리는 가능한 수정하지 않고 사용하는 것을 지향한다 .

만일 수정이 필요하면 define 을 통해 정의 한 후 사용할 수 있다 . 명확히 알 수 있는 버그에 대해선 공지 후 define 없이 수정할 수 있다 .

Project

STM32F2 시리즈를 사용하는 프로젝트는 여기에 정의하고 사용할 수 있다 . 각 Project 아래 각 디렉토리는 Project 이다 . 프로젝트 아래 세부 프로젝트로 나눌 수 있다 . 프로젝트 디렉토리는 프로젝트에 맞게 디렉토리를 분리하여 개발해도 된다 . 개발에 맞게 적용한다 .

프로젝트 파일이 많은 경우 Library 와 Utility 를 포함하여 전체를 새롭게 만들 수도 있다 .

Utilities

공통 Utilities 를 적용한다 . 특히 3rd party solution 들을 위치 시킨다 . Library 와 마찬가지로 공통 디렉토리이므로 수정을 지양한다 . 수정할 경우 define 을 통한 정의 통해 사용하여 다른 프로젝트에 영향을 미치지 않도록 한다 . 명확히 알 수 있는 버그에 대해선 공지 후 define 없이 수정할 수 있다 .

Project 구조

FreeRTOS™ Demo S/W 구조 (cont.)

Project 디렉토리 아래에는 진행할 Project 를 정의한다 . Project 그룹도 정의할 수 있다 . FreeRTOS 는 프로젝트 그룹이고 그 아래에 각 Project 를 정의하였고 , MultiHop_2013 은 프로젝트 디렉토리이다 .

이 프로젝트에서 개발되는 소스는 이 프로젝트에만 영향을 미치도록 하고 Library 또는 Utility 에 영향을 미치지 않도록 한다 . Dependency 도 주어선 안된다 .

EWARM 툴체인 정보를 SVN 에 공유할 때 Object 나 Setting 디렉토리는 제외한다 . Dep 파일도 제외한다 .

STM322xG-EVAL


STM322xG-EVAL 보드를 이용하여 각 테스트 버전을 만들 수 있는 프로젝트

STM322xG-EVAL 을 위한 Demo 버전 소스로 구성되어 있음

STM322xG-EVAL 디렉토리 개발자 소스 디렉토리 구조는 다음과 같습니다 .

Config: Target configuration header 파일들을 여기에 둔다 .

Core: 개발 소스 디렉토리 . 각 소스의 특징에 맞게 분리한 디렉토리 아래 둔다 . 소스와 헤더

파일도 같이 둔다 .

Doc: 소스와 관련된 문서 보관 장소

EWARM: IAR 툴체인 디렉토리 오브젝트 파일들도 이 경로 아래 둔다 .

MultiHop_2013


병사용 무전기를 개발하기 위한 지경부 EVM 으로 개발하는 프로젝트

MultiHop_2013 디렉토리 안에 EWARM 이라는 IAR 사에서 제공하는 Toolchain 을 사용할 때 적용되어진다 . EWARM Toolchain 에서 사용하는 프로젝트 경로는 이 디렉토리를 가르키게 한다 .

MultiHop_2013 디렉토리 개발자 소스 디렉토리 구조는 다음과 같습니다 .

Config: Target configuration header 파일들을 여기에 둔다 .

Core: 개발 소스 디렉토리 . 각 소스의 특징에 맞게 분리한 디렉토리 아래 둔다 . 소스와 헤더 파일도 같이 둔다 .

Doc: 소스와 관련된 문서 보관 장소

EWARM: IAR 툴체인 디렉토리 오브젝트 파일들도 이 경로 아래 둔다 .

이 프로젝트에서 개발되는 소스는 이 프로젝트에만 영향을 미치도록 하고 ST Micro chip 을 사용하면서 공통으로 이용 가능한 것들은 Library 또는 Utility 에 포함하여 정의한다 .

TCB 에 관한 구조체와 Stack 을 지니며 동작하는 실행 개체

독립적인 Task 를 이용하여 Real time application 을 구현

Task 는 Swap in/out 시 사용되는 각자의 Stack 을 지니고 있다

우선 순위에 따라 Task Scheduler 에 의해 Multi-Tasking 을 구현

4 가지 state 를 가짐

– Ready, Running, Suspended, Blocked state

Supports full preemption

Re-entrancy must be carefully considered if using preemption

Task Characteristics

FreeRTOS™ Task

RTOS 가 사용되는 용도에 따라 제한된 Memory 용량 문제가 생기게 되는데 이를

해결하기 위해 Single Stack 을 공유하는 Light Task 개념으로써 사용되며 실행에

있어서 Main Routine 과 Sub Routine 처럼 주종관계가 있으며 실행될 때마다

재실행되는 Sub Routine 과 달리 서로 동등한 관계를 지니며 서로 호출이 가능하고

호출되어 다시 실행할 경우 마지막에 실행된 곳에서부터 실행을 재개한다 .

Task 와는 달리 하나의 Stack 을 모든 CoRoutine 들이 공유하게 되어 RAM 상의 소모를

크게 줄일 수 있으나 그에 따른 실행과 관리에 제약이 존재한다 .

우선순위를 제공하고 비선점형 방식에 협력적 (Cooperative) 스케줄링을 통해 실행되며

매크로방식을 사용하여 실행된다 .

Task 와 함께 사용시에는 Task 에 의해 선점이 되므로 보통 IdleTaskHook 함수를 이용하여

실행한다 .

Co-Routine Characteristics

FreeRTOS™ Task (cont.)

Ready State : Task 와 마찬가지로

실행이 가능하지만 정지된 상태로

우선순위가 높거나 같은 Co-Routine 이

이미 실행 중이거나 Task 가 실행 중일

경우 Ready State 가 된다 .

Running : 현재 프로세스를 사용하여

실행중인 상태

Block : crDelay() 등의 함수를 통해

외부적인 이벤트 ( 타이머 ) 를 기다리는

상태로 Task 와 마찬가지로 스케줄링이

불가능

Co-Routine 함수는 다음과 같은 구조를

같는다

Co-Routine State

FreeRTOS™ Task (cont.)

portBASE_TYPE xTaskCreate( pdTASK_CODE pvTaskCode, const portCHAR * const pcName, unsigned portSHORT usStackDepth, void *pvParameters, unsigned portBASE_TYPE uxPriority, xTaskHandle *pvCreatedTask );

– pvTaskCode: Task entry function 을 가리키는 pointer 값 . 무한루프 함수로 작성

– pcName: 생성할 Task 이름 혹은 Tag char배열로 configMAX_TASK_NAME_LEN = 16

– usStackDepth: Task 에서 사용될 Stack Size 를 지정 . 이 값은 byte size 가 아님 . Stack 으로

사용하는 메모리의 기본크기 portSTACK_TYPE x usStackDepth 이다 . portSTACK_TYPE 은 un-

signed long 이므로 4 이다 . Stack size 는 4 x usStackDepth bytes 이다 .

– pvParameters: Task Entry Function 을 호출할 때 넘겨줄 Parameter 를 가르키는 pointer 이다 .

– uxPriority: Task Priority 로 configMAX_PRIORITIES 값보다 작아야 한다 .

– pvCreatedTask: 해당하는 Task 의 TCB 를 만들고 그것을 handle 로 돌려 준다 .

xTaskCreate

Task Creation API

xTaskCreate() 함수를 호출하면 해당 Task 의 TCB 가 옆의 그림과 같이 생성됨

TCB 아래에 xTaskCreate() 함수 호출 시 정의한 stack size x 4 bytes 만큼 생성됨

맨 아래 stack 에 초기화 값들을 채운다 .

xGenericListItem, xEventListItem

TCB 구조

Task Creation API(cont.)

첫 번째 Task 를 생성하면서 한 번 호출되는 함수 prvIni-tialiseTaskLists( )

pxReadyTasksLists[13], xDelayedTaskList1, xDe-layedTaskList2, xPendin-gReadyList 이름의 List 를 생성하고 초기화 한다 .

List 관리


ReadyTaskList


pxReadyTasksLists 와 생성한 TCB와 Linked List 로 연결한다 .

TCB Priority 별로 각각 연결한다 .

TCB Priority 가 같으면 추가되는 TCB 는 아래와 같이 연결되고 관리 되어진다 .

TCB 의 *pvContainer 는 연결된 pxReadyTasksLists[ ] 을 가리킨다 .

void vTaskDelete( xTaskHandle pxTaskToDelete )

– Remove task from the ready list and place in the termination list. This will stop the task from be scheduled.

– The idle task will check the termination list and free up any memory allocated by the scheduler for the TCB and stack

vTaskDelete


void vTaskDelay( portTickType xTicksToDelay )

해당 Tick 수만큼 호출한 Task 를 대기상태로 한다 .

– xTicksToDelay : Tick 주기 단위의 시간량 , FreeRTOSconfig.h 의 con-figTICK_RATE_HZ 에 설정되어 있다 .

– 설정 상수 ( FreeRTOSconfig.h ) : IN-CLUDE_vTaskDelay= 1

pxCurrentTCB 즉 현재 Task 를 pxReadyTasksLists 에서 삭제

pxCurrentTCB 를 pxDelayed-TaskList, pxOverflowDelayed-TaskList 에 등록

xTaskResumeAll( ) 을 통해 Task switching

vTaskDelay

Task Control API

void vTaskDelayUntil( portTickType * const pxPreviousWakeTime, portTickType xTimeIncrement )

– vTaskDelay 의 경우 다른 Task 에 의해 Tick 수에 의한 정확한 실행 주기를 만들기 어려운 반면 vTaskDe-layUntil() 의 경우 Task 가 마지막으로 깨어난 시점과 반복주기를 매개변수로 받아 대기시간을 명시하여 정확한 실행 주기를 만들 수 있다

– pxPreviousWakeTime : Task 가 마지막으로 깨어난 시점을 기록하는 포인터 , 함수가 실행될 때마다 자동적으로 갱신된다 .

vTaskDelayUntil

Task Control API(cont.)

– xTimeIncrement : 반복주기 , Task 는 ( *pxPreviousWake-Time +xTimeIncrement ) 로 계산된 시간에 깨어나게 된다 .

– 설정 상수 ( FreeRTOScon-fig.h ) : INCLUDE_vTaskDelayUntil= 1

unsigned portBASE_TYPE uxTaskPriorityGet( xTaskHandle pxTask )– 해당 Task 의 우선순위를 반환– pxTask : 해당 Task 의 Handle값 , NULL 일 경우엔 호출한 Task 의 값이 된다 .– 설정 상수 ( FreeRTOSconfig.h ) : INCLUDE_vTaskPriorityGET = 1

void vTaskPrioritySet( xTaskHandle pxTask, unsigned portBASE_TYPE uxNewPri-ority )

– 해당 Task 의 우선순위를 재설정하며 , 함수가 반환 하기 전에 우선순위가 현재 실행되고 있는 Task 보다 높게되면 Context switch 를 행한다 .

– pxTask : 해당 Task 의 Handle– uxNewPriority : 설정할 Task 의 우선순위– 설정 상수 ( FreeRTOSconfig.h ) : INCLUDE_vTaskPrioritySet=1– xEventListItem 의 xItemValue = configMAX_PRIORITIES - ( portTickType ) uxNewPriority

TaskPriority 관련 함수


pxReadyTasksLists 에 Task 재 작성

void vTaskSuspend( xTaskHandle pxTaskToSuspend )– 해당 Task 를 중지상태 (Suspend State) 로 전환– pxTaskToSuspend : 해당 Task 의 Handle– 설정 상수 ( FreeRTOSconfig.h ) : INCLUDE_vTaskSuspend=1– Remove task from the ready/delayed list and place in the suspended list.– Waiting 하고 있는 xEventListItem 삭제에 의해 event 도 삭제– Current Task 가 suspend 되면 Context Switching 을 통해 Task switching

void vTaskResume( xTaskHandle pxTaskToResume )– 중지상태에 있는 해당 Task 를 재개– pxTaskToResume : Resume 할 Task 의 Handle– 설정 상수 ( FreeRTOSconfig.h ) : INCLUDE_vTaskSuspend=1– pxReadyTasksLists 에 Resume Task TCB 등록함으로서 수행

portBASE_TYPE xTaskResumeFromISR( xTaskHandle pxTaskToResume )– vTaskResume() 함수와 기능이 같으며 ISR 내부에서 실행– pxTaskToResume : Resume 할 Task 의 Handle– 설정 상수 ( FreeRTOSconfig.h ) : INCLUDE_vTaskSuspend = 1– 설정 상수 ( FreeRTOSconfig.h ) : INCLUDE_vTaskResumeFromISR = 1

vTaskSuspend, vTaskResume


vTaskStartScheduler()

Public Scheduler Control API

vPortStartFirstTask() 에서 non-Return

PendSV Interrupt 를 통해 Context switching 을 수행한다 .

vTaskSwitchContext( ) 를 호출하여 px-CurrentTCB 를 가장 best Task 로 설정한 후 인터럽트가 호출되면 수행하게 된다

Public Scheduler Control API (cont.)

void vTaskEndScheduler( void ): xSchedulerRunning = pdFALSE void vTaskSuspendAll( void ): ++uxSchedulerSuspended signed portBASE_TYPE xTaskResumeAll( void )

– Move any readied tasks from the pending list into the appropriate ready list– xTaskResumeFromISR, xTaskRemoveFromEventList 와 같은 함수 호출은 Task suspend 동안

pxReadyTasksLists 에 Task 가 등록되지 않고 xPendingReadyList 에 등록 된다 .– Resume 시 Priority 가 현재 Task 보다 높은 Task 가 Ready 상태에 있다면 Task switching– vTaskIncrementTick 함수가 호출된 횟수 만큼 xTaskResumeAll() 함수에서 vTaskIncre-

mentTick 함수를 호출 #define taskYIELD() portYIELD() : 강제적으로 Context Switch 를 한다 . #define taskENTER_CRITICAL() portENTER_CRITICAL() : 크리티컬 코드 영역의

시작 이후로는 다른 Task 에 의한 Context Switch 가 일어나지 않는다 . #define taskEXIT_CRITICAL() portEXIT_CRITICAL() : 크리티컬 코드 영역의 끝을 표시

#define taskDISABLE_INTERRUPTS() portDISABLE_INTERRUPTS() : 모든 인터럽트를 비 활성화 – basePRI register 를 활용

#define taskENABLE_INTERRUPTS() portENABLE_INTERRUPTS() : 비 활성화한 인터럽트들을 다시 활성화 – basePRI register 를 활용

vTaskEndScheduler, vTaskSuspendAll

vTaskSuspendAll() 과 match 되어야 한다 . (uxSchedulerSuspended)

xTaskResumeAll

Public Scheduler Control API (cont.)

Public Task Utilities

portTickType xTaskGetTickCount( void ), portTickType xTaskGetTickCountFromISR( void )

vTaskStartScheduler 가 호출되어 스케줄링을 시작한 이후부터의 Tick 카운트 수를 반환 unsigned portBASE_TYPE uxTaskGetNumberOfTasks( void )

현재 Kernel 에서 관리하는 Task 의 수를 반환 . 삭제 대기 상태이나 idle Task 에 의해 삭제되지 않은 Task 도 포함된다 .

void vTaskList( signed char *pcWriteBuffer )현재 실행중인 모든 Task 들의 정보를 표시하며 , 대기 (‘B’), 준비 (‘R’), 삭제 (‘D’), 중지 (‘S’) 로 표현된다 .

– pcWriteBuffer : 위에서 나타난 State 를 아스키 문자 형식으로 저장하는 버퍼– 설정 상수 ( FreeRTOSconfig.h ) : configUSE_TRACE_FACILITY = 1– 설정 상수 ( FreeRTOSconfig.h ) : INCLUDE_TaskDelete= 1– 설정 상수 ( FreeRTOSconfig.h ) : INCLUDE_TaskSuspend = 1

void vTaskStartTrace( signed char * pcBuffer, unsigned long ulBufferSize )– 구현부 없음실시간 Kernel 동작을 추적하여 어떤 Task 가 언제 실행되는지에 대한 것을 추적하여 기록

– pcBuffer : 추적결과를 기록할 버퍼– ulBufferSIZE : pcBuffer 의 바이트 단위 크기 , 설정된 크기이상 Trace 정보가 기록될 경우나 ul-

TaskEndTrace() 가 호출될 때까지 Trace 한 내용을 기록 unsigned long ulTaskEndTrace( void ) – 구현부 없음

Trace 를 중지한다 . pcBuffer 에 기록된 바이트 수를 반환한다

Public Task Utilities(cont.)

xTaskHandle xTaskGetCurrentTaskHandle( void )호출된 Task 의 Handle값을 반환

– 설정 상수 : INCLUDE_xTaskGetCurrentTaskHandle = 1 or configUSE_MUTEXES == 1 portBASE_TYPE xTaskGetSchedulerState( void )

현재 스케줄러의 상태를 “ taskSCHEDULER_NOT_STARTED, taskSCHEDULER_RUNNING, taskSCHEDULER_SUSPENDED” 중 하나로 반환

– 설정 상수 : INCLUDE_ xTaskGetSchedulerState = 1 or configUSE_TIMERS == 1 void vTaskSetApplicationTaskTag( xTaskHandle xTask, pdTASK_HOOK_CODE px-

HookFunction ) : 해당 Task 의 Tag값을 설정– xTask : 해당 Task 의 Handle– pxTagValue : Tag값으로 사용할 함수의 포인터 , xTaskCallApplicationTaskHook() 에서 사용될

함수를 정의하는 값이다 .– 설정 상수 ( FreeRTOSconfig.h ) : configUSE_APPLICATION_TASK_TAG = 1

pdTASK_HOOK_CODE xTaskGetApplicationTaskTag( xTaskHandle xTask ) portBASE_TYPE xTaskCallApplicationTaskHook( xTaskHandle xTask, void *pvPa-

rameter ) : 실행될 때마다 Task 의 Tag값으로 명시된 Hook Function 을 실행한다 . 매개변수로 주어진 pvParameter값을 Hook Function 에 전달하여 사용할 수 있다 .

– xTask : 해당 Task 의 Handle– pvParameter : Hook Function 에서 사용될 값의 포인터– 설정 상수 ( FreeRTOSconfig.h ) : configUSE_APPLICATION_TASK_TAG = 1

예제 1 : Task 를 생성하여 LCD 화면 출력

TASK API 예제

TASK API 예제 (cont.)

예제 2 : vTaskDelay() 와 vTaskDe-layUntil()


예제 3 : uxTaskPriorityGet(), vTaskPriori-tySet()


예제 4 : vTaskSuspend(), vTaskRe-sume()


예제 5 : vTaskSuspendAll(), vTaskResumeAll()


예제 6 : vTaskSetApplicationTaskTag(), vTaskApplicationTaskHook();


uxTaskPriorityGet(), xTaskGetTickCount(), xTaskGetSchedulerState(), uxTaskGetNumberOf-Task()


CoRoutine 생성과 실행

CoRoutine API 예제

CoRoutine API 예제 (cont.)

MutiTasking 에서는 각 Task 간에 공유하거나 겹치게 되는 자원영역 즉 Critical Section 이 존재하므로 이에 의해 생기는 문제를 해결하기 위하여 자원의 선점을 관리하거나 각 Task 간 통신 (ITC : Inter Task Communication) 이 필요하게 된다 .

FreeRTOS 에서 지원하는 ITC 로는 Message Queue 와 Semaphore(Mutexes) 를 지원하고 있다 .

Message Queue 는 FIFO(First in First out)방식을 사용하며 데이터를 Queue 에 보낼때는 자료의 포인터를 보내게 되며 ISR 에서도 사용하여 ISR 과 Task 내에 통신이 가능하다 .

ITC – Message Queue

Public Queue Management

• *pcHead: Points to the beginning of the queue storage area. • *pcTail: Points to the byte at the end of the queue storage area.

Once more byte is allocated than necessary to store the queue items, this is used as a marker.

• *pcWriteTo: Points to the free next place in the storage area.• *pcReadFrom: Points to the last place that a queued item was read

from.• xTasksWaitingToSend: List of tasks that are blocked waiting to post

onto this queue. Stored in priority order.• xTasksWaitingToReceive: List of tasks that are blocked waiting to

read from this queue. Stored in priority order.• uxMessagesWaiting: The number of items currently in the queue.• uxLength: The length of the queue defined as the number of items it

will hold, not the number of bytes.• uxItemSize: The size of each items that the queue will hold.• xRxLock: Stores the number of items received from the queue (re-

moved from the queue) while the queue was locked. Set to queue-UNLOCKED when the queue is not locked

• xTxLock: Stores the number of items transmitted to the queue (added to the queue) while the queue was locked. Set to queueUN-LOCKED when the queue is not locked.

• ucQueueNumber: configUSE_TRACE_FACILITY = 1 일때• ucQueueType: configUSE_TRACE_FACILITY = 1 일때

Queue 의 구조

Public Queue Management(cont.)

xQueueCreate( uxQueueLength, uxItemSize ) xQueueHandle xQueueGenericCreate( unsigned portBASE_TYPE uxQueue-

Length, unsigned portBASE_TYPE uxItemSize, unsigned char ucQueueType )

새로운 Queue 를 생성한다 . Queue 가 가질 자료의 최대 항목 수 uxQueueLength 와 각 항목 당 필요한 자료의 크기인 (바이트수 ) uxItemSize 를 매개변수로 받아 Heap memory 로부터 Queue 헤더와 Queue 데이터 영역을 생성 후에 그 Handle값인 xQueue 를 반환해 준다

– uxQueueLength : Queue 가 가질 최대 항목 개수– uxItemSize : Queue 에 있는 하나의 항목이 필요로 하는 바이트 수

xQueueHandle xQueueCreateMutex( unsigned char ucQueueType )Queue 를 Mutex 로 사용하기 위해 실제 Queue 와 좀 다르게 생성한다 . Queue Header 만 생성한다 .

xQueueHandle xQueueCreateCountingSemaphore( unsigned portBASE_TYPE uxCountValue, unsigned portBASE_TYPE uxInitialCount )

unsigned portBASE_TYPE uxQueueMessagesWaiting( const xQueueHandle pxQueue )해당 Queue 의 Handle 값인 xQueue 를 매개변수로 받아 Queue 내의 매세지 개수를 반환한다 .

void vQueueDelete( xQueueHandle pxQueue )해당 Handle값을 입력 받아 해당 Queue 를 삭제하고 Queue 내의 모든 항목의 Memory 를 해제시킨다 .

xQueueCreate

Public Queue Management API

xQueueSend( xQueue, pvItemToQueue, xTicksToWait ) xQueueSendToFront( xQueue, pvItemToQueue, xTicksToWait ) xQueueSendToBack( xQueue, pvItemToQueue, xTicksToWait )

xQueueGenericSend( ( xQueue ), ( pvItemToQueue ), ( xTicksToWait ), queueSEND_TO_BACK(0) )

– xQueue: 해당 queue 에 데이터를 저장하는 함수– pvItemToQueue : Queue 에 저장할 항목에 대한 포인터 , 생성시 사용된 uxItemSize 인자 즉 각 항목당 바이트 수에 의해 해당 포인터부터 정해진 바이트 수만큼 Queue 영역으로 복사한다 .

– pxQueue->xTasksWaitingToReceive 에 등록한 Task 가 있으면 xTaskRemoveFromEventList( ) 를 호출 pdTRUE 를 return 하면 portYIELD_WITHIN_API() 를 수행 task switching 을 진행한다 .

– xTicksToWait : Queue 에 공간이 빌 때까지 Task 가 기다리는 최대 시간 signed portBASE_TYPE xTaskRemoveFromEventList( const xList * const px-

EventList )이 함수는 인터럽트가 disable 상태거나 scheduler 가 suspend 상태일 때 호출되어져야 한다 . ISR 에서 호출될 수도 있다 . The event list is sorted in priority order, so we can remove the first in the list, remove the TCB from the delayed list, and add it to the ready list

– *pxEventList = &pxQueue->xTasksWaitingToReceive ( 예 )– pxUnblockedTCB = pxQueue->xTasksWaitingToReceive 의 pvOwner 가 가리키는 TCB 가

된다 .– TCB 내의 xEventListItem 과 xGenericListItem 와 연결된 List 에서 삭제하고 pxReady-

TasksLists 에 연결 portBASE_TYPE xTaskCheckForTimeOut( xTimeOutType * const pxTimeOut,

portTickType * const pxTicksToWait )이 함수는 빈 Queue 가 없을 때 Queue 생성될 때까지 대기하는 시간을 check 한다

xQueueSend

Public Queue Management API(cont.)


xQueueSendFromISR( pxQueue, pvItemToQueue, pxHigherPriorityTaskWoken ) xQueueSendToFrontFromISR( pxQueue, pvItemToQueue, pxHigherPriorityTaskWoken ) xQueueSendToBackFromISR( pxQueue, pvItemToQueue, pxHigherPriorityTaskWoken )

xQueueGenericSendFromISR( xQueueHandle pxQueue, const void * const pvItemToQueue, signed portBASE_TYPE *pxHigherPriorityTaskWoken, portBASE_TYPE xCopyPosition ): ISR(Interrupt Service Routine) 내에서 해당 Queue 에 자료를 전달하는 함수 .

– pxQueue: Queue handle– pvItemToQueue : Queue 에 저장할 항목에 대한 포인터 , 생성시 사용된 uxItemSize 인자 즉 각 항목당 바이트 수에 의해 해당 포인터부터 정해진 바이트 수만큼 Queue 영역으로 복사한다 .

– *pxHigherPriorityTaskWoken : ISR 내에서 xQueueSendFromISR() 에 의해 unblock 된 Task의 Priority 가 현재 실행중인 Task 보다 높을 경우 xQueueSendFromISR() 은 pxHigherPriority값을 pdTRUE 로 만든다 . 그럴 경우 ISR 수행이 끝나지 않았음에도 unblock 된 Task 에 의해 Context Switch 가 요청되어야 하므로 ISR 수행 후 pxHigherPriorityTaskWoken값을 이용하여 Context Switch 처리 여부를 결정할 수 있다 .

– xCopyPosition : xQueueGenericSendFromISR( ) 를 호출하면서 Queue 의 front or back 에 저장 위치에 대한 정보를 전달한다 .

xQueueReceive( xQueue, pvBuffer, xTicksToWait ) xJustPeeking=pdFALSE 호출 xQueuePeek( xQueue, pvBuffer, xTicksToWait ): xJustPeeking=pdTRUE 호출

signed portBASE_TYPE xQueueGenericReceive( xQueueHandle pxQueue, void * const pvBuffer, portTickType xTicksToWait, portBASE_TYPE xJustPeeking )해당 Queue 에서 자료를 받는다 . 항목을 성공적으로 받을 경우에 pdTRUE 1, 그렇지 않으면 pdFALSE 0 값을 반환한다 .

– xQueue: 해당 Queue 의 Handle 값– pvBuffer : 받은 자료를 저장할 Buffer 의 포인터– xTicksToWait : Queue 에 공간이 빌 때까지 Task 가 기다리는 최대 시간– xJustPeeking: xQueueReceive 에서는 xJustPeeking=pdFALSE, xQueuePeek 에서는 xJust-

Peeking=pdTRUE

signed portBASE_TYPE xTaskRemoveFromEventList( const xList * const px-EventList )

xTaskCheckForTimeOut( &xTimeOut, &xTicksToWait )

xQueueReceive



xQueueReceiveFromISR( xQueueHandle pxQueue, void * const pvBuffer, signed portBASE_TYPE *pxTaskWoken )

: ISR 내에서 해당 Queue 내의 자료를 지정된 Buffer 복사한 후 제거한다 .– pxQueue: Queue handle– pvBuffer : Queue 에서 받은 자료를 저장할 Buffer 의 포인터– *pxTaskWoken : 해당 Queue 가 full 일 경우 빈공간이 생기길 기다리는 Task 가 존재할 수 있다 .

이 경우 함수 실행 후 빈 공간이 생겨서 해당 Task 의 Waiting 상태가 풀릴 경우 px-TaskWoken 은 pdTRUE 로 Set 되며 아닐 경우 pdFALSE 로 남아있게 된다 .

crQUEUE_SEND( xCoRotineHandle xHandle, xQueueHandle pxQueue, void *pvItemToQueue, portTickType xTicksToWait, portBASE_TYPE *pxResult )

: CoRoutine 내에서만 사용되며 xQueueSend() 와 기능이 동일하며 , CoRoutine 은 Stack 을 유지하지 않으므로 호출된 함수 내에서는 사용할 수 없다 .

– xHandle : CoRoutine handle– pxQueue: Queue handle– *pvItemToQueue : Queue 에 넣을 자료의 포인터– xTicksToWait : Queue 가 사용 가능해질 때까지 CoRoutine 이 대기하는 Tick 의 수– pxResult : Queue 에 자료를 넣는데 성공시 pdPASS, 실패 시 projDefs.h 에 정의된 값을 Set

crQUEUE_RECEIVE( xCoRotineHandle xHandle, xQueueHandle pxQueue, void *pvBuffer, portTickType xTicksToWait, portBASE_TYPE *pxResult )

: crQUEUE_SEND 와 마찬가지로 CoRoutine 내에서만 사용되며 xQueueReceive() 와 동일 , 마찬가지로 호출

– xHandle : CoRoutine handle– pxQueue: Queue handle– pvBuffer: 받을 자료를 저장할 포인터 값– xTicksToWait : Queue 가 사용가능해질 때까지 CoRoutine 이 대기하는 Tick 의 수– pxResult : Queue 에 자료를 넣는데 성공시 pdPASS, 실패 시 projDefs.h 에 정의된 값을 Set 된

함수 내에서 사용할 수 없다 .

CoRoutine Queue Manage-ment



crQUEUE_SEND_FROM_ISR( xQueueHandle pxQueue, void *pvItemToQueue, portBASE_TYPE xCoRotinePreviouslyWoken )

: xQueueSendFromISR() 과 동일한 기능을 가지며 차이점은 ISR 과 Task 간의 자료전달이 아니라 ISR 과 CoRoutine 간의 자료 전달이라는 점이다 .

– pxQueue: Queue handle– *pvItemToQueue : Queue 에 넣을 자료의 포인터– xCoRotinePreviouslyWoken : xQueueSendFromISR() 과 동일하게 Queue 에 자료를 보낸 후

Context Switch 가 필요한 시점이 되면 pdTRUE값으로 Set 된다 .

crQUEUE_RECEIVE_FROM_ISR( xQueueHandle pxQueue, void *pvBuffer, portBASE_TYPE *pxCoRotineWoken )

: xQueueReceiveFromISR() 과 같이 Queue 로부터 자료를 받아 pvBuffer 에 지정된 포인터 값으로 자료를 전송한다 . ( 복사 후 삭제 )

– pxQueue: Queue handle– pvBuffer: 받을 자료를 저장할 포인터 값– pxCoRotineWoken : 해당 Queue 가 Full 상태일 때 Queue 가 비는 것을 기다리는 CoRoutine

이 존재 시 Queue 의 자료를 받은 후 pxCoRotineWoken값을 pdTRUE 값으로 Set 한다 .

예제 1 : Queue 생성과 Data 전송

Message Queue API 예제

Message Queue API 예제 (cont.)

예제 2 : CoRoutine 내에서 Queue 사용 (crQUEUE_SEND(), crQUEUE_RECEIVE())

CoRoutine 내에서 Queue


공유 자원에 대하여 둘 이상의 프로세스가 접근할 경우 자원의 값이 변함에 의한 오류나

교착상태 (Deadlock) 가 생길 수 있는 Critical Section 의 동기화 문제를 해결하기 위한

방법

하나의 프로세스가 공유 자원을 선점하였을 경우에 다른 프로세스들이 접근하지 못하도록

막고 , 사용 후 공유자원에 대한 사용권을 풀어줌으로써 자원 점유에 대한 중복을 막을 수

있게 한다 .

공유 자원의 사용권 수에 따라 하나일 경우 Binary Semaphore, 둘 이상일 경우 Count-

ing Semaphore, Binary Semaphore 와 비슷하지만 소유권개념을 가지는 Mutex (Re-

cursive Mutex) 를 지원한다 .

각 Semaphore 들은 Queue 를 이용한 매크로함수를 사용하여 구현된다 .

Semaphore (FreeRTOS)

Semaphore

vSemaphoreCreateBinary( xSemaphoreHandle xSemaphore ): Queue 의 길이가 1 인 Binary Semaphore 를 생성한다 .

– xSemaphore : 생성된 Semaphore 의 Handle값

xSemaphoreCreateCounting( unsigned portBASE_TYPE uxMaxCount, unsigned portBASE_TYPE uxInitialCount ): Counting Semaphore 를 생성하기 위한 함수 , 생성 시에 남아 있는 자료량과 최대 자료량을 결정할 수 있다 . 생성 후 Semaphore 의 Handle값을 반환한다 .

– uxMaxCount : 사용할 수 있는 최대 자료량– uxInitialCount : Semaphore 가 생성될때 남아있는 자료량– 설정 상수 ( FreeRTOSconfig.h ) : configUSE_COUNTING_SEMAPHORES = 1

xSemaphoreCreateMutex( void ): Mutex 를 생성하는 함수 , 생성 후 Semaphore 의 Handle값을 반환한다 .

xSemaphoreCreateRecursiveMutex( void ): 한 Mutex 를 받은 함수가 여러번 Take 를 할 수 있는 Mutex 를 생성 예를 들어 Task 가 5 번 Take 를 할 경우에 다른 Task 에서 Mutex 를 얻기 위해서는 해당 Task 가 5 번 Give 를 해야 한다 .

Semaphore API

Semaphore(cont.)

xSemaphoreGive( xSemaphoreHandle xSemaphore ): Task 가 가지고 있는 Semaphore 를 release 한다 . 그러기 위해서는 xSemaphoreCreateBi-nary(), xSemaphoreCreateCouting(), xSemaphoreMutex() 가 선언되고 xSemaphoreTake() 를 통해 Semaphore 를 획득한 상태여야 한다 .

– xSemaphore : 해당 Semaphore 의 Handle값

xSemaphoreGiveRecursive( xSemaphoreHandle xMutex ): xSemaphoreCreateRecursiveMutex() 를 통해 생성된 Mutex 를 release 한다 . Mutex 를 가지고 있는 Task 의 경우 xSemaphoreTakeRecursive() 를 통해 Take 한 횟수만큼 Give 를 해 주어야 다른 Task 에서 Mutex 에 접근할 수 있다 .

– xMutex : 해당 Mutex 의 Handle값

xSemaphoreGiveFromISR( xSemaphoreHandle xSemaphore, portBASE_TYPE *pxHigherPriorityTaskWoken )

: xSemaphoreCreateBinary(), xSemaphoreCreateCounting() 을 통하여 생성된 Semaphore를 ISR 내에서 release 하는 함수 . Mutex Type 의 경우 사용할 수 없다 .

– xSemaphore : 해당 Semaphore 의 Handle값– pxHigherPriorityTaskWoken : Semaphore 를 놓아 줌으로써 현재 실행되고 있는 Task 보다 높은

Priority 를 가진 Task 가 unblock 되었을 시 해당 변수를 pdTRUE 로 Set 해 준다 .

Semaphore API

Semaphore(cont.)

예제 1 : BinarySemaphore

Semaphore API 예제

Semaphore API 예제 (cont.)

예제 2 : Recursive Mutex 와 소유권 문제


예제 3 : Recursive Mutex


예제 4 : Counting Semaphore


Memory Management

RTOS 에서는 Task Stack, Queue, Semaphore 등을 생성할 때 Memory 를 할당받는다 . 하지만

이때 사용되는 malloc(), Free() 는 Fragmentation 에 의한 Memory 낭비가 있거나 Thread

Safe( 동시에 여러 개의 Thread 실행 시 결과의 Correct 를 보장 ) 에 문제 , 연속적인 메모리

할당이 아닐 수 있으므로 생기는 비결정적 (Non – Determination) 수행속도에 의해 RTOS 에서는

부적합 할 수 있다 . FreeRTOS 에서는 이를 보장하기 위해서 malloc(), Free() 대신에 pvPortMal-

loc(), vPortFree() 를 Portable 계층에서 정의하여 Thread safe 와 Memory낭비를 줄여주는

Scheme 인 Heap_1, Heap_2, Heap_3 를 지원하고 있다 . Heap방식의 선택은 Compile 시 Make

file 설정을 통해 선택이 가능하다 .

프로그램 상에서 Task 나 Queue 가 Delete 되지 않을 경우 사용되며 , Memory 할당 시에는 pvPortMalloc() 을 통해 Stack Size 에 맞춰 할당하게 되며 한번 할당되면 제거를 하지 않는 프로그램에 맞는 Scheme 이다 .

A → B → C 순으로 시간이 경과 할 때마다 Task 가 들어오면 차례로 Task 의 Size 별로 Heap영역을 할당하게 된다 .

Heap_1.c

Memory Management(cont.)

Memory 를 5 bytes, 25 bytes, 100 bytes 단위로 Block 을 구축하여 Memory 영역 할당 시 pvPortMalloc() 을 통하여 요구된 Memory 영역의 크기와 비교 가장 요구조건을 만족시키면서 낭비가 없는 Block 을 선택하여 설정하게 된다 . 해당 Memory 영역과 남은 Memory Block 들은 list 를 통하여 관리되고 사용되고 있는 Memory 영역을 제거할 경우에는 vPortFree() 를 통하여 제거한 후 해당 블록을 빈상태로 list 에서 관리하게 된다 . 또한 할당 후 Block 내에 남은 Memory 들은 다시 단위로 쪼개어 Block 화 함으로써 Frag-mentation 을 줄이게 한다 .

Heap_2.c

Memory Management(cont.)

free rtos seminar

Software