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

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

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

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

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 Мбит / с, вы be ok!) - правильный момент включения / выключения isr, особенно если система также переходит в спящий режим - # прерываний. Может быть удивительно, если вы добавите механические переключатели, механические поворотные (сотни моментов размыкания / контакта до достижения устойчивого положения)

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

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

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

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

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

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