Прерывания в embedded-системах воспринимаются как благо: быстрый отклик, экономия ресурсов, «реакция по событию».
Но на практике именно прерывания часто становятся причиной плавающих багов, редких зависаний и поведения «раз в неделю, но навсегда».
Разберёмся, почему так происходит.
Иллюзия «быстрого и безопасного» кода
Основная ошибка — воспринимать обработчик прерывания как «обычную функцию, только быстрее».
На самом деле ISR — это код, который:
- выполняется вне нормального потока программы
- может прервать выполнение в любой момент
- работает с ограниченным стеком
- влияет на тайминги всей системы
Чем больше логики внутри ISR — тем выше риск нестабильности.
Накопление прерываний и скрытая перегрузка
Если источник прерывания срабатывает быстрее, чем ISR успевает отработать:
- флаги начинают накапливаться
- растёт латентность других прерываний
- появляются пропуски событий
Система может не падать, но:
- тайминги «плывут»
- протоколы начинают давать ошибки
- watchdog срабатывает без видимой причины
Особенно часто это встречается при:
- работе с UART на высоких скоростях
- таймерах с коротким периодом
- АЦП с частыми выборками
Приоритеты: источник хаоса №1
Неправильно расставленные приоритеты прерываний приводят к:
- взаимным блокировкам
- голоданию низкоприоритетных задач
- непредсказуемым задержкам
Типичная ошибка — давать «высокий приоритет всему важному».
В итоге важным оказывается слишком много.
Общие данные и гонки
ISR и основной код почти всегда работают с общими ресурсами:
- буферы
- флаги состояния
- счётчики
Без строгой синхронизации это приводит к:
- повреждению данных
- частичным записям
- багам, которые невозможно воспроизвести отладчиком
Особенно опасны:
- много байтовые структуры
- 16/32-битные переменные на 8-битных МК
- операции чтение-модификация-запись
Вложенные прерывания и стек
Вложенные прерывания выглядят удобно, но:
- быстро увеличивают использование стека
- усложняют анализ таймингов
- делают сбои «неуловимыми»
Переполнение стека в ISR — одна из самых неприятных причин нестабильности: устройство может работать дни, прежде чем сломаться.
Что делать, чтобы прерывания не ломали систему
Практика, которая реально работает:
- ISR делает минимум: установить флаг, сохранить байт, выйти
- вся логика — в основном цикле или RTOS-задаче
- чёткая схема приоритетов (не «на глаз»)
- контроль времени выполнения ISR
- защита общих данных (atomic, critical sections)
- мониторинг стека и нагрузки
Прерывания должны быть механизмом доставки событий, а не местом для логики.
Прерывания — мощный инструмент, но: чем больше «ума» в ISR, тем менее предсказуема система.
Стабильные embedded-проекты строятся не на количестве прерываний, а на архитектуре работы с ними.
Именно на этом уровне — архитектуры, таймингов и реальных условий эксплуатации — чаще всего и требуется инженерный разбор, а не просто выбор микроконтроллера или платы.