Как вы тестируете свой модуль обработки прерываний?

Question

У меня есть модуль обработки прерываний, который управляет оборудованием контроллера прерываний на встроенном процессоре. Теперь я хочу добавить больше тестов к нему. В настоящее время тесты только проверяют, работает ли вложение прерываний, делая два программных прерывания изнутри ISR, одно с низким приоритетом и одно с высоким приоритетом. Как я могу проверить этот модуль дальше?

Answer 1

Я предлагаю вам попробовать создать и другие стимулы.

Часто аппаратные прерывания также могут быть вызваны программным обеспечением (автоматическое тестирование) или отладчиком, установив флаг. Или как прерывание через ввод / вывод. Или прерывание по таймеру. Или вы можете просто установить бит прерывания в контроллере прерываний через отладчик, пока вы выполняете один шаг.

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

low_prio_isr(void)
{
    LOW_PRIO_ISR=1;
    if (1 == HIGH_PRIO_ISR)
    { this may never happen. dummy statement to allow breakpoint in debugger }

}

high_prio_isr(void)
{
    HIGH_PRIO_ISR=1
} 

Недостаток программного прерывания заключается в том, что момент зафиксирован; всегда одна и та же инструкция. Я полагаю, вы хотели бы видеть доказательства того, что это всегда работает; без тупиков.

Для процедур обработки прерываний я считаю обзоры кода очень ценными. В конце концов, вы можете протестировать только те ситуации, которые себе представляли, и в какой-то момент усилия по тестированию будут очень высокими. Общеизвестно, что ISR трудно отлаживать.

Я думаю, что полезно предоставить тесты для следующего: - isr не прерывается для прерывания с более низким приоритетом - isr не прерывается для такого же приоритетного прерывания - прерывание isr для прерывания с более высоким приоритетом - максимальное количество вложений в пределах стековых ограничений.

Некоторые из ваших тестов могут оставаться в коде в качестве инструментария (поэтому вы можете отслеживать, например, максимальный уровень вложенности.

Да, и еще одна вещь: мне обычно удавалось держать ISR настолько короткими, что я могу воздерживаться от вложения ... если вы можете, это даст вам дополнительную простоту и большую производительность.

[EDIT] Конечно, ISR также должны быть проверены на оборудовании в системе. Помимо пошагового, пошагового подхода вы можете доказать: - стабильность системы при максимальной нагрузке прерывания (предпочтительно, в несколько раз превышающей прогнозируемую максимальную нагрузку; если ваш последовательный драйвер со скоростью 115 кбит / с также может обрабатывать 2 Мбит / с, все будет в порядке!) - правильный момент включения / выключения isr, особенно если система также переходит в спящий режим - Количество прерываний. Может быть удивительно, если вы добавляете механические переключатели, механические поворотные (сотни моментов разрыва / контакта до достижения устойчивой ситуации)

Answer 2

Я рекомендую тестирование на реальном оборудовании. Обработка прерываний по своей природе случайна и непредсказуема.

Используйте генератор сигналов и подайте прямоугольную волну на соответствующий контакт прерывания. Используйте несколько генераторов (или один с несколькими выходами) для тестирования нескольких линий IRQ и проверки обработки приоритетов.

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

Альтернатива: Если на вашей платформе есть таймеры, которые могут вызывать прерывания, вы можете использовать их вместо внешнего оборудования.

Answer 3

Для подобных вещей я настоятельно рекомендую что-то вроде модель проверки SPIN . Вы заканчиваете тестирование алгоритма, а не кода, но тестирование является исчерпывающим . Когда-то, Я нашел ошибку в gdb, используя эту технику.

Answer 4

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