Урок 50. Latency budget и планирование времени в FreeRTOS

1. Тема дня

Переходим от «в среднем работает быстро» к вопросу:

какой максимум времени пройдет от аппаратного события до реакции?

Темы:

deadline;
period;
latency;
jitter;
WCET;
ISR latency;
scheduler latency;
priority inversion;
response-time analysis;
DMA buffer deadlines;
Flash/NVS interference;
latency histogram;
deadline misses.

Главная мысль: средняя загрузка CPU не доказывает выполнение сроков. При 20% CPU одна длинная critical section или Flash write может сорвать deadline.

2. Зачем это нужно

Фазовые входы

signal -> opto -> GPIO/ADC -> ISR/DMA -> queue -> input_task -> filter -> phase FSM

Общая задержка:

Tdecision = Thardware + Tinterrupt + Tqueue + Tscheduler + Tprocessing + Tfilter

Нужно отделять намеренный debounce от нежелательной задержки RTOS.

EC25 UART

115200 8N1:

Tbyte ~= 10 / 115200 = 86.8 us
256 bytes ~= 22.2 ms

Если UART consumer не работает дольше времени заполнения ring buffer, данные теряются.

ADC DMA

Tblock = Nsamples / Faggregate

Если half-buffer 128 samples, aggregate 32 ksample/s:

Tblock = 4 ms

Processing должен быть быстрее, желательно с запасом.

3. Теория

Компоненты latency

Ltotal = Lirq_disabled + Cisr + Lwake + Lschedule + Ctask + Bresource + Cout

Для каждого компонента нужен budget, measured max и deadline miss counter.

Response-time analysis

Для фиксированных приоритетов на одном ядре:

R_i(n+1) = C_i + B_i + J_i + sum(ceil((R_i(n)+J_j)/T_j) * C_j)

Если R > D, задача не укладывается.

Приоритеты

Приоритет определяется deadline, а не бизнес-важностью.

UART buffer переполнится через 10 ms -> UART service выше MQTT.
ADC half-buffer перезапишется через 4 ms -> ADC service выше logger.

Высокоприоритетная задача должна большую часть времени быть BLOCKED, а не крутиться в polling.

ESP32 SMP

На двухъядерном ESP32 учитывай:

affinity;
системные tasks;
spinlocks;
heap locks;
межъядерные очереди;
Flash operations;
shared memory bus.

Pinning помогает только если shared resources не становятся bottleneck.

FreeRTOS tick vs hardware time

vTaskDelayUntil() лучше для периодических задач, чем vTaskDelay(). Для microsecond timestamps используй esp_timer_get_time() или hardware timer/input capture.

Flash/NVS

Flash erase/write может задерживать task execution. Нельзя считать, что low-priority storage task не влияет на high-priority path.

Deadline miss

Deadline miss - системное событие, а не просто warning:

phase data -> DEGRADED;
UART loss -> resync parser;
ADC block miss -> drop block;
CAN FIFO overrun -> fault counter;
MQTT delay -> metric only.

4. Типичные ошибки

• Оценка только средней CPU load.
• Всем важным задачам одинаковый высокий приоритет.
• Logger выше UART RX.
• Parser работает в ISR.
• vTaskDelay() используется как точный период.
• DMA block period не учитывается.
• Mutex держится во время I/O.
• Два ядра считаются автоматическим real-time ускорением.
• Time-critical task unpinned на SMP без анализа.
• Flash erase/write исключен из threat model.
• Timestamp измеряется только в task.
• Хранится только среднее, без histogram.
• ISR drops не считаются.
• Каждый deadline miss печатается синхронно.
• Watchdog считается контролем micro-deadline.

5. Практическое задание на 30-60 минут

Создай LATENCY_BUDGET.md:

# Latency budget
| Pipeline | Period/min interval | Deadline | WCET target |
|---|---:|---:|---:|
| Phase GPIO ISR -> task | 2 ms | 500 us | 100 us |
| Phase raw -> FSM | 2 ms | 1 ms | 300 us |
| EC25 UART service | 5 ms | 2 ms | 500 us |
| ADC half-buffer | 4 ms | 4 ms | 1 ms |
| MQTT command | - | 500 ms | 20 ms |
| Logger | - | 2 s | 100 ms |

Добавь instrumentation:

ISR timestamp;
task-start timestamp;
processing-finished timestamp;
queue high water;
drops;
deadline misses;
histogram.

CLI:

latency phase
events=10042
irq_drops=0
scheduler:
min=8us
avg=24us
max=184us
deadline=500us
misses=0
end_to_end:
min=21us
avg=48us
max=241us
deadline=1000us
misses=0

Проведи прогоны:

A. Только GPIO input.
B. GPIO + EC25 UART traffic.
C. GPIO + MQTT + verbose logging.
D. GPIO + NVS commit / test Flash write.

6. Что почитать или попробовать дальше

• ESP-IDF FreeRTOS SMP scheduler, critical sections, ESP Timer, GPTimer, apptrace.
• CMSIS-RTOS2 Thread Management, Mutex Management, Message Queue.
• Response-time analysis для fixed-priority scheduling.
• SystemView/Tracealyzer для визуального анализа ISR/task scheduling.

Общий итог уроков 41-50

За эти 10 уроков мы прошли путь от внутренней архитектуры состояния до production-надежности:

FSM
→ бинарный протокол
→ fuzzing
→ fault injection
→ postmortem observability
→ reproducible release
→ Secure Boot / Flash Encryption
→ unique device identity
→ secure remote commands
→ latency budget

Ключевая идея серии: надежная embedded-система строится не только на драйверах и peripheral init. Она требует явных состояний, ограниченных буферов, проверяемых протоколов, безопасных обновлений, наблюдаемости, воспроизводимых релизов и измеренных временных бюджетов.