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

Ответ 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
} 

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

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

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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