Chapter 05임베디드 소프트웨어 구조 살펴보기

5.1 라운드로빈 구조

5.2 인터럽트 라운드로빈 구조

5.3 펑션큐스케줄링 구조

5.4 RTOS 구조

5.5 알맞은 소프트웨어 구조의 선택

2

임베디드 소프트웨어 구성 하드웨어와 통신하기 위한 부분

인터럽트 처리

애플리케이션 서비스를 위한 부분 Task code

3

임베디드 소프트웨어 구조를 결정하기 위한 요소

얼마나 많은 시스템의 응답을 제어해야 하는가 ?

4

라운드로빈 구조 가장 단순한 방식

서비스가 필요한 장치들은 순차적으로 순회하면서 서비스를 해주는 방식

비교적 느린 응답시간을 허용하거나 , 서비스를 요구하는 장치가 자주 변하지 않는 경우

e.g. 디지털 멀티미터 , 디지털 시계 , 전자레인지 etc.

5

라운드로빈 방식이 부적절한 경우 마이크로 프로세서가 메인 루프를 도는 시간 보다 짧은 응답시간을 요하는

경우 수행할 작업이 긴 시간을 소요하는 경우 이 구조는 깨어지기 쉬움

다른 장치의 추가

6

라운드 로빈 구조의 예void main (void)

{

while (TRUE)

{

if (!! I/O 장치 A 가 서비스가 필요하다면 )

{

!! I/O 장치 A 에 대해 필요한 것을 처리한다 .

!! 데이터를 I/O 장치 A 에 넘겨주거나 가져온다 .

}

if (!! I/O 장치 B 가 서비스가 필요하다면 )

{

!! I/O 장치 B 에 대해 필요한 것을 처리한다 .

!! 데이터를 I/O 장치 B 에 넘겨주거나 가져온다 .

}

. 생략표시 .

if (!! I/O 장치 Z 가 서비스가 필요하다면 )

{

!! I/O 장치 Z 에 대해 필요한 것을 처리한다 .

!! 데이터를 I/O 장치 Z 에 넘겨주거나 가져온다 .

}

}

}

7

인터럽트 라운드로빈 구조 라운드로빈 구조에 인터럽트 개념 도입 처리방식

1. 메인 루프를 반복 탐색

2. 인터럽트 발생시 해당 ISR 로 분기

3. 인터럽트 처리 후 , 수행할 Task Code flag 설정

4. Task Code 수행 , flag reset

- Task code 처리 중 인터럽트 발생시 인터럽트 우선 처리 단점

ISR 과 main 의 task code 사이에서 데이터 공유 문제가 발생할 수 있음 모든 태스크 코드들이 동일한 우선순위로 실행됨

8

인터럽트 라운드로빈 구조의 예 인터럽트 라운드로빈 구조의 예

BOOL fDeviceA = FALSE;

BOOL fDeviceB = FASLSE;

.

.

.

BOOL fDeviceZ = FALSE;

Void interrupt vHandleDeviceA (void)

{

!! I/O 장치 A 를 처리한다

fDeviceA = TRUE;

}

void interrupt vHandleDeviceB (void)

{

!! I/O 장치 B 를 처리한다

fDeviceB = TRUE;

}

.

.

.

void interrupt vHandleDeviceZ (void)

{

!! I/O 장치 Z 를 처리한다

fDeviceZ = TRUE;

}

9

인터럽트 라운드로빈 구조의 예 (Cont’d)

void main (void)

{

while (TRUE)

{

if (fDeviceA) {

fDeviceA = FALSE;

!! I/O 장치 A 로 데이터를 넘겨 주거나 가져 온다

}

if (fDeviceB) {

fDeviceB = FALSE;

!! I/O 장치 B 로 데이터를 넘겨 주거나 가져 온다

}

. . .

if (fDeviceZ) {

fDeviceZ = FALSE;

!! I/O 장치 Z 로 데이터를 넘겨 주거나 가져 온다

}

}

}

10

라운드로빈 구조를 위한 우선 순위 레벨

11

펑션큐스케줄링 구조의 특징 ISR 은 인터럽트 발생시 수행해야 할 코드 ( 함수 ) 에 대한 포인터를 펑션

큐에 삽입한다 . 메인 함수는 펑션 큐로부터 함수를 읽어와서 수행한다 . 인터럽트 루틴이 발생하는 순서대로 메인 함수가 함수를 호출해야 할 필요는

없다 . 즉 , 우선 순위를 고려해서 함수가 호출되도록 코드를 작성할 수 있다 .

최악의 대기 시간 : 태스크 코드 함수 중에서 제일 긴 함수의 수행 시간 + ISR 의 수행 시간 가장 긴 코드가 막 시작 되었을 때 , 우선 순위가 가장 높은 인터럽트가 발생하는

경우 낮은 우선 순위의 태스크 코드가 수행시간이 길다면 , 높은 우선 순위의 함수의

응답시간에 영향을 줄 수 있음 ( 단점 )

낮은 우선 순위의 태스크 코드의 응답성이 나빠질 가능성이 있음 ( 단점 ) 제어가 다소 복잡

12

펑션큐스케줄링 구조 평션큐스케줄링 구조의 예

!! 함수 포인터들의 큐 ;

void interrupt vHandleDeviceA (void)

{

!! I/O 장치 A 에 대해 필요한 것을 처리

!! function_A 에 대한 함수 포인터를 함수 포인터들의 큐에 삽입

}

void interrupt vHandeDeviceB (void)

{

!! I/O 장치 B 에 대해 필요한 일을 처리

!! function_B 에 대한 함수 포인터를 함수 포인터들의 큐에 삽입

}

void main (void)

{

while (TRUE)

{

while (!! 함수 포인터들의 큐가 비어 있다 면 기다림 )

…

!! 큐에 있는 첫 번째 함수 호출

}

}

void function_A (void)

{

!! 장치 A 에게 필요한 일을 처리

}

void function_B (void)

{

!! 장치 B 에게 필요한 일을 처리

}

13

5.4 RTOS 구조 RTOS 구조의 예

void interrupt vHandleDeviceA (void)

{

!! I/O 장치 A 에 대해 필요한 일을 처리한다

!! 시그널 X 를 설정한다

}

void interrupt vHandleDeviceB (void)

{

!! I/O 장치 B 에 대해 필요한 일을 처리한다

!! 시그널 Y 를 설정한다

}

.

.

.

void Task1 (void)

{

while (TRUE)

{

!! 시그널 X 를 기다린다!! I/O 장치 A 로부터 데이터를

받거나 준다}

}

void Task2 (void)

{

while (TRUE)

{

!! 시그널 Y 를 기다린다!! I/O 장치 B 로부터 데이터를

받거나 준다}

}

14

RTOS(Real-Time Operating System) 와 다른 구조들의 차이점 인터럽트 루틴과 태스크 사이에서 필요한 시그널의 교환은 RTOS 가 처리

( 프로그래머를 위한 편의사항 )

코드 작성자는 다음에 수행 될 함수에 대해서 관여하지 않아도 됨 (프로그래머를 위한 편의사항 )

이 부분은 모두 RTOS 가 알아서 처리해 줌 RTOS 는 다른 서브루틴을 수행하기 위해서 , 현재 처리 중인 서브루틴을

일시 정지 시킬 수 있음 (RTOS 의 본질 )

RTOS 는 ISR 의 응답 우선 순위 뿐만 아니라 , 태스크 코드의 우선 순위도 조정 가능

15

RTOS 구조의 단점 RTOS 구조의 기본적인 단점

RTOS 구입 비용 RTOS 자체가 시스템의 프로세스 시간을 약간 소비

16

RTOS 구조를 위한 우선 순위 레벨

17

다양한 소프트웨어 구조의 특징

소프트웨어 구조 우선 순위 사용 가능 여부

태스크 코드를 위한 최악의 경우 응답 시간

코드를 수정했을 때 응답의 안정성 복잡도

라운드로빈 불가능 모든 태스크 코드의 합 좋지 않음 매우 단순

인터럽트 라운드로빈

우선순위를 갖는 인터럽트 루틴과 , 모두 같은 우선 순위를 갖는 태스크 코드

모든 태스크 코드의 수행 시간 ( 더하기 인터럽트 루틴 수행 시간 )

인터럽트 루틴을 위해서는 좋음 , 태스크 코드를 위해서는 좋지 않음

인터럽트 루틴과 태스크 코드 간의 공유 데이터 문제를 처리해야 함

펑션큐 스케줄링

우선순위를 갖는 인터럽트 루틴과 , 우선순위를 갖는 태스크 코드

가장 긴 함수의 수행 시간 ( 더하기 인터럽트 루틴의 수행 시간 )

상대적으로 좋음공유 데이터 문제를 처리해야 하고 , 함수 큐를 다루는 코드를 작성해야 함

RTOS

우선순위를 갖는 인터럽트 루틴과 , 우선순위를 갖는 태스크 코드

응답 지연 시간이 없음 ( 인터럽트 루틴의 수행시간은 더해야 함 )

매우 좋음가장 복잡한 구조임( 대부분의 복잡한 부분은 운영체제 안에 숨겨져 있다 )

18

5.5 알맞은 소프트웨어 구조의 선택 설계하려는 시스템의 응답 조건에 적절한 시스템 중 가장

간단한 구조를 선택 임베디드 시스템 소프트웨어 작성 자체가 복잡하기 때문에 ,

필요 이상으로 복잡한 구조의 선택은 임베디드 시스템 소프트웨어 작성을 더욱 복잡하게 만듦

만약 설계하려는 시스템이 RTOS 를 사용해야 할 필요가 있는 응답 조건을 가지고 있다면 , RTOS 구조를 사용하는 방향으로 결정을 해야 함 대부분의 상용 RTOS 는 시스템을 테스트 하고 , 디버깅을 쉽게

할 수 있는 유용한 툴들을 같이 제공

필요한 경우 여러 구조들 ( 라운드로빈 , 인터럽트 라운드로빈 , …) 을 혼합한 형태를 만들 수도 있음

19

요약 응답 조건은 소프트웨어 구조를 선택하는데 있어서 가장 중요한 요소이다 .

네 가지 소프트웨어 구조 각각의 특징은 표 5.1 에 나와 있다 .

일반적으로 , 하려는 일에 맞는 가장 간단한 구조를 택하는 것이 좋다 .

RTOS 구조의 장점 중의 하나는 RTOS 를 구입 함으로서 , 직접 코드를 작성하지 않아도 어떤 문제들은 해결을 할 수가 있다는 것이다 .

어떤 시스템은 몇 가지 구조를 같이 사용하는 혼합 구조를 사용할 수도 있다 .