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

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

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

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

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

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

    Комментарии 44

      +5
      > программы многопоточны
      это действительно актуально, к примеру, для МК а-ля MC51?
      Или я отстал от жизни?..

      зы: хорошо бы в виде списочка оформить с выделением тезисов, чтобы читалось лучше.
        0
        Там, где есть прерывания, есть и другие потоки. Работа в один поток путем опроса (так назыаемый поллинг) — очень плохой вариант :-(
          +1
          для тех кто считает центы это актуально. ещё «дороже» им стоило видно нанять программиста на ARM.
          это идиотизм экономить 1 бакс и не ставить ARM, когда контроллер еле справляется. даже ARM7 хватило бы всё разрулить.
            +4
            А расскажите-ка сколько будет стоить переучить персонал, переписать весь софт, разработать новую аппаратную часть и поддерживать не 1 платформу, а сразу две? А потом еще и менять все жезезо в количестве сотен-тысяч модулей по всей стране, да еще и там, где живой человек не проездом на поезде оказывается раз в год? Ну и еще и как-то утилизировать пару тонн ненужного железа…
              +2
              Вот в том то и дело, что с каждым новым проектом на исчерпавшем себя контроллере, всё глубже и глубже вязнет фирма. Всё больше и больше новых изделий на старье. И всё дороже и дороже становится неизбежный переход в будущем.

              Ушли из фирмы из-за чего? если не секрет…
                +2
                А что это все персоналки до сих пор на x86 архитектуре, когда есть RISC всякие? И почему до сих пор на глючной венде, когда есть мегакрутая QNX? Железо создавалось не один год и не один год внедрялось.

                Ушел? Ну надоело немного, однообразно стало.
                  0
                  >А что это все персоналки до сих пор на x86 архитектуре, когда есть RISC всякие?

                  А я вот очень жду, когда начнут делать нормальные ноутбуки на ARM. Куплю себе обязательно такой.
                0
                Так может тогда добавить пункт — «старайтесь изначально грамотно и по-возможности с запасом по производительности выбирать железо»?

                Вобще говоря я тоже не очень понимаю смысла так жаться в автоматике для поездов. Это может быть актуально при разработке коммерческих девайсов, где объёмы огромные, а цена должна быть минимальная. Или в апаратной части летательных аппаратов/ракет/спутников, где лишний килограмм — это лишнее топливо. В этих случая использование даже ассемблера будет оправдано, поскольку одна программа сможет сэкономить миллионы, а стоить пусть даже тысячи долларов.

                  0
                  > поскольку одна программа сможет сэкономить миллионы, а стоить пусть даже тысячи долларов
                  Хотя, вполне возможно, что это как раз ваш случай.
                  Но не уверен, что наиболее актуальный для большинства.
                    0
                    Несомненно, железо надо с запасом брать. Но там история той платформы долгая, лет 5-8 ей уж точно. Когда оно создавалось она была с огромным запасом мощности. А потом пошли всякие высокоскоростные поезда, наращивание станций и прочие уже непонятные мне вещи. Проблема-то не в том, чтобы купить камень на 3 бакса дороже, проблема в новой платформе, переобучении и т.д. как я уже описал выше. Недавно общался с тамошними программистами — говорят, меняют аппаратную часть. Платформа, прожила лет 6 — не каждая железка может таким сроком похвастаться :-)
                      0
                      так и есть
                      но всё-таки это достаточно уникальный случай.

                      Наиболее распространён вариант, когда схемотехническое решение чётко готовится заранее и в соответствие с поставленными задачами. А на этом этапе нет никаких проблем взять ARM вместо AVR, и то и другое суть песок (кремний) и стоит копейки.
                        0
                        Да можно было бы и x86 взять какой-нибудь, запустить на нем QNX и радоваться, благо что «главная» железка всего этого комплекса несла на борту 3 реальных x86 и один «процессор» в ПЛИС. И наработки были и по ОС и по аппаратной части и по софту.

                        Очень хочу оттуда одну из железок ввода-вывода утащить в связи с заменой: сотня ног на ввод-вывод — «умный дом» вполне можно сделать :-)
              +2
              хабракат, плз…
                +1
                Спасибо. «как слышим — так и пишем», написал через «cat» :-)
                • НЛО прилетело и опубликовало эту надпись здесь
                    +2
                    OffTop:

                    Ну а что, если есть хабралюди, то должны быть хабракоты и хабрасобаки. Один хабракот вот щас на ногах у меня храпит :)
                    • НЛО прилетело и опубликовало эту надпись здесь
                0
                PS. Если общественность скажет, что за коллективный блог есть для подобного — перенесу тут же.
                Может быть этот? habrahabr.ru/blogs/DIY/
                0
                А можно ли немного рассказать о самом процесе запрограмирования?
                  0
                  О чем именно? Как программы писать? Или как программу заливать на железку?
                    0
                    ну как я понимаю, почти микропроцессоры работают через ком или параллельный? тоесть заливать через них, но об поподробнее если можно.
                      0
                      Сильно зависит от конкретного камня. Наш С167 через COM-порт загружал прошивку, если интересно — могу рассказать, но надо учитывать, что это — коммерческий камень, под него свободных компилеров и нет :-)

                      Есть еще заливка программы черех JTAG… Но рассказать я могу про C167, так как работал с ним.
                        0
                        А в принцыпе то, «алгоритм заливки» там идентичен почти?
                        А как программы писать то понятно, благодаря тому же топу о часах самодельных, если можно ссылки на какие то учебнички связаные чисто с командами кампей, или конкретного какого то.
                          0
                          Нет, разный он может быть везде. Если у камня память программ на борту — один, если используется внешняя флэшка — совершенно иной.
                • НЛО прилетело и опубликовало эту надпись здесь
                    +2
                    Есть выражение типа «внесу свои пять копеек» или что-то в этом духе.
                  • НЛО прилетело и опубликовало эту надпись здесь
                      +4
                      Потому что выражение «внести лепту» — древнее и библейское, и с американской идиомой не связано никак. Лепта — это копейка в Древнем Греции.
                      • НЛО прилетело и опубликовало эту надпись здесь
                          0
                          Наверное при том, что сама американская идиома не первоначальна ;) А фразу про «пять копеек» — я достаточно часто слышу и вижу ;)
                            0
                            И ваше американское выражение, и пять копеек пошли от той самой лепты. «Внести свою лепту» давно стало синонимом «внести свой вклад», а пять копеек — аналог этого выражения. И называть один дочерний фразеологизм калькой другого — по меньшей мере неверно.
                        0
                        Я в своё время работал тоже с реалтаймом, только для станков. ещё, правда у нас были не микроконтроллеры, а обычные пни. Но что запомнилось. Останов всегда хардварный. Т.е. большая красная кнопка отрубала питалово всего агрегата, без каких либо прерываний. Любой неправильный сигнал при проверке оборудования (да, проверок могло быть много ещё до старта алгоритма) запрещал дальнейшую работу. Любой неправильный код алгоритма должен был остановить станок и вернуть в исходное положение с обрывом или без обрыва алгоритма, это уже настраивалось. Концевики (датчики конца движения) всегда были защищены механическим остановом с обрубанием гидравлики, питалава и вобще чего угодно, лишь бы всё остановилось. Ну и конечно же любимая борьба за милисекунды, потому что на больших скоростях доля секунды могла означать вплоть до сантиметра ошибки по траектории. Было так же весело заниматься доводкой всяких частей на расстояния до нескольких микрон, особенно когда кривые движения нелинейные.

                        Короче, автоматизация — это мегаинтересно.
                          0
                          Не то слово!
                          Была интересная задача — контролировать состояние реле, коих было около 800 штук. Причем не просто контролировать, но и отслеживать возможные неполадки. В итоге система определяла обрыв проводов от реле, КЗ их между собой, замыкание на землю и на питающее напряжение… Ну и обработка данных была разделена на два потока и каждая стадия обработки сравнивалась :-)
                            0
                            Дада тоже хотел добавить про большую красную кнопку на отруб всего.
                            0
                            Это Вы, что-то из цепей автоблокировки разрабатывали?
                              0
                              Не, СЦБ у нас отдельно было. Мы ДЦ, ЭЦ и прочие страшные слова делали :-) Выдача управляющих сигналов на стрелки/светофоры и съем данных об их состоянии. Потом эти данные передавались в «мегамозг», аж о 4 процессорах под управлением QNX. Или этот «мегамозг» и выдавал команды, которые железка должна была выдать на дискретные выходу чтобы оборудование их получило.
                                0
                                ясно) а мы теперь проектируем эти самые ДЦ, ЭЦ на ваших микрухах.
                                кстати, интересно, кому РЖД отдала такой кусок пирога на разработку если не секрет?
                              –3
                              все это делается на раз на контроллерах siemens S7
                              причем большая часть головной боли перекладывается с разработчика на ОС и IDE.
                                0
                                Решение дорогое больно получается. PLC это конечно круто, но дорого.
                                0
                                еще один пунктик

                                Не забывай инициализировать переменные, не доверяй дефолтному состоянию контроллера
                                  0
                                  Вот новую статью о специализированных контроллерах для управления прецизионными электроприводами опубликовал, там все достаточно просто описано, думаю немного обрезать и опубликовать в данном разделе, но интересно, что скажет публика?
                                    0
                                    Что-то не очень хабралюди ПЛК увлекаются, но если кому-то интересно, не дайте утопить топик-ссылку про языки программирования, на мой взгляд, для начинающих электроников это было бы полезно.

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое