В статье предлагается ряд простых правил, упрощающих разработку приложений, использующих прерывания.
- Постарайтесь делать обработчик прерываний как можно короче. В идеале он должен быть не более полстраницы кода на языке C. Если пишите на ассемблере, то постарайтесь уместить код максимум на одной странице. Длинные обработчики, могут нарушить время работы программы.
- Время выполнения кода в обработчике также должно быть сведено к минимуму. 100-200 тактовых циклов хватит вполне, хотя насчет точного количества можно подискутировать. Если вам нужно много чего обработать, то лучше сгрести данные в буфер ожидания и позволить основному циклу или подпрограмме не-обработчика сделать все остальное.
- Стоит знать наихудшее время выполнения обработчика, тогда можно планировать программу для работы в реальном времени. Избегайте циклов, потому что они делают проблемные места еще «проблемнее», и программа может войти в бесконечный цикл из-за мелочи, о которой вы даже не подозревали.
- Конечно, стоит делать планирование работы программы в реальном времени, что, впрочем, имеет свои сложности из-за того, что обработчики различных прерываний не вытесняют друг друга в пределах одного уровня приоритета.
- Не тратьте время в обработчике (например, не нужно организовывать цикл для ожидания ответа от какого-либо периферийного модуля).
- Сохраняйте значения регистров, которые вы изменяете в обработчике, если аппаратная часть не делает это за вас (это кажется очевидным, но если вы используете множество регистров, то можно потратить много времени на поиск места, где регистр, задействованный в основном цикле, изменяется обработчиком).
- Определите источник прерывания в самом начале обработчика (прямо после сохранения значений регистров). Это облегчает ревизию и анализ кода.
- Не «переразрешайте» прерывания внутри обработчика, это только приводит к проблемам.
Также имеются некоторые моменты на системном уровне, разрешение которых положительно скажется на практике применения обработчиков прерываний.
- При получении доступа к переменной, используемой также в обработчике, убедитесь, что прерывания отключены. Работайте с такой переменной предельно короткое время, даже если вы уверены, что это безопасно (поведение оптимизатора компилятора трудно предугадать, и новая версия компилятора может генерировать несколько измененный код). В идеале защитите эти переменные правилами доступа, в итоге вы сможете изменять их только в одном месте кода.
- Объявляйте все переменные обработчика (и не только его) как volatile.
- Когда вы проводите анализ времени выполнения, не забывайте, что оно тратится и в обработчиках.
- Когда вы делаете анализ глубины стека, учитывайте наихудший случай, когда все прерывания срабатывают одновременно (особенно если ваш процессор поддерживает несколько уровней прерываний).
- Убедитесь, что все векторы прерываний инициализированы, даже если вы не планируете их использовать.
- Используйте только немаскируемые прерывания для катастрофических событий системы, например, системного сброса.
- Удостоверьтесь, что инициализируете все связанные с прерываниями структуры данных и периферийные модули, которые способны генерировать прерывания, до того как вы разрешили прерывания в цикле начальной загрузки.
- После включения сторожевого таймера, никогда не маскируйте прерывание от него.
- Если вы решили, что сделали что-то странное в обработчике, то вернитесь назад и устраните причину проблемы. Странные обработчики сулят только беды.
Перевод © digitrode.ru