Как Вы тестируете свой модуль обработки прерываний?
Каждый объект Python имеет __dict__ атрибут, который является словарем, содержащим все другие атрибуты. например, когда Вы Python типа self.attr на самом деле делаете self.__dict__['attr']. Поскольку можно предположить использовать словарь для хранения атрибута, занимает некоторое дополнительное место & время для доступа к нему.
Однако, когда Вы будете использовать __slots__, любой объект, созданный для того класса, не будет иметь __dict__ атрибут. Вместо этого весь доступ атрибута сделан непосредственно через указатели.
Поэтому, если хотят структуру стиля C, а не абсолютный класс, можно использовать __slots__ для уплотнения размера объектов & сокращение времени доступа атрибута. Хорошим примером является класс Точки, содержащий атрибуты x & y. Если Вы собираетесь иметь много точек, можно попытаться использовать __slots__ для сохранения некоторой памяти.
4 ответа
Я предлагаю вам попытаться создать и другие стимулы.
Часто также аппаратные прерывания могут быть вызваны программным обеспечением (автоматическое тестирование) или отладчиком путем установки флага. Или как прерывание через ввод / вывод. Или прерывание по таймеру. Или вы можете просто установить бит прерывания в контроллере прерываний через отладчик во время пошагового выполнения.
Вы можете добавить некоторые проверки во время выполнения того, чего не должно происходить. Иногда я выбираю установку выходных контактов для внешнего мониторинга (хорошо, если у вас есть осциллограф или логический анализатор ...)
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 настолько короткие, что я могу воздержаться от вложенности ... если вы сможете, это даст вам дополнительную простоту и большую производительность.
[РЕДАКТИРОВАТЬ] Конечно, ISR также необходимо протестировать на аппаратном обеспечении в системе. Помимо пошагового подхода, вы можете доказать: - стабильность системы при максимальной загрузке прерываний (желательно, в несколько раз превышающей прогнозируемую максимальную нагрузку; если ваш последовательный драйвер 115 кбит / с также может обрабатывать 2 МБ / с, все будет в порядке!) - правильный момент включения / отключения isr, особенно если система также переходит в спящий режим - # прерываний. Может быть удивительно, если вы добавите механические переключатели, механические поворотные (сотни моментов размыкания / контакта до достижения устойчивого положения)
Я рекомендую тестирование на реальном оборудовании. Обработка прерываний по своей сути случайна и непредсказуема.
Используйте генератор сигналов и подайте прямоугольный сигнал на соответствующий вывод прерывания. Используйте несколько генераторов (или один с несколькими выходами) для тестирования нескольких линий IRQ и проверки обработки приоритетов.
Поэкспериментируйте с повышением и понижением частоты на генераторах сигналов (варьируйте скорости между ними) и посмотрите, что произойдет.
Я не являюсь разработчиком встроенных систем, поэтому не знаю, возможно ли это, но как насчет того, чтобы отделить код, который обрабатывает прерывания, от механизма регистрации обратного вызова? Это позволит вам написать код симулятора, запускающий события прерывания, как вам нравится ...
Для подобных вещей я настоятельно рекомендую что-нибудь вроде проверки модели SPIN . Вы завершаете тестирование алгоритма, а не кода, но тестирование исчерпывающее . В свое время я обнаружил ошибку в gdb , используя эту технику.