Обработка многих источников прерываний

Question

Учтите, что существует более 100 способов прерывания от разных датчиков.Есть вероятность, что все это может произойти одновременно.Как программное обеспечение может быть разработано, чтобы справиться с этим эффективно?

Answer 1

Это зависит от того, оптимизируете ли вы время ожидания или пропускную способность.

Поскольку вы спрашивали об эффективности, я думаю, вы смотрите на пропускную способность. В этом случае один проверенный способ состоит в том, чтобы обработчики прерываний считывали датчики, ставили в очередь команду и состояние и возвращались немедленно.

У вас есть программный поток без прерываний, который выбирает команды из очереди и объявляет события для обработчиков. Это минимизирует ваше время переключения задач. Вы можете использовать специфичную для домена логику, чтобы объединять команды, выбрасывать команды, которые больше не актуальны, и т. Д.

По сути, именно так работают оконные системы. Каждый щелчок мыши, движение мыши, нажатие клавиатуры и т. Д. Приводит к тому, что команда ставится в очередь. Система управления окнами отбирает команды и вызывает соответствующий обработчик. Существует обширная логика для отбрасывания команд, которые не имеют отношения к моменту, когда они выбраны из очереди, для объединения команд и для их ускорения.

Сетевые стеки используют ту же модель. Пакеты ставятся в очередь на уровне сети, затем основной цикл отбирает их и использует инверсию модели управления для обработки каждого пакета.

Answer 2

Если ваша система действительно имеет сотни источников прерывания, эффективность может быть не единственной проблемой. Возможно, вам придется провести «анализ удержания», чтобы убедиться, что вы не нарушите требования в худшем случае.

Сначала измерьте время наихудшего случая для каждого ISR. Затем для каждого прерывания X:

1. Определить крайний срок: каково максимальное время, которое может пройти между прерыванием X и аварией (например, потеря данных, отсутствие окон связи и т. Д.) *
2. Определите наихудший сценарий других ISR, который может задерживать обслуживание прерываний X. В зависимости от структуры приоритетов вашего процессора, вам, возможно, придется учитывать прерывания, которые происходят непосредственно перед X, и те, которые возникают, пока X находится в ожидании.
3. Суммируйте все времена ISR, определенные в шаге 2. Если сумма больше, чем крайний срок, вам необходимо изменить дизайн.

Редизайн может включать ускорение ISR, настройку длины FIFO, изменение частоты прерываний (сбор большего количества данных реже или наоборот), настройку последовательностей, чтобы гарантировать, что определенные прерывания не будут происходить одновременно. Не существует универсальной стратегии. (хотя более быстрые ISR почти всегда полезны.)

Answer 3

Практическое правило заключается в том, что обработчики прерываний должны делать столько, сколько им нужно для обработки прерывания. Держите их «как можно короче».

Например, если ваше устройство должно получать сообщения через последовательный порт и отвечать на них: обработчик прерываний последовательного RX UART должен просто прочитать входящий байт и сохранить его в буфере (и убедиться, что буфер не переполнен) ). Вот и все. Затем задача основного цикла должна позже обработать данные в буфере и создать любой ответ в буфере, чтобы он мог передаваться обработчиком последовательных прерываний TX.

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