Chapter 05 임베디드 소프트웨어 구조 살펴보기 5.1 라운드로빈 구조 5.2 인터럽트 라운드로빈 구조
Download
Report
Transcript Chapter 05 임베디드 소프트웨어 구조 살펴보기 5.1 라운드로빈 구조 5.2 인터럽트 라운드로빈 구조
Chapter 05
임베디드 소프트웨어 구조 살펴보기
5.1 라운드로빈 구조
5.2 인터럽트 라운드로빈 구조
5.3 펑션큐스케줄링 구조
5.4 RTOS 구조
5.5 알맞은 소프트웨어 구조의 선택
임베디드 소프트웨어 구성
하드웨어와 통신하기 위한 부분
인터럽트 처리
애플리케이션 서비스를 위한 부분
Task code
2
임베디드 소프트웨어 구조를 결정하기 위한 요소
얼마나 많은 시스템의 응답을 제어해야 하는가?
3
라운드로빈 구조
가장 단순한 방식
서비스가 필요한 장치들은 순차적으로 순회하면서 서비스를 해주는
방식
비교적 느린 응답시간을 허용하거나, 서비스를 요구하는 장치가 자
주 변하지 않는 경우
e.g. 디지털 멀티미터, 디지털 시계, 전자레인지 etc.
4
라운드로빈 방식이 부적절한 경우
마이크로 프로세서가 메인 루프를 도는 시간 보다 짧은 응답시간을
요하는 경우
수행할 작업이 긴 시간을 소요하는 경우
이 구조는 깨어지기 쉬움
다른 장치의 추가
5
라운드 로빈 구조의 예
void main (void)
.생략표시
{
.
while (TRUE)
if (!! I/O 장치 Z가 서비스가 필요하다면)
{
{
if (!! I/O 장치 A가 서비스가 필요하다면)
!! I/O 장치 Z에 대해 필요한
것을 처리한다.
{
!! 데이터를 I/O 장치 Z에
넘겨주거나 가져온다.
!! I/O 장치 A에 대해 필요한 것을
처리한다.
}
!! 데이터를 I/O 장치 A에 넘겨주거나
가져온다.
}
}
}
if (!! I/O 장치 B가 서비스가 필요하다면)
{
!! I/O 장치 B에 대해 필요한 것을
처리한다.
!! 데이터를 I/O 장치 B에 넘겨주거나
가져온다.
}
6
인터럽트 라운드로빈 구조
라운드로빈 구조에 인터럽트 개념 도입
처리방식
1.
메인 루프를 반복 탐색
2.
인터럽트 발생시 해당 ISR로 분기
3.
인터럽트 처리 후, 수행할 Task Code flag 설정
4.
Task Code 수행, flag reset
-
Task code 처리 중 인터럽트 발생시 인터럽트 우선 처리
단점
ISR과 main의 task code 사이에서 데이터 공유 문제가 발생할 수 있음
모든 태스크 코드들이 동일한 우선순위로 실행됨
7
인터럽트 라운드로빈 구조의 예
인터럽트 라운드로빈 구조의 예
void interrupt vHandleDeviceB (void)
BOOL fDeviceA = FALSE;
{
BOOL fDeviceB = FASLSE;
!! I/O 장치 B를 처리한다
.
fDeviceB = TRUE;
.
}
.
.
BOOL fDeviceZ = FALSE;
.
.
Void interrupt vHandleDeviceA (void)
void interrupt vHandleDeviceZ (void)
{
{
}
!! I/O 장치 A를 처리한다
!! I/O 장치 Z를 처리한다
fDeviceA = TRUE;
fDeviceZ = TRUE;
}
8
인터럽트 라운드로빈 구조의 예 (Cont’d)
if (fDeviceB) {
void main (void)
fDeviceB = FALSE;
{
!! I/O 장치 B로 데이터를 넘겨
주거나 가져 온다
while (TRUE)
}
{
...
if (fDeviceA) {
if (fDeviceZ) {
fDeviceA = FALSE;
fDeviceZ = FALSE;
!! I/O 장치 A로 데이터를
넘겨 주거나 가져 온다
!! I/O 장치 Z로 데이터를 넘겨
주거나 가져 온다
}
}
}
}
9
라운드로빈 구조를 위한 우선 순위 레벨
10
펑션큐스케줄링 구조의 특징
ISR은 인터럽트 발생시 수행해야 할 코드(함수)에 대한 포인터를 펑션 큐에
삽입한다.
메인 함수는 펑션 큐로부터 함수를 읽어와서 수행한다.
인터럽트 루틴이 발생하는 순서대로 메인 함수가 함수를 호출해야 할 필요
는 없다.
즉, 우선 순위를 고려해서 함수가 호출되도록 코드를 작성할 수 있다.
최악의 대기 시간: 태스크 코드 함수 중에서 제일 긴 함수의 수행 시간 +
ISR의 수행 시간
가장 긴 코드가 막 시작 되었을 때, 우선 순위가 가장 높은 인터럽트가 발생하는
경우
낮은 우선 순위의 태스크 코드가 수행시간이 길다면, 높은 우선 순위의 함수의
응답시간에 영향을 줄 수 있음 (단점)
낮은 우선 순위의 태스크 코드의 응답성이 나빠질 가능성이 있음(단점)
제어가 다소 복잡
11
펑션큐스케줄링 구조
평션큐스케줄링 구조의 예
!! 함수 포인터들의 큐;
void main (void)
{
while (TRUE)
void interrupt vHandleDeviceA (void)
{
{
while (!!함수 포인터들의 큐가 비어 있다
면 기다림)
!! I/O 장치 A에 대해 필요한
것을 처리
!! function_A 에 대한 함수
포인터를 함수 포인터들의
큐에 삽입
}
…
!! 큐에 있는 첫 번째
함수 호출
}
}
void function_A (void)
void interrupt vHandeDeviceB (void)
{
!! 장치 A 에게 필요한 일을 처리
{
!! I/O 장치 B에 대해 필요한 일을 처리
!! function_B 에 대한 함수 포인터를
함수 포인터들의 큐에 삽입
}
}
void function_B (void)
{
!! 장치 B 에게 필요한 일을 처리
}
12
5.4 RTOS 구조
RTOS 구조의 예
void interrupt vHandleDeviceA (void)
void Task1 (void)
{
{
while (TRUE)
!! I/O 장치 A에 대해 필요한 일을 처리한다
{
!! 시그널 X를 설정한다
!! 시그널 X를 기다린다
}
준다
void interrupt vHandleDeviceB (void)
{
!! I/O 장치 B에 대해 필요한 일을 처리한다
!! 시그널 Y를 설정한다
}
!! I/O 장치 A로부터 데이터를 받거나
}
}
void Task2 (void)
{
while (TRUE)
.
{
.
!! 시그널 Y를 기다린다
.
준다
!! I/O 장치 B로부터 데이터를 받거나
}
}
13
RTOS(Real-Time Operating System)와 다른 구조
들의 차이점
인터럽트 루틴과 태스크 사이에서 필요한 시그널의 교환은 RTOS가
처리 (프로그래머를 위한 편의사항)
코드 작성자는 다음에 수행 될 함수에 대해서 관여하지 않아도 됨
(프로그래머를 위한 편의사항)
이 부분은 모두 RTOS가 알아서 처리해 줌
RTOS는 다른 서브루틴을 수행하기 위해서, 현재 처리 중인 서브루
틴을 일시 정지 시킬 수 있음 (RTOS의 본질)
RTOS는 ISR의 응답 우선 순위 뿐만 아니라, 태스크 코드의 우선 순위도
조정 가능
14
RTOS 구조의 단점
RTOS 구조의 기본적인 단점
RTOS 구입 비용
RTOS 자체가 시스템의 프로세스 시간을 약간 소비
15
RTOS 구조를 위한 우선 순위 레벨
16
다양한 소프트웨어 구조의 특징
소프트웨어 구조
우선 순위
사용 가능 여부
태스크 코드를 위
한 최악의 경우 응
답 시간
코드를 수정했을
때 응답의 안정성
복잡도
라운드로빈
불가능
모든 태스크 코드
의합
좋지 않음
매우 단순
인터럽트 라운드
로빈
우선순위를 갖는 인
터럽트 루틴과, 모
두 같은 우선 순위
를 갖는 태스크 코
드
모든 태스크 코드
의 수행 시간(더하
기 인터럽트 루틴
수행 시간)
인터럽트 루틴을
위해서는 좋음, 태
스크 코드를 위해
서는 좋지 않음
인터럽트 루틴과
태스크 코드 간의
공유 데이터 문제
를 처리해야 함
펑션큐 스케줄링
우선순위를 갖는 인
터럽트 루틴과, 우
선순위를 갖는 태스
크 코드
가장 긴 함수의 수
행 시간 (더하기
인터럽트 루틴의
수행 시간)
상대적으로 좋음
공유 데이터 문제
를 처리해야 하고,
함수 큐를 다루는
코드를 작성해야
함
RTOS
우선순위를 갖는 인
터럽트 루틴과, 우
선순위를 갖는 태스
크 코드
응답 지연 시간이
없음(인터럽트 루
틴의 수행시간은
더해야 함)
매우 좋음
가장 복잡한 구조
임(대부분의 복잡
한 부분은 운영체
제 안에 숨겨져 있
다)
17
5.5 알맞은 소프트웨어 구조의 선택
설계하려는 시스템의 응답 조건에 적절한 시스템 중 가장 간
단한 구조를 선택
만약 설계하려는 시스템이 RTOS를 사용해야 할 필요가 있는
응답 조건을 가지고 있다면, RTOS 구조를 사용하는 방향으로
결정을 해야 함
임베디드 시스템 소프트웨어 작성 자체가 복잡하기 때문에, 필요
이상으로 복잡한 구조의 선택은 임베디드 시스템 소프트웨어 작
성을 더욱 복잡하게 만듦
대부분의 상용 RTOS는 시스템을 테스트 하고, 디버깅을 쉽게 할
수 있는 유용한 툴들을 같이 제공
필요한 경우 여러 구조들(라운드로빈, 인터럽트 라운드로빈,
…)을 혼합한 형태를 만들 수도 있음
18
요약
응답 조건은 소프트웨어 구조를 선택하는데 있어서 가장 중요한 요
소이다.
네 가지 소프트웨어 구조 각각의 특징은 표 5.1에 나와 있다.
일반적으로, 하려는 일에 맞는 가장 간단한 구조를 택하는 것이 좋
다.
RTOS 구조의 장점 중의 하나는 RTOS를 구입 함으로서, 직접 코드
를 작성하지 않아도 어떤 문제들은 해결을 할 수가 있다는 것이다.
어떤 시스템은 몇 가지 구조를 같이 사용하는 혼합 구조를 사용할
수도 있다.
19