Понимает ли ваш супруг, как вы думаете?

Инженерия — это аналитическая профессия, в которой, если все сделано правильно, все может быть проверено холодным расчетом. Это данность. Не имеет значения, что вы думаете о чем-то, важен только результат.

Недавнее статья Малкольма Гладуэлла в Нью-Йоркер поднимает этот вопрос. В ней обсуждается роль инженеров в автомобильной службе отзыва. Помните катастрофу Пинто? Столкновения сзади может превратить автомобиль в огненный шар. Что не так с этими инженерами?

Оказывается, числа просто не поддерживают страстные крики о переменах. Большое дело, которое было инициировано, когда три девочки-подростка погибли, когда их Пинто сгорел, выиграл Ford.

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

Конечно, иногда наши аналитические стороны не всегда уместны. Когда мы растили детей, моя жена спросила, почему я всегда думал о том, что может пойти с ними не так. Я ответил: «Я тренировался в анализе худшего случая.»

Только дурак учится на своих ошибках, умный предпочитает учиться на чужих

Мой активный корреспондент Чарльз Мэннинг отправил мне ссылку на вопрос с сайта Nordic Semiconductor. Вот этот вопрос, дословно: «Какой BLE профиль будет удовлетворять ЭКГ сигналам наилучшим образом и есть ли пример кода для АЦП из этого профиля? Искал какое-то время и не могу найти его ».

Чарльз, и я вместе с ним, были ошеломлены. Кто-то создает критическую часть медицинского оборудование с, как нам представляется, ограниченным знанием протокола связи, который он будет использовать Он также планирует построить эту часть на референсном (если кто предложит хороший перевод этого термина буду благодарен — «образцовый и эталонный» не очень подходят — в русском языке эти два термина содержат несколько иной смысл, а «примерный» не звучит -примечание переводчика) ( мне подсказали в комментариях демонстрационный код -пп) коде от поставщика.

Не все йогурты одинаково полезны.

Пока беспроводные технологии не победили окончательно, USB (Ю) стал (или вот-вот станет) наиболее часто применяемым интерфейсом в устройствах на микроконтроллерах (МК) и уверено занимает нишу устройства стандартной коммуникации, вытесняя UART. Не забудем и то, что в настоящий момент в наиболее известной и распространенной серии плат на основе МК — Arduino — даже и сам UART реализован через преобразователь из Ю интерфейса, а в некоторых продвинутых вариантах и преобразователь реализован на самом МК. Так что наличие Ю модуля в МК становится одним из критериев выбора конкретного устройства из множества вариантов. К сожалению, невозможно всего лишь посмотреть на таблицу в документации и удостоверится в наличии плюса в соответствующей строке. Рассмотрим некоторые особенности интерфейса с точки зрения функциональных возможностей.

Имея в виду, что Интернет вещей (IOT) привлечет много людей, не являющихся квалифицированными разработчиками, Texas Instruments модифицировала свой TI-RTOS, добавив функции, упрощающие автоматизированное управление питанием и создание конечной точки IoT. TI-RTOS v2.12 (последняя ревизия), поможет разработчикам максимально увеличить срок службы батареи в TI SimpleLink и других беспроводных микроконтроллерах, не будучи специалистами в программировании «железа».

Во многие знания многие печали.

Компания, назовем ее Acme Products, производила очень популярный продукт, который многие из нас используют ежедневно (даже не представляю о чем идет речь, может быть телефоны с АОН, но они были 8битными — Примечание переводчика). Выполнен он на одном 16-битном процессоре, весь код умещался в 256k ПЗУ. Код развивался в течение десятилетий, патч следовал за патчем, создавая беспорядок. Расходы на поддержку увеличивались год от года.

Инженеры убедил руководство, что необходимо полностью переделать систему. Не без оснований они выбрали топовый 32-битный МК с частотой 200Мгц. Возможно, не до конца обоснованно, поддавшись на призывы сирен, инженеры для замены традиционной ОСРВ ОС выбрали Windows CE с обширной графической библиотекой, и многочисленными слоями промежуточных слоев изоляции API от приложения, и получили в свое распоряжение ресурсы, необходимые для того, чтобы сделать все, что только можно представить себе в будущем.

Эксперты отрасли призывают разработчиков встроенных систем (ВР) покинуть зону комфорта и приобретать новые навыки, дабы не потерять актуальность в профессии.

Если мы посмотрим на ситуацию в 1980 году, парень (а в основном контроллерами занимаются все-таки парни), который разрабатывал схему обработки смешанных сигналов, парень, который подключал МК, парень, который писал код на ассемблере и парень, который выносил прототип наружу (наверное, имеется в виду отладка -примечание переводчика), был одним и тем же человеком (я сам из таких, хотя, конечно, это началось в СССР намного позже 1980 года -пп). Все это делал в значительной степени один инженер.

По мере того, как встроенные системы становились больше и сложнее, и миллионы строк кода начали поставляться с устройством (Джек Гансли в своей статье вспоминает время, когда с IBM PC поставлялся полный исходный код BIOS — пп), наступило время деления на разработку железа, разработку прошивки и разработку ПО в рамках одного устройства.

Во многих крупных компаний до сих пор так и остается. Но, похоже, маятник качнулся обратно, так как во все больших компаниях наступает консолидация ролей и снова в моде разработчики, которые в совершенстве владеют как аппаратной частью, так и программным обеспечением, и пытаются сделать большее с меньшими затратами. Соответственно, все больший процентов инженеров говорят, что они работают как на аппаратном, так и на программном уровне, и доля универсалов превосходит долю узких специалистов. (Собственно, универсалы никуда и не пропадали, просто какое то время в индустрии царило мнение, что принцип декомпозиции и специализация является серебряной пулей и позволяет достигнуть хороших результатов командой посредственностей — пп).

Поскольку мы не желаем отстать от прогресса в области ВР, то как определить, какие навыки, которые мы можем приобрести или развить, являются наиболее актуальными сегодня?

Журнал EE Times обратился к 9 профессионалам в ВР (видимо, у них произошел сбой в адресной книге, ничем другим то, что они не обратились ко мне, я объяснить не могу — пп) и рекрутерам и попросил их рассказать, что они думают по поводу наиболее важных вещей, необходимых современному инженеру в области ВР.

«Я знал, что будет плохо, но не знал, что так скоро» (В.Цой)

Не знаю, что послужило причиной написания данного поста, наверное просто наболело, но конкретным побудительным мотивом стало два события — одно ИЗ-ЗА рубежа, а другое отечественного происхождения. Неизвестно, какое хуже, но об этом судить читателю, так что начнем.

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

То есть было высказано предположение, что дело действительно в стандартном модуле от известной фирмы. И действительно, эксперименты показали, что модуль питания при определенных значениях входного напряжения (находящихся внутри области работоспособности) и определенных значениях температуры модуля (тоже внутри допустимых) не может включиться при работе на емкостную нагрузку, превосходящую определенное значение (и при этом почти на порядок не дотягивающую до максимально допустимой).

Rich Nass из embedded-computing.com взял у меня интервью о моих мыслях по инженерному образованию. Для начала, важно отметить, что обучение в университете еще не инженерное образование, а всего лишь начало этого процесса. Слишком многие из нас, практиков, решили, что можно остановить обучение после окончания школы. Есть тревожный факт, что в среднем «человек прошивки» читает только одну техническую книгу в год, и это в области, где постоянные изменения являются основой нашей профессии.

Как из камня сделать пар, знает доктор наш Гаспар

Очень часто при выборе МК приходится обращать внимание на наличие в его составе конкретного набора периферийных устройств под конкретную задачу. Между тем ряд стандартных шин может быть реслизован на основе других интерфейсов, имеющихся в уже используемом МК. В даном посте я покажу, как на МК 1986ВЕ1Т можно реализовать отсутствующий в его составе аппаратный интерфейс 1-Wire на основе имеющегося интерфейса SSP, причем данный опыт может быть перенесен на другие МК других производителей аналогичной архитектуры.

Во многие знания многие печали

Если вы спросите любого разработчика встроенного ПО, хочет ли он иметь доступ к исходному коду операционной системы реального времени, которую он использует, ответ почти наверняка будет — конечно. Точно так же обстоит дело с любым покупным ПО. Является ли такой ответ разумным для всех случаев и почему исходный код иногда необходим, а иногда его наличие менее полезно, чем ожидалось?

«Жуки, жуки, жуки» — всхрапывая, приговаривал во сне Пумба, и они ему снились!

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

Знал бы где упадешь, соломки подстелил бы

О существовании DMA (Direct Memory Access) — русскоязычное ПДП (Прямой Доступ к Памяти) многие разработчики встроенных устройств слышали, но вот применяют его гораздо реже, чем он (ПДП) этого заслуживает. Кстати, я буду упоминать именно эту аббревиатуру, но не потому, что я такой упрямый патриот и противник англоязычных заимствований, а всего лишь от того, что мне лень лишний раз переключать раскладку клавиатуры.

Основных причин недостаточного использования ПДП в программах для МК три: 1) относительная сложность данного устройства, которая вместе с 2) непониманием выгод его применения приводит к нежеланию данное устройство изучать и осваивать (как говорят в таких случаях, старшая сестра не велит — для тех, кто в танке — это про лень, котороая раньше нас родилась), отягощенному 3) отсутствием хороших и понятных примеров применения ПДП в поставляемых с МК руководствами. И если первые две причины носят явно субъективный характер, то третья несомненно объективна и внутри меня просыпается параноик и настойчиво утверждает, что это сделано специально с целью не допустить отечественных разработчиков МК на продвинутые уровни, где-то выше 60 (то, что при этом страдают и остальные разработчики по всему миру, параноиком игнорируется, поскольку либо 1) за пределами России распространяются правильные примеры, либо 2) ради великой цели не допустить вставания, сами понимаете кого, с колен буржуины готовы пойти на любые жертвы).

Тем не менее без шуток, действительно, в примерах в лучшем случае лежит модуль настройки отдельно взятого канала ПДП, а увязанную систему с ПДП драйвером Вы в примерах применений не найдете (даже в CMSIS не найдете, ну тут действительно есть объективная причина — напишу пост про него — упомяну). Почему так на самом деле — я не знаю, но разработчикам кристаллов виднее, единственное разумное обоснование, которое мне приходит в голову — это то, что ПДП довольно таки специфичны, поэтому «нельзя просто так взять и » перенести код из другого источника, а ввиду малой востребованности ПДП в реальных разработках отсутствие таких примеров не считается существенным недостатком. Восполнить указанный мной пробел в знаниях и предназначен настоящий пост (нескромное заявление, но если сам себя не похвалишь, весь день ходишь как оплеванный), поэтому те, кого я заинтриговал, могут нажать на кнопочку.

Нам представилась возможность провести еще одно небольшое, но крайне поучительное тактическое занятие

Тематику этого поста навеяла рассылка от Шерлока Омса — периодически там размещаются истории о нетривиальных инженерных задачах, возникших при диагностировании различных электронных устройств. Вот и подумалось, а почему бы и нет? Хотя прекрасно понимаю, что тематика достаточно специфическая, требует вполне конкретных узкоспециализированных знаний и вряд ли будет интересна широкому кругу читателей, но нескольно приятных минут узкому кругу ценителей аппаратных загадок способна доставить. Итак для тех, кто знает, что такое шина данных и как она устроена — история, в которой будут

Понимаю, что заголовок выглядит как машинный перевод, но лучшего эквивалента " Top 10 Bug-Killing Coding Standard Rules " придумать не смог.

10 главных правил по избеганию багов — подсказали в комментах

Данный пост представляет собой вольный пересказ ключевых понятий книги Michael Barr «Embedded C Coding Standard», изложенных в его выступлении на вебинаре в июне этого года (не знаю как поставить тэг «перевод»).
Часть правил применима только к C++ и расширениям C, а часть и к стандарту языка.

Нам представилась возможность провести небольшое, но крайне поучительное тактическое занятие

На днях, в прцессе портирования FreeRTOS на микроконтроллер с ядром Cortex-M1, о котором я уже писал, возник маленький вопрос, который совершенно неожиденно яростно сопротивлялся всем попыткам найти на него ответ при помощи ГУГЛА всемогущего. Причем в процессе поиска выяснилось, что этот вопрос интересовал не меня одного, а, значит, не может быть следствием врожденной (либо приобретенной) тупости вопрошающего, ну или, в крайнем случае, свидетельствует, что таковая встречается не столь уж редко. Слегка озадаченный невозможностью применить обычный способ поиска ответов, решил прибегнуть к более экзотическому и слегка забытому — подумать и найти ответ самостоятельно. К сожалению, тоже не получилось, равно как не помогла и попытка проконсультироваться с другими неглупыми людьми (сам себя не похвалишь — весь день ходишь как оплеванный). Поскольку на Хабре таковых должно быть в избытке, попробуем экстенсивный путь решения путем вовлечения в этот процесс еще большего количества специалистов. Поэтому вместо победного поста пишу пост жалобный — помогите, люди добрые, кто чем может. Итак, переходим к сути проблемы.

Не все так плохо, как могло бы быть, но не столь хорошо, как хотелось бы.

Прежде, чем приступить к рассмотрению реализации драйверов различных устройств в МК, хотелось бы определиться с объектом, на котором мы вышеупомянутую реализация будем осуществлять. Конечно, можно рассмотреть сферический МК в вакууме, но в этом случае любое неудобство, приводящее к особенностям реализации программы, будет рассматриваться, как нечто искусственно созданное. Если же принять за базовый идеальный МК (если бы я умел их создавать, то наверняка давно бы этим занялся), то для него написание какой-либо программы вообще не представляет никакой трудности и сводится к двум командам: 1) пойми мысли разработчика и 2) сделай это. Поэтому какой-то реальный МК в качестве базового весьма желателен, причем то, насколько он далек от идеала, станет мерилом ценности разработанного ПО (раз оно устойчиво работает на этом МК, перенести его на любой более совершенный нетрудно — сильное утверждение, но примем его без доказательства).

Тема данного поста образовалась почти случайно, в процессе легкой дискуссии по поводу подходов к разработке програмного обеспечения в частности и устройств на МК в общем. Желающие могут ознакомится с самой дискуссией habrahabr.ru/company/coolrf/blog/222801. Хотя обе стороны явно остались при своем мнении, тем не менее определенный вызов был брошен. Я вызовов не боюсь, любой челлендж уже сам по себе хорош, поскольку отвечая на него, ты в чем-то меняешься и, как правило, в лучшую сторону (вариант типа «а слабо выпить 10 литров пива за раз», который очевидно меняет человека НЕ в лучшую сторону, в моем возрасте уже не прокатывает). Итак, мы начинаем.

Все хорошо, что хорошо кончается

Теперь, когда мы рассмотрели, как с помощью средств языка С мы сможем определить фиксированное расположение регистра в адресном пространстве МК (часть 1), как мы сможем определить отдельные битовые группы в регистре (часть 2), самое время рассмотреть как мы можем с этими группами работать. Работа с группой битов, как с целым, не представляет никаких проблем, опирается на их описание в виде битовых полей и уже демонстрировалась, однако нам может потребоваться и работа с отдельными битами поля, причем по соображениям эффективности либо понятности программы разделять группу на отдельные поля нецелесообразно.

Наступила полночь и Шехрезада продолжила позволенные речи

Для начала замечание к предыдущей статье — я там позволили себе неуважительно высказаться по поводу ASSERT — поясню свою позицию. Мне не очень нравится. что проверка в ASSERT проводится только на этапе исполнения, проверка на этапе компиляции эффективнее. Мне в личку сообщили о существовании конструкции, позволяющей сделать необходимые проверки именно на этапе компиляции (я проверил — действительно работает), думаю, что пост на эту тему скоро появится в песочнице.
Итак, мы продолжаем…
Как было сказано выше, регистры внешних устройств характеризуются расположением в адресном пространстве (тут мы уже определились) и составом управляющих элементов. Дело в том что многие управляющие элементы недостаточно велики для того, чтобы занять целое слово конкретного МК и, чтобы сэкономить адресное пространство, несколько управляющих элементов могут быть упакованы в один регистр. Такое решение позволяет также в определенных условиях несколько увеличить скорость работы программ, взаимодействующих с данным внешним устройством, потому и встречается весьма часто. В то же время данное решение вызывает определенные проблемы в отношении языка программирования, о которых мы и поговорим.

Вдохновленный несомненным успехом предыдущего поста (никто не написал, что статья неинтересная и не предназначена для Хабра — это уже успех, а многие люди прочитали, написали комментарии и дали советы по оформлению — еще больший успех, кстати, всем спасибо), решил продолжить делиться своими мыслями по поводу программирования МК. Сегодняшние заметки посвящены общим вопросам программирования в языке C, а именно работе с битовыми полями безотносительно к конкретным МК и средам программирования (хотя примеры и будут приводиться для конкретного CORTEX-M1 и IAR). Вроде бы тема не новая, но хотелось бы показать недостатки и достоинства разных методов. Итак, мы начинаем…