[Перевод] Референсный код
Мой активный корреспондент Чарльз Мэннинг отправил мне ссылку на вопрос с сайта Nordic Semiconductor. Вот этот вопрос, дословно: «Какой BLE профиль будет удовлетворять ЭКГ сигналам наилучшим образом и есть ли пример кода для АЦП из этого профиля? Искал какое-то время и не могу найти его ».Чарльз, и я вместе с ним, были ошеломлены. Кто-то создает критическую часть медицинского оборудование с, как нам представляется, ограниченным знанием протокола связи, который он будет использовать Он также планирует построить эту часть на референсном (если кто предложит хороший перевод этого термина буду благодарен — «образцовый и эталонный» не очень подходят — в русском языке эти два термина содержат несколько иной смысл, а «примерный» не звучит -примечание переводчика) коде от поставщика.Это, наверное, несправедливо сделать такие выводы всего лишь из одного вопроса, несмотря на, возможно, леденящие душу последствия для пользователей. И я не собираюсь запретить форумы — они представляют собой отличный способ совместного использования знаний. В до-интернетовскую эпоху мы все в значительной степени должны были выяснить интересующие нас вопросы из собственного опыта, что было ужасно неэффективно. Я помню поездки в объятия вендоров для разговора с разработчиками чипа, чтобы получить внутреннюю информация о какой-то плохо документированной или неработающей функциональности.
И, поверьте мне, я целиком и полностью за повторное использование, и думаю, что это действительно наша единственная надежда на спасение, поскольку системы становятся больше и сложнее.
Но референсный код изобилует ошибками и далеко не полон. Он, как правило, призван показать разработчику, как использовать функции чипа. У большинство опытных разработчиков на теле есть шрамы от эпизодов, когда они выясняли, почему некоторые части этого кода не работают. Некоторые из них просто ужасны (а некоторые еще хуже -пп). Чарльз использует Nordic и утверждает, что их код на голову выше остальных, но это тем не менее референсный код.
Человек, который задал такой вопрос, может быть чрезвычайно компетентным разработчиком, который будет анализировать код, прежде чем его использовать. Но это симптом, указывающий на две проблемы в нашей отрасли сегодня.
Первая из них — часто вшивое неважное качество кода от поставщика. В некоторых случаях все настолько плохо, что полупроводниковая компания должна держать большую команду своих инженеров на объекте заказчика, чтобы помочь вывести продукт на рынок. Конечно, это только происходит для тех, кто покупает огромное число чипов, а небольшие потребители, или даже те, кто покупает сотни тысяч, пролетают мимо.
В некоторых случаях, как мне известно, результаты работы этих инженеров не возвращается назад и не отражается в референсном коде, предоставляемом всем остальным. У них никогда нет времени, чтобы искать ответы на любые вопросы, кроме немедленного кризиса, таким образом обновления остаются вне зоны внимания.
Тем не менее надо проявить снисходительность к поставщикам — ведь их миссия заключается в продаже чипов. Референсный код является свободным и поэтому воспринимается как бесплатный. То есть он должен существовать, чтобы протолкнуть чип в дверь продаж, но никогда не получит требуемого внимания к потребностям пользователя. Современные микроконтроллеры действительно сложны. Даже шина может развалиться, периферия работает в бесчисленных режимах. Сотни или даже тысячи регистров должны быть установлены правильно. Список инициализации сегодня может составлять 500, 1000 или более страниц. Референсный код действительно не может обработать каждый режим и возможную конфигурацию. Стоимость развития такого кода огромна, а цена равна нулю.
Вторая проблема заключается в постоянной нехватке времени на рынке. Клиенты просто не имеют времени, чтобы выяснить нюансы обработки всех этих периферийных устройств настолько хорошо, как требуется для создания надежного кода, если они хотят удержаться на гребне волны. Решением является повторное использование референсного кода. Если бы это было совершенный мир, повторное использование осуществлялось бы на уровне объектного кода, весь повторно используемый код был бы квалифицирован, и все клиенты имели бы полную уверенность в коде.
Восхитительные чудеса будут сопровождать взрыв IoT в ближайшие годы, если ситуация останется столь плохой.
К сожалению, есть тонкое мета-размышление на тему того, что есть хорошо. Предположим, что производитель чипа создаст референсный код, который будет абсолютно совершенным. Нет ошибок, блестящая документация и подтверждение прекрасности этого кода инженерной практикой. Кто поверит ему? Десятилетия проблем создали атмосферу общего недоверия. Как бы продавец убедил скептически настроенных, что вот теперь-то он, конечно, произвел то, что мы действительно хотим (именно поэтому они такой прекрасный код и не делают — ага. конечно -пп)?
Когда дело доходит до повторного использования мы должны думать о пирамидах. Они были построены на невероятно прочном фундаменте. В мире прошивки, слишком часто, эта пирамида перевернута.
Каков ваш опыт работы с референсным кодом?
Дальше от переводчика ответ на вопрос Джека.Недели две назад увидел в блоге вопрос о сбоях серво-машинок под Ардуино. Нашел код используемой библиотеки, посмотрел, ужаснулся — они формируют программный ШИМ, дергая ножки руками в прерывании таймера, поэтому, естественно (или как еще говорят, разумеется) при загрузке процессора другим прерыванием (а в том случае речь шла о стеке поддержки беспроводного протокола, исходников которого я не нашел, но который скорее всего, следуя современной моде, исполняется в режиме прерывания), длительность ШИМ импульсов способна расширяться на неопределенную величину. Решение очевидно — надо использовать в подобных случаях аппаратный ШИМ, но, как вы думаете, где-нибудь в документации об этом было сказано? Причем все скачано с официального сайта Ардуино. Есть альтернативное решение, но там свои тараканы и чуть ли не крупнее. Как говорил товарищ Сталин — «Оба хуже».Ну да фиг то с ними с Ардуино (хотя с какого перепугу, ребята то считают себя вполне взрослыми и спрашивать с них надо соответственно), но вот буквально вчера обнаружена бага в референсной библиотеке (порте lwIP) на STM, которая проявляется в определенных условиях при не-одновременности подачи питания на разные аппаратные части устройства.Где-то с полгода назад у знакомых молодых инженеров на определенных режимах не работала референсная библиотека USB от STM, а через месяц появилась новая версия библиотеки, которая заработала, за что STM искреннее спасибо (что этих инженеров, конечно, не оправдывает в столь некритичном использовании стороннего кода).Как, во многом справедливо, указал мой коллега по поводу все тех же Ардуино библиотек, их использование сильно напоминает карго-культ, то есть делай так и будет тебе счастье. И все замечательно, пока все действительно работает, но ежели нет… вот тут и требуются знания, которых следование наперед заданным правилам дать не может в принципе. Хотелось, что бы меня правильно поняли — я не против Ардуино, более того, это замечательная экосистема, которая потрясающе понизила порог вхождения и привлекла к прошивке колоссальное количество людей, но надо четко понимать что она никак не серебряная пуля и даже при реализации не экстремально сложных функций может создать определенные проблемы, решать которые она не учит. То есть, начинайте с Ардуино, но потом идите дальше — там самое интересное и начинается.PS. Вот не могу понять, почему тот же Джек читает свой курс по прошивке «More Firmware, Faster» каждый год в 5–6 странах, а у нас ничего подобного нет и не предвидится. У нас нет потребности в сильных инженерах? Не верится. Или дело в нежелании учиться? Или в нежелании платить за учебу (за свою или своих сотрудников)? У меня нет ответа на эти вопросы, есть только констатация факта.
