Pull to refresh

Пара копеек про микроконтроллеры

Reading time 3 min
Views 15K
Довелось мне проработать три года в фирме, которая занималась встраиваемыми системами, а именно автоматикой, что поезда водит. Жесткое реальное время, серьезное тестирование и выгрызание микросекунд везде, где только можно. Попробую дать пару советов тем, кто интересуется встраиваемыми системами (а по постам на хабре я понял, что таких — немало ;-)

Железка у нас была совсем не слабая — С167, 16 МГц тактовая, внешняя шина с 4-мя чипселектами, куча перефирии на камне… Да и задачки стояли такие, что еле железки хватало — опрос чуть ли не 2000 дискретных входов, да еще и с хитрой циклограммой, упаковка данных в специальные структуры и обмен по CAN-сетям этой информацией… И все это — за 1 миллисекунду!
А теперь — советы :-) Не всегда верные и применимые к вашему камню, но вдруг помогут.

Считайте, что все ваши системы — системы жестокого реального времени. То есть системы, где отклик на внешнее воздействие должен быть не позднее n-ного количества времени. Желательно еще и минимального ;-)
Функция main() должна оканчиваться бесконечным циклом. Без всяких return вообще. Ибо черт знает, куда управление передастся после выхода из нее!
Предусматривайте состяние системы, в котором она принесет минимальный вред! Так называемый защитный отказ. Если вдруг у робота отваливается датчик положения исполнительного органа — он должен ОСТАНОВИТСЯ, а не пытаться перейти в безопасное положение (куда он перейдет с отрубленным датчиком — тоже знает черт). Хорошо бы, что бы и пользователь узнал, что устройство в таком состоянии. Например, перевести часы в 88:88 — лучше, чем оставить дисплей неизменным. Очень полезно проверять оборудование, подключенное к микроконтроллеру, хотя бы при инициализации. Не всякое можно проверить, но то, что можно — обязательно!
Про реальное время. Программа для микроконтроллера — многопоточная в большинстве случаев, и main() должна быть потоком с минимальным приоритетом. Потоки с более высоким приоритетом — обработчики прерываний. Прерывания отключать без крайней необходимости (например, перехода в состояние защитного отказа) не следует. Обработчик прерывания не должен выполнятся дольше, чем минимальный период между прерываниями, а то не останется системе времени на менее приоритетные задачи. А как время оценивать — так это просто. Одна нога вывода микроконтроллера должна быть не сильно важна для функционирования устройства. Идеально на нее подключить светодиод и сигналить им обо всем, чем только можно :-) В общем, переключение состояния этой ноги поможет при помощи осцилла замерить время выполнения всего, чего угодно :-)
Грамотно расставляйте приоритет прерываний! В часах приоритет — за кнопками управления. Если есть кнопка аварийной остановки — она должна иметь высший приоритет: мало ли что в устройстве произойдет и где оно зациклится, но должна быть возможность его остановить. Высший приоритет — у аварийных сигналов, далее — по важности функций устройства.
Очень важно учитывать время исполнения обработчика и периодичность возникновения прерываний для задач коммуникации. Вдруг выйдет, что прерывания по COM-порту происходят каждые 10 мкс и обработчик висит в нем 9 мкс. Как уже писал выше, программы многопоточны, поэтому используйте синхронизацию при доступе к одному объекту из разных потоков. Особенно к очередям приема-передачи. Один маленький баг в очередях, совмещенный с выскоим приоритетом коммуникационных прерываний — страшные вещи творит! :-)
Знай и люби оборудование! Проблемы на шине могут вылиться в долгие часы отладки и невоспроизводимые глюки. Использование ассемблера далеко не всегда оправдано: выигрыш в проценты времени может привести к плохой читаемости кода, особенно учитывая хорошие компиляторы для некоторых камней :-)

Вот, вроде, и вспомнил большинство подводных граблей, на которые наступал. Может, вы делаете и вовсе несерьезные устройства забавы ради, и жесткое реальное время вовсе не нужно, но почему бы не делать устройства с серьезным подходом? Вдруг именно с этих «игрушек» начнется ваша дорога в серьезные системы? Удачи всем в конструировании, программировании и отладке :)

PS. Если общественность скажет, что за коллективный блог есть для подобного — перенесу тут же.
PPS. Спасибо комментаторам — натолкнули на еще один совет: прерывания — добро, а вот опрос в цикле там, где можно использовать прерывания — зло! Хоть прерывания и кажутся страшными и ужасными :-)
Tags:
Hubs:
+71
Comments 44
Comments Comments 44

Articles