동작 개수 대신 응답 조건을 적습니다
센서 읽기, 통신, 출력이 여러 개라고 해서 RTOS가 필요한 것은 아닙니다. 각 작업의 도착 조건, 허용 지연, 실행 시간, 대기 원인과 공유 자원을 적습니다. 짧은 비차단 처리와 상태 머신으로 요구를 만족하면 단일 이벤트 루프도 선택지입니다. 한 작업의 긴 대기가 다른 응답을 막는다면 구조를 나누는 이유가 됩니다.
요구 지연·주기·최악 실행 경로
대기·공유 락·인터럽트 제약
루프와 태스크 구조 비교
시간·스택·메모리를 계측
우선순위가 마감 시간을 자동 보장하지는 않습니다
FreeRTOS V11.1.0 tasks.c의 단일 코어 태스크 선택은 준비 상태인 가장 높은 우선순위를 찾습니다. 선점과 같은 우선순위의 time slicing은 설정의 영향을 받습니다. 우선순위를 부여했다고 최악 응답 시간이나 모든 deadline이 자동 보장되는 것은 아닙니다.
긴 임계 구역, 상위 우선순위 작업의 실행, 공유 락과 드라이버 대기를 응답 시간에 포함합니다. ISR에서 오래 처리하면 태스크를 나누어도 문제가 남습니다. 주기만으로 우선순위를 결정하기 전에 실행 시간·blocking·실패 대응 조건을 확인하고 대상에서 측정해야 합니다. 이 글은 특정 시스템의 스케줄 가능성 증명이 아닙니다.
일정한 주기 요청과 실제 실행 시점을 나눕니다
V11.1.0 task.h의 지연 API 설명에서 vTaskDelay는 호출한 시점에 상대적인 지연입니다. xTaskDelayUntil은 이전 기준 시각과 주기를 이용해 unblock 시점을 정하므로, 작업 수행 뒤 상대 지연을 반복하며 생기는 기준 이동과 구별됩니다. 이전 명칭 vTaskDelayUntil과 혼동하지 말고 사용하는 버전의 API를 확인합니다.
unblock 시각이 곧 CPU에서 실행을 시작하는 시각은 아닙니다. tick 해상도, 더 높은 우선순위 작업과 인터럽트, 주기를 초과한 작업 때문에 실제 시작은 달라집니다. 요구 주기·시작 시각·완료 시각을 따로 측정하고 주기를 놓쳤을 때의 정책도 정합니다.
메모리는 태스크 스택만 합산하지 않습니다
각 태스크의 스택과 TCB, queue·동기화 객체, 드라이버 버퍼, 공유 heap과 인터럽트용 공간을 함께 봅니다. xTaskCreateStatic의 스택 버퍼는 StackType_t 배열이며 원소 크기는 포트에 따라 다릅니다. 스택 깊이 인자를 무조건 바이트로 계산하지 않습니다. 태스크 개수나 고정 RAM 숫자 하나로 도입 가능성을 판정하지 않습니다.
정적 할당은 메모리 사용 위치를 예측하는 데 도움이 되지만 스택 초과와 교착을 저절로 없애지는 않습니다. 동적 할당을 쓴다면 heap_4의 전체 여유와 최대 연속 블록도 구분합니다. LinkedIn 615의 원고를 공식 구현과 대조했으며 실제 RTOS 부하 시험은 하지 않았습니다.
English summary. Start with response-time, blocking and memory requirements, not task count. Priority scheduling and periodic unblocking do not guarantee deadlines. Account for port-specific stack units and all supporting objects.