В фокусе
Читать
ГлавнаяРубрикиПрограммное обеспечениеВстраиваемое ПО: Как не наступить на грабли?
22.05.2019

Встраиваемое ПО: Как не наступить на грабли?

Современные устройства – давно уже не шесть реле в два ряда с тремя кнопками и парой светодиодов. Сегодня пользователи ждут захватывающего опыта взаимодействия с девайсами. Даже рабочему у станка хочется иметь надежное, совместимое, безопасное и удобное в использовании оборудование, не говоря уже об автомобилистах, пилотах и медиках с пациентами, которым «умные» устройства не только значительно облегчают работу, но зачастую буквально спасают жизнь.

Сердце любого «умного» устройства – встраиваемое программное обеспечение (ПО). Будучи неотъемлемой частью медицинского и промышленного оборудования, автомобилей и систем безопасности, именно встраиваемое ПО обеспечивает их бесперебойную и безотказную работу. Аурига знает об этом не понаслышке: по изначальной натуре своей и внутреннему укладу наша компания сильно отличается от других. Мы не такие как все – у нас «вьют гнезда» олдскульные программисты встраиваемого ПО.

Погружение в таинства

С 1990 года разработка встраиваемых решений является одним из основных направлений деятельности Ауриги. Мы разрабатывали ПО для многих международных компаний, включая IBM, Dräger Medical и др. Причем не только то, которое выдает пользователю информацию о температуре и давлении пара на ЖК дисплее котла (подобного рода ПО даже не является встраиваемым в классическом смысле), а то, которое управляет компрессором, стравливает давление клапаном и измеряет параметры с помощью сенсоров.

Впрочем, и графические интерфейсы Аурига тоже пишет – современным устройствам без них никуда. Однако мы понимаем, что инженеры, разрабатывающие GUI, могут не знать многих ограничений и зависимостей в нашей работе, к примеру:

  • в условиях ограниченной памяти (и часто даже физической, а не какой-то там виртуальной);
  • в отсутствие операционной системы (если она и имеется, то даже не Linux, а что-то типа QNX или ThreadX, в некоторых случаях аж OS-9);
  • без отладчика, когда ходить по шагам считается за большое счастье (страшные слова Flash aka EEPROM или просто PROM, а где-то еще ультрафиолетовой лампой светят перед тем, как начать ритуал запуска);
  • и вообще вдруг процессорное ядро на х86 не похоже, а посвященные вокруг что-то про powerpc, arm, mips и RISC V шепчут;
  • почему-то приходится интегрироваться с какими-то кусками кода даже не на С, а на каком-то DSP ассемблере;
  • да и процессов с потоками нет – не просто POSIX-подобных, а вообще никаких;
  • а еще процессор дохлый, поэтому не выносит гениальной задумки по отрисовке QWidget в правом верхнем углу;
  • какие-то другие программисты всю память из кучи (HEAP) «съели», и сошлась она в бою со стеком (STACK), и погиб стек бесславно, и повисла очередная программа управления ускорителем, и взорвался он оттого;
  • и, наконец, после выявления ошибки входных данных нельзя делать throw exception, ибо некому это исключение обрабатывать, и на реальном оборудовании оно может привести к опасным и даже фатальным последствиям.

Именно поэтому и есть в Ауриге группа «посвященных», которая терпеливо обучает неофитов мудреной науке. Это не библиотека кривая, а нужно открыть исходники и смотреть, почему «падает». Если исходников нет, то есть дизассемблер – ибо ты программист или кто? Это не железо слабое, а необходимо оптимизировать алгоритм. Не надо использовать оголтело объектно-ориентированный подход, да и функциями увлекаться не стоит. И оператор goto – вполне себе хороший оператор, в условиях недостатка памяти – просто палочка-выручалочка.

Грабли встраиваемого ПО

Все это даже не цветочки – так, посев. «Цветочки» — это когда клиенту приходится объяснять на живых примерах и аргументированно доказывать, почему профессионал с опытом работы в нестандартных условиях стоит дороже обычного программиста. Существенная разница заключается в том, что у первых все отлично работает всегда и везде, тогда как у вторых все работает в течение 15 минут, а затем, наверное, железо перегревается.

За годы работы в отрасли мы сталкивались с самыми разными случаями. Простой для Ауриги случай – когда заказчик сам ошибся в выборе специалистов, сам зашел в центр лабиринта и молит нас о спасении. Что ж, приходим и спасаем. Однако нередко бывает и тяжелый случай: «Мы тут взяли новый pin-to-pin совместимый микроконтроллер, немножко изменили программу, собрали, а она не работает. Старые бинарники на новом микроконтроллере работают, но не так хорошо, как на старой версии. Вы сможете за пару деньков все поправить? А еще мы хотим, чтобы код под разные аппаратные платформы собирался, и очень желательно, чтобы работал».

В этом случае я, как Генеральный директор, вызываю пару инквизиторов и одного евангелиста, чтобы первые двое изгнали из программистов заказчика user-mode, а третий приобщил их к исконным знаниям и придал твердости духа. Не вдаваясь пока в такие термины, как ядро ОС, драйвер, BIOS, микрокод, мы «открываем букварь» и начинаем рассказывать:

  • про Little-Endian и Big-Endian;
  • про то, что некоторые типы переменных иногда занимают не 4 байта, а вполне себе 6;
  • про то, что бывают «плотноупакованные структуры», которые почему-то популярны в сетевых протоколах (все знают, что поля в структурах нужно выравнивать на разрядность шины данных для скорости, только еще есть такая штука как совместимость);
  • про необходимость пользоваться симулятором для быстроты разработки и поиска функциональных ошибок;
  • про параллельный выход на натурные испытания на реальном железе, ибо только война план покажет и поможет выявить «узкие места».

Вместе с заказчиком мы начинаем изучать регистровую модель микроконтроллера и ассемблер, а также считать память и использовать макросы вместо функций для экономии оной и ускорения процессора. Мы упираемся от перехода на новый компилятор или библиотеку, ибо знаем, что все рухнет, а когда рухнет, открываем исходники (и, если надо, бинарники) и начинаем править там. Мы объясняем, почему тестировать надо в основном автоматически, и почему тесты должны быть только системные. Мы знаем по опыту, что тестировать нужно несколько миллионов раз, чтобы поймать эту одну сотую микросекунды race-conditions, и что ручное тестирование во встраиваемом ПО практически ничего, кроме функциональных багов, не выявляет – там хороши симуляторы.

Осилив «букварь», многие заказчики «прозревают» и говорят: «Эх, если бы мы знали!..» Надеюсь, теперь вы знаете и понимаете, как важно иметь дело с опытными программистами. Возникла проблема со встраиваемым ПО – обращайтесь к профильным специалистам, профессионалам своего дела. Да, это будет дороже, но зато это будет работать, а не висеть!

— Вячеслав Ванюлин, Генеральный директор, Аурига

Источник.

Версия для печати128 просмотров.
Оцените статью по: