코루틴
RAM 제약이 심한 프로세서에서 사용, 32bit 마이크로 컨트롤러에서는 사용 잘 안 됨
태스크 형태처럼 보이지만, 태스크는 아니다
xCoRoutineCreate 이 함수로 코루틴 만들 수 있음, 우선 순위 갖춘다. 스택 메모리를 공유한다
crSTART 함수로 무조건 코루틴 핸들을 넣어 시작해줘야한다
종료할 때 crEND 해야함
코루틴 돌려면, 이 스케줄 함수를 지속적으로 불러줘야함
인터럽트
이렇게 인터럽트 빈도가 과하게 몰려있고, 안 몰려있는 시스템에서, Deferred Interrupt 사용한다
Deferred Interrupt
인터럽트가 당장 발생하긴 하지만, 처리(실행)를 미루는 것
우선 순위가 가장 높은 세미 인터럽트인 테스크를 만들고, 하드웨어 인터럽트에서 세미 인터럽트를 부르게 한다
인터럽트는 이 테스크를 선점하지만, 다른 테스크보다는 우선순위가 높아서, 바쁜 인터럽트 처리가 다 끝나고 한가한 시간에 제일 먼저 처리하게 한다
*시간을 많이 소모하는 GPIO 인터럽트
이런식으로 틱카운트를 출력하는 프로그램에서, 시간이 오래 걸리는 인터럽트를 추가한 경우,
거의 타이머틱을 실행 못하여서, 저 시간이 오래 걸리는 인터럽트 때문에, 틱 인터럽트가 많이 발생하지 못한다
하지만 Deffered 인터럽트를 활성화하면
저 GPIO인터럽트가 있음에도 불구하고, 틱 인터럽트 처리가 많이 된 것을 알 수 있다
소스코드 분석
GPIO인터럽트가 발생할 때 마다, vTaskNotifyGiveFromISR 함수가, 알림값을 증가시킨다. 이후 Handle1에 해당하는 테스크 함수 내부에서 ulTaskNotifyTake에 담긴 알림값을 활용해서, 그 값이 0이 될 때 까지 기존에 시간이 오래걸리던 GPIO 함수를 처리해준다
시간이 많이 걸리는 작업은 태스크에서 처리가 되고, 인터럽트는 인터럽트대로 즉시 처리가 된다. 즉 타이머 인터럽트가 즉각적으로 작동된다
시스템 성능 최적화 방법
- 전역 변수 선언 및 활용하는 태스크 수를 줄인다
- 시간 소요가 많은 인터럽트 루틴은 IPC(xSemaphoreGive)를 활용해, 테스크에서 그 일을 수행하도록 구현한다
- 간단한 코드의 임계영역 보호는 세마포어보다, taskENTER_CRITICAL 활용
- 자주 호출되는 함수는 인라인 어셈블리 사용
- 클럭 속도를 가감하여 최적의 CPU 스피드 결정
- TICK 시간이 절대적으로 지켜지는지 판단
HW 타이머와 ISR 개수가 일치하는지
우선순위 배정
중요해서 우선순위를 높게 하는 것이 합리적인가?
정답은 아니다. 평등한 관점에서, 작업의 특성을 이해한다
- 모든 태스크의 특징을 수치화하여서 그 수치만을 가지고 우선순위를 결정한다
(마감시간, bound time)
예제
인터럽트는 빨리 처리해야하는 것이 아니다
인터럽트라는 것은 하드웨어가 소프트웨어적인 작업을 못한다. 소프트웨어적 작업은 CPU의 고유 작업인데, 인터럽트가 하드웨어의 작업을 CPU에게 떠 넘겨서 처리해달라고 하는것일 뿐
인터럽트를 빨리 처리하는 관점보다, 제 시간안에 처리해야하는 관점으로 바라보자
FreeRTOS 동적메모리 할당 방법
heap_2.c
heap_4.c
