Я уже подробно рассказывал на Хабре, как мы делали камеру для определения усталости водителя. Сегодня хочется сосредоточиться на том, что мы узнали при создании прототипа этого устройства, как при помощи прототипов быстро проверять гипотезы и какие платформы и компоненты лучше для этого использовать.
— Когда мы шли к разработке этого продукта, нам пришлось сделать много прототипов. Я бы хотел частично поделиться нашим опытом, рассказать, что и как мы делали. Возможно, кому-то многое из рассказа покажется банальным. Многие из вас, скорее всего, проходили эти этапы и тоже имеют свои наработки. Я не претендую на последнюю инстанцию истины, но это будет интересно.
Давайте посмотрим, как же делаются устройства, прежде чем дойти до прототипов, потому что это многое определяет. Это абстрактный проект, он не привязан к каким-то конкретным обстоятельствам, я привожу его просто для примера.
Сначала вы подготавливаете вводные данные и подходите к R&D. Обычно это для вас делает сторонняя компания, а может быть, вы сами. Но в любом случае, это достаточно длительный процесс, минимальный срок — три-восемь недель. На данном этапе делают плату, подбирают электронные компоненты, и устройство обретает материальное воплощение.
Далее производится EVT-образец, тестовое устройство, которое уже расположено на нужной вам плате примерно таких габаритов, примерно из таких комплектующих. Его цель — дать вам понять, похоже это на то, что вы хотите получить, или нет, нужно ли что-то менять. У вас появляется возможность это протестировать.
Затем производятся DVT-образцы. Это design verification test, когда все найденные в EVT недостатки или большинство из них устраняются. После этого устройство помещается в финальный корпус, в финальный дизайн, чтобы вы понимали, как оно ощущается в руках, как вы его будете дальше использовать.
Следующий этап — вы выпускаете пробную партию PVT. Это может быть сто или тысяча штук, в зависимости от того, как у вас все идет. И потом начинается mass production.
Главный вывод из всей этой истории в том, что пока вы получите первый прототип, я имею в виду EVT, пройдет минимум два-три месяца. Это довольно долго, и всегда возникают риски. Может быть, не все функции будут реализованы. Может быть, вы неудачно подберете компоненты, и вам придется возвращаться в изначальную стадию R&D. Может быть, вы не учли какие-то условия работы этого устройства. Может быть, вокруг жарко, холодно, вибрация, грязь, пыль, вода. Все что угодно.
Еще вы могли переоценить свои возможности. Вы хотели сделать устройство, которое помещается в некий ценовой диапазон, но не вышло, оно оказалось дороже. А еще может случиться банальное — пока вы полгода разрабатывали устройство, требования поменялись, и вам нужно идти и делать заново. Так бывает.
С учетом предыдущей схемы это приводит нас к тому, что сейчас в разработке софта люди обычно используют какой-нибудь agile-подход. Все идет по кругу, короткими итерациями. На каждом этапе есть работающий прототип, и все нормально, итеративно. В hardware-разработке это не подходит. Если вы меняете требования, то возвращаетесь не первый этап, у вас опять семь-восемь недель, и вы производите новый EVT. Именно поэтому вы не можете сделать какой-то minimum available-продукт, а когда-нибудь потом его доработать. Нельзя сделать плохо. Вы, может быть, сможете что-то улучшить программно, но если вы сделали плохо, значит, ваш продукт получится плохим.
Каждая такая ситуация — потеря времени, потому что на заказанные вами новые исследования, доработки и производство нового EVT-образца тратится время. Вы просто сидите и ждете результата.
Поэтому давайте к этой схеме, где я рассказал о производстве устройства, добавим то, как это мэпится к разработке софта.
Как обычно происходит эта разработка? Есть development-версия. В рамках R&D вы выпускаете альфа-версию, к первому EVT-образцу у вас должна быть готова бета, затем появляется вторая бета и вы итеративно готовитесь к релизу. В идеальном мире все происходит, как на этой схеме.
На самом деле реальность такова, что альфа-версию вам не на чем тестировать, поэтому вы сильно рискуете. А бета-первая может вообще не запуститься на том, что вам произвели. В этот момент вы потеряли время. Сроки и планы срываются, и ничего хорошего не получится.
Однако есть маленький чит, вы все о нем знаете. Можно на ранних этапах сделать прототип. Он не обязан быть полностью соответствующим финальному устройству, не обязан обладать его габаритами. Он вообще может быть другим, сделанным из чего-то другого. Но он поможет вам понять, что именно вы делаете, как вы это делаете и с чем вы столкнетесь.
Вы сможете быстрее определиться с тем, какое железо вам нужно. Сможете проверить свою идею в реальных условиях, потому что пока она у вас в голове, вам кажется, что она работает. В реальном мире другие потребности.
То же самое касается дизайна. Устройство может казаться вам хорошим, но когда вы его поместите в реальные условия — на стекло автомобиля или на руль велосипеда — оно не будет работать так, как вам надо. Так что проверка дизайна — тоже очень важный аспект.
Еще вы можете быстро писать ПО, потому что каждое ваше действие вы проверяете на живом образце или на серии образцов. Хорошо, если они еще где-то в это время эксплуатируются.
Кроме того, мы все знаем, что миром рулят маркетологи и продуктологи. Они прибегают и говорят вам: «А мы еще вот так хотим и вот так». Эти требования сложно уточнить, когда у вас ничего нет в руках. Когда у вас что-то есть, вы можете их применить, можете попробовать и рассказать им: вот эти ваши сценарии будут работать, а эти — нет.
Когда вы делаете устройство, чаще всего вы делаете его для каких-то бизнес-задач. Если вам нужно привлекать инвестора, то приходить к нему с бумажками, проектами, чертежами и рассказами — классно и нужно. Но когда вы приходите и говорите: «Смотрите, мы придумали вот это, а вот это — работающий прототип», то инвестор сразу больше заинтересован.
У вас есть множество рисков, о которых вы можете не подумать. Если вы, как и мы, делаете устройство с камерой, вам может не прийти в голову, что питание в машине не такое хорошее, как, например, у вас в домашней розетке. Таких рисков может быть миллион, и они всплывут только тогда, когда вы возьмете устройство и поместите его в реальную среду.
Также это вам позволит собрать реальные данные. Одно дело, когда вы ставите камеру перед собой и записываете себя. Другое — когда камера стоит перед мотоциклистом, водителем автомобиля, механиком. Все это нам позволяет предъявить новые технические требования и ограничения к hardware, минимизирует риски.
Теперь давайте посмотрим, какие могут быть случаи с рисками. Я их хотел бы сгруппировать в три части. Либо вы не уверены вообще ни в чем. У вас нет понимания, какое нужно железо, у вас нет понимания, как писать софт. В этом случае все грустно, и, на мой взгляд, лучше всего сделать какой-то proof of concept, а потом скатиться к одной из методик слева. Либо вы уверены в железе и не уверены в ПО, тогда все силы тратятся на ПО, а железо вы отдаете стороннему подрядчику, пусть он его делает в штатном режиме. Либо вы полностью уверены в программном обеспечении, но в железе не уверены, тогда вам срочно нужен прототип. Вы на этом прототипе будете примерять ваше ПО. Возможно, его придется адаптировать, но у вас тоже все получится.
И тут мы приходим к тому, из чего прототипы делать. Здесь мое мнение, может быть, оно не совпадет с вашим мнением, — всегда надо выбирать платформу, которая может больше, чем вы хотите. Если вам нужно малое расширение, берите про запас больше. Если вам нужна ограниченная производительность, — берите что-то, что дает большую. Если вам нужно чуть-чуть памяти, — берите в два раза больше. Если вам нужно что-нибудь, работающее исключительно в вашем скопе задач, возьмите что-нибудь еще более расширенное, с каким-то максимальным инструментарием, это вам всегда поможет. Почему? Потому что, когда вы будете делать это прототипирование, придут те же самые продуктологи, маркетологи, и скажут: «А вот, смотрите, здесь бы еще вот так сделать, и вот это подключить». И что получится?
Давайте чуть-чуть ближе к реальности. Из чего можно это делать? Напрашивается очевидная платформа — Arduino. Давайте делать на Arduino, все любят Arduino. На самом деле да и нет. На Arduino можно делать, на мой взгляд, очень простые штуки. То есть Arduino скорее подходит для каких-то узлов. Вам нужно сделать манипулятор? Отлично, берите Arduino и делайте. Вам нужно сделать термометр? Отлично, их миллион. Другое дело, если вам нужно сделать что-то сложное, требующее вычислительной мощности, computer vision, machine learning.
Arduino — это узел. Вы можете сделать колесо, радиоуправляемую машинку, и Arduino для этого подойдет. Но если в эту вашу машинку понадобится установить камеру — уже как-то не очень.
Тут напрашивается другой вариант — Raspberry PI. Все его любят. Маленький, хороший, популярный, продается сотнями миллионов штук в мире. И, на самом деле, может быть и да, может быть и нет. С одной стороны, он недорого стоит, он производительный, у него много модулей, которые на него можно прицепить. У него довольно стандартный уже сорокапиновый разъем. Но есть проблемы.
Во-первых, он греется, особенно последняя модель, четвертая. И если вы посмотрите на картинку, процессор окружен кучей периферии, и очень сложно придумать к нему такой радиатор, который крутил бы его нормально, потому что вы будете упираться в HDMI порт, USB, в сорокапиновое расширение, и у вас площадь радиатора будет, может быть, четыре на четыре сантиметра максимум.
А еще там нет Android, там только Linux. Есть какие-то вариации на тему, но некоторые проекты, они нуждаются в Android. Например, вы делаете какое-то устройство, которое вы изначально нацелили на платформу Android. И здесь как-то Raspberry PI вам не очень помощник.
И следующая проблема, на мой взгляд, это операционные системы на сменном носителе. Вы используете SD-карту, соответственно, минус, все автомобильные и прочие варианты использования. У вас машина трясется, SD-карта ненадежна, она может вывалиться, она будет вибрировать. Если у вас мороз, еще что-то, будет конденсат, в общем, будут проблемы.
На самом деле, есть очень много всяких штук, я их вам могу показать, мы их разные перепробовали. Есть бананопай. Он примерно то же самое, что Raspberry Pi. Он нормальный, он работает, он совместим с ним по разъемам. Не самая плохая платформа Allwinner. Есть решение чуть-чуть получше, например, Khadas Vim на процессоре Amlogic. Можно будет после моего рассказа подойти ко мне потом в перерыве, я это все буду готов рассказать, показать.
У всех этих штук есть свои недостатки. Я, на самом деле, сюда не железяки рекламировать пришел, но, тем не менее, остановлюсь. Есть устройство, которое нам подошло в наших целях намного лучше.
Это NanoPi, китайский производитель, называется FriendlyElec, FriendlyARM. У них несколько названий. И так случилось, что он лишен недостатков Raspberry Pi, при этом у него множество преимуществ.
Там есть и Linux, и Android, все это с исходниками, все это можно собирать на ходу. Есть eMMC-модуль, то есть вы отделяете операционную систему от внешнего носителя, и он работает в хорошем температурном режиме. Мы пробовали морозить Raspberry Pi и получилось не очень хорошо, при запуске третья модель у нас просто лопнула, процессор развалился. Больше экспериментов проводить мы не стали. А вот эту штуку мы пробовали и замораживать, и в духовке разогревать. Никаких проблем не было.
При этом тут есть полноценный еще PCI Express шина, причем 2x, и в целом все нормально. Его можно и охладить, у него процессор расположен с обратной стороны, я вам сейчас покажу, у меня тоже есть. Вот так он выглядит, все то же самое, что у вас. Процессор снизу. На него надевается жирный радиатор, и этот радиатор прекрасно рассеивает все это тепло.
Чуть-чуть подробнее. Что там есть? На самом деле, мне эта платформа очень понравилась. Я с ней последние полгода прототипирую все, что есть, поэтому и делюсь с вами. Там шестиядерный процессор. Он очень мощный, он греется. Он в пике может потреблять 15 ватт, иногда даже больше. Но там нормальная видеокарта, аппаратное сжатие видео, и, самое главное, все это хорошо расширяется и стоит примерно как Raspberry Pi. Это 50 долларов, плюс чуть-чуть за eMMC и радиатор.
У него есть младший брат. Точно такого же размера, малюсенький. Хорошая новость: если вы этот eMMC-модуль возьмете отсюда и воткнете вот в этот, то вам не нужно пересобирать прошивку, менять софт. Они полностью hardware-совместимы. Даже вот этот маленький сорокапиновый разъем сверху — он по пинам полностью совместим с большим устройством. То есть если вы делаете устройство и вам внезапно понадобилось переехать на маленький форм-фактор, то электрически оно у вас будет примерно совместимо. Да, чуть меньше памяти. Да, меньше USB, их не четыре, а два, но зато все хорошо.
Что еще вам понадобится? На мой взгляд, прототипировать лучше всего на большом толстом дистрибутиве Linux. Понятно, что в финальном устройстве у вас, скорее всего, будет либо проприетарная операционная система, либо очень маленький Embedded Linux, какой-нибудь Linaro или еще что-нибудь меньше. И да, там это будет работать хорошо.
Но пока вы пишете прототип, вам нужен гибкий инструментарий, поэтому большой Linux — это ваш выбор. Что-нибудь на Debian, или еще что-то, с пакетами, куда вы можете в две команды поставить все, что вам нужно и запускать большие-большие штуки.
На стадии прототипирования размер дистрибутива на самом деле не имеет значения. Да, он у вас будет четыре гигабайта. Ну и хорошо. Вот здесь eMMC-модуль на 16 гигабайт. Я залил сюда этот Linux, все у меня прекрасно. Еще вам нужен хороший блок питания, и, самое главное, хороший кабель.
Мы сейчас говорим про устройство типа такого, или типа Raspberry Pi, которое питается от Type-C. Так случилось, что хороших Type-C-кабелей довольно мало, а хороших блоков питания еще меньше. И если вы возьмете даже не серийный блок питания, а что-нибудь, например, для светодиодных лент и запитаете этим напрямую устройство, вам будет намного лучше. Кабель подобрать будет тоже сложно, не игнорируйте это.
У нас в начале экспериментов что плохое питание и плохой кабель приводили к тому, что устройство внезапно зависало. Мы искали проблемы в софте и в периферии, а она состояла в том, что питание внезапно проседало.
Очевидно, что если у вас будут сенсоры, то вы будете использовать плату вроде такой, с кучей маленьких проводочков, потому что паять на коленке целую кучу всего и подключать в такую мешанину из проводов — не очень удобно. Когда вы придете к более-менее серийному прототипу, вы всегда сможете заказать PCB, и на нее уже напаять ваши компоненты. Но пока вы экспериментируете, так удобнее.
Следующая вещь, которая вам нужна, — USB-UART. Скорее всего, в плате, на которой вы прототипируете, и так будет выход для монитора. Но если по-взрослому, лучше сразу переходить к решению, в котором вы работаете с этим в консоли, потому что когда вы будете собирать EVT-образцы, никто вам никаких видеовыходов, HDMI и прочего напаивать не будет. Надо сразу учиться жить нормально.
Есть еще одна полезная штука, я вам ее покажу. Это LCD-экран, как ни странно, с USB-интерфейсом. Я, на самом деле, считаю, что USB в industrial — это не очень хорошо, даже плохо. Но в прототипировании и разработке — отлично. На USB есть тонны периферии, этот экран — частный случай. Это обычный стандартный привычный всем двухстрочный экран с конвертором в USB и еще с двумя кнопочками. Его можно подключить к любому устройству, выводить на него отладочную информацию. Этого достаточно. В большинстве случаев вам больше ничего и не нужно.
Вам понадобится еще одна вещь — 3D-принтер. Можно, конечно, вырезать ножом из пенопласта, лепить из глины, из пластилина, еще из чего-то. Но в конечном итоге вы всегда придете к ситуации, когда вот моя электроника, вот я понял, чего я от нее хочу. Но невозможно представить себе, как это будет работать в реальных условиях. Поэтому в какой-то момент мы закупили несколько принтеров, и все идеи, которые у нас появлялись, мы печатали.
Придумали новый держатель — печатаем. Придумали новый корпус — печатаем. У нас целая галерея из двух-трех десятков разных держателей, кнопочек, подставок. Так проще понимать реальность.
Сейчас будет немножко холивара, на чем разрабатывать. Я не сторонник чего-либо, я считаю, что все это отличные языки программирования. Но так случилось, что все железо, как правило, лучше всего пишется на C. Потому что ядро Linux, потому что все модули, потому что там все просто, понятно и сложнее себе выстрелить в ногу. На C++ выстрелить себе в ногу чуть-чуть проще, на Python вообще не надо заморачиваться ни с памятью, ни с чем.
Поэтому, на мой взгляд, здесь правило такое: если вы сразу нацелены на финальное mass production-решение, пишите на C. Оно легко переносится, куда вам понадобится, и все будет работать. Если вам все нужно здесь и сейчас, если вам нужен computer vision, работа с изображениями, нейронные сети и вот эта вся история, то проще начать с Python. Это быстро, легкий порог вхождения, вы подключили всю периферию, написали, скопипастили даже откуда-то набор скриптов, у вас все заработало. Вы можете с этим жить. Это всегда можно параллельно переписать на C, можно сделать как-то еще. Но вот мое субъективное мнение: C хорош для production, а Python хорош для прототипирования.
Теперь следующий момент. Я считаю, что прототипы не надо аутсорсить. Есть один случай, когда надо их аутсорсить, — это когда вы полностью уверены в железе. Вот у вас есть железка, и вы точно хотите с этой железкой реализовать определенные функции. Тогда все просто: нашли аутсорсера, они написали вам код, вы применили его на железку, у вас все заработало.
На самом деле, во время работы с аутсорсом вам сложнее менять требования на ходу. Вы уже договорились, у вас уже есть договор, скоуп работ, и аутсорсер уже придерживается этого скоупа. Он получит деньги по факту договора, а не по факту ваших желаний.
Пока вам делают ваши прототипы, вы просто ждете. Вы находитесь в стадии, когда же нам покажут что-нибудь следующее. И самое главное, за ваши деньги аутсорсер учится. Они испытывают весь этот фан, они играют с железом, они играют с софтом, и учатся, и получают удовольствие. А вы получаете примерно ничего, то есть ваша экспертиза в этом месте не растет.
И когда вы приходите к производству финального устройства или к какому-то массовому заказу, вы общаетесь с фабрикой, исполнителем, с design-house и так далее, и вы им рассказываете какие-то свои требования. Они вам задают вопросы, а вы не знаете, что отвечать, потому что за вас все эти этапы проходил аутсорсер. Они за вас думали. Они за вас думали про инженерную часть, про электрическую, еще про что-нибудь. И, на мой взгляд, это очень нехорошо. Хорошо, когда экспертиза копится у себя.
А еще, когда вы разделяете экспертизу hardware и экспертизу software в разных компаниях, в разных географических местах, это сложно, потому что здесь нужна плотная коммуникация, и обязательно что-то может получиться не так.
А еще у аутсорсеров есть свои планы, свои ресурсы. Вы с ними договорились, они сделали. Вам надо доработать, они могут сказать: «Ну, вставайте в очередь, у нас тут новый заказчик, простите». А вся экспертиза у них. Они уже все знают, как делать, а вы не знаете ничего.
Дальше, у вас есть hard и soft. Вам надо где-то что-то оптимизировать, потому что это деньги, процесс. Если вам нужно сделать просто proof of concept, то на самом деле железо вообще не очень имеет значение. Вы можете взять ноутбук, приклеить к нему изолентой камеру, GPS, обмотать это все в пенопласт и пустить в тестовую эксплуатацию. Это proof of concept, не имеет значения, из чего он сделан.
Если речь идет об оптимизации BOM, того, из чего вы будете собирать устройство, мой совет: лучше сначала оптимизировать программное обеспечение, потому что это позволит вам сильно ужаться по деньгам и по устройствам.
В то же время, если у вас цель прямо деньги-деньги-деньги, это, извините, китайский подход. Давайте делайте из самого дешевого железа. Тут сильно альтернативы нет. Если речь идет про сбор данных, например, когда мы делали наши камеры, нам нужно было собрать как можно видео и фотографий уставших водителей, водителей, которые провели весь день за рулем, и для этого нам было нужно что-то собрать. В этом месте сложно вообще что-то оптимизировать. У вас другая задача. У вас цель — собрать данные, поэтому делайте из того, что есть и собирайте.
Например, вот эта камера юисбишная, напечатанная на принтере, соединенная вот с таким нашим NanoPi. Она ездит в машинах и собирает данные. Работает? Работает. По деньгам это выгодно? Не очень. Но это работает, все хорошо.
Если вам нужно проверить механику, проверить дизайн, то оптимизируйте железо, потому что когда вы финализируете дизайн, финализируете механику, покажете вашему заказчику, руководству, инвестору, а потом придете к выбору железа, и вам скажут: «Извините, в это не помещается», то вы окажетесь в глупой ситуации. Поэтому, прежде чем играться с дизайном, зафиксируйте железо.
Во всех остальных случаях пишите программное обеспечение, делайте, чтобы оно работало быстро и стабильно. После этого подбирайте под него компоненты.
Пример — наше устройство Signal Q1, которое отслеживает поведение водителя. Вот оно, нормальное, красивое, закрыто снаружи специальным инфракрасным стеклом-фильтром. Внутри модем, GPS — оно достаточно неплохо нафаршировано электронной начинкой. А начиналось все вот с такого:
Присоска, камера, крепеж, кабель, NanoPi. Прототип, который мы делали, дал нам осознать очень много важных моментов.
В первую очередь, мы поняли, какая нам нужна камера, какой нужен сенсор, какая нужна оптика. Какое физическое расстояние от водителя до стекла. Вот кто может навскидку сказать, сколько расстояние между стеклом лобовым и лицом водителя, если в параллель? Семьдесят сантиметров. Это такой обман, легкая ловушка. Вы в нее попадаете. Это 70 сантиметров, 45 — это до зеркала заднего вида.
Кроме того, что камера и оптика, мы подобрали платформу, на которой может исполняться наш код. Мы оптимизировали этот код, чтобы все работало еще лучше. Мы собрали бесценные данные для machine learning, потому что, не собирая эти данные, сидя в офисе, невозможно ничего сделать. Когда человек сидит, просто в обычном режиме работает с ноутбуком, эти данные не релевантны. Он смотрит вверх, вниз, вбок. Это не поведение шофера. А нам нужно было поведение шофера. Поэтому без устройства деваться было совершенно некуда.
Опять же, я показывал присоску. Присоски — плохая идея. Они отваливаются на морозе и на жаре. Мы даже их мазали сахарным сиропом, чтобы они держались лучше. Все это нужно было пройти. Это смешно, забавно, но пока вы не прошли перечисленный этапы, вы ничего не будете знать наверняка. Вам кажется — это же присоска, все держатели для телефона на них делают. Но если вы собираете устройство, которое будет ездить в сотнях, в тысячах, в сотнях тысяч автомобилей, у вас нет права на такую ошибку. Вы не сможете поехать и в ста тысячах машин заменить одни присоски на другие.
Еще мы подобрали место установки, где я и рассказал, — 70 сантиметров на уровне глаз. Нельзя было узнать это, пока мы не попробовали поставить наш реальный прототип в реальные машины. Дальше мы научились подключаться к самой машине. Там много всяких чудес с питанием, не тривиально протаскивать эти кабели. Нужно было найти место, куда это все монтировать, куда подключать, куда вешать устройство.
И еще мы научились обновлять программное обеспечение. Казалось бы, чего там обновлять? Пошел на сервер, чего-то забрал. Но нет. Это тоже длинная история, и только сделав какое-то количество прототипов и запустив их в реальное плавание, вы получаете возможность потренироваться. Это нам дало понимание того, с чем мы столкнемся в будущем, а также фидбек с обратной стороны — о том, как наши устройства воспринимаются в машине.
Несколько советов. Как я уже сказал, бояться USB-интерфейса надо в production, в индустриальных вещах. Когда вы прототипируете, USB — это классно и хорошо. У вас есть возможность подключить кучу модемов, камер, GPS, Wi-Fi.
Вот например, камера. Сколько вариантов камер можно найти для того же Raspberry? Две, три, четыре. А когда мы подбирали камеру для нашего устройства, мы просто пошли на AliExpress, простите, и купили там 50 разных камер на разных сенсорах, с разными линзами, на разных PCV. Все они были USB, и мы их все попробовали. Это нам не стоило примерно ничего, я имею в виду — в масштабах проекта. Мы быстро убедились, что если бы мы сейчас пошли на несколько заводов и заказали разместить вот такие сенсоры Sony, OmniVision, с такими-то линзами, то мы потратили бы месяцев пять-шесть только на это производство и к нынешней точке пришли бы только спустя полгода. Поэтому USB — хорошее решение, в том числе на примере этого отладочного экрана.
Когда вы делаете что-то, прототипируете — сразу думайте, как это будет производиться на заводе. Например, когда вы думаете про корпус, возьмите и сами соберите его отверткой. Если на сборку ваших плат отверткой и закрытие корпуса у вас уйдет полчаса — это не вариант. Вв не сможете научить такой длинной процедуре людей, которые находятся на заводе и могут быть без специального образования. Значит, вам надо что-то упрощать. Это одна из причин, почему вам нужен прототип.
Еще, как я уже говорил, 3D-принтер — наше все. Все, что вам пришло в голову, вы нарисовали, начертили, напечатали, подержали в руках. Если получилось хорошо — прекрасно. Если плохо — исправьте.
Следующий пункт очень важен. Делайте все руками. Даже если этого вы не любите, даже если это не ваш профиль. Это помогает накопить ценные знания, позволяет вам попробовать много всего разного. А еще это весело, потому что вы погружаетесь в какой-то новый параллельный мир.
Предположим, вы делали такую-то разновидность hardware, а теперь перешли на что-то другое. Вы работаете на стыке между computer vision и железом. Или вы усиливаете свои навыки в разработке ПО какими-то хардварными навыками. Это всегда полезно, и команда чувствует подъем, когда все происходит внутри, когда это бурлит, когда есть много устройств, много прототипов. Самое главное — это копит у вас внутри опыт.
Когда вы переходите к следующему этапу, к mass production, этот опыт оказывается бесценным. Вы ни за какие деньги не сможете найти себе консультанта, который все знает и умеет. На мой взгляд, это правильно. Поэтому прототипируйте, делайте, и все получится. Спасибо.
Комментарии (135)
MinimumLaw
23.10.2019 12:53Хорошо написано. Не поспоришь.
Но не кажется Вам, что процесс разработки крайне сложно поддается алгоритмизации? Не все можно отмакетировать на коммерческих платах. Не всегда стоит думать о массовом производстве (уже не говоря о том, что массовое производство у каждой компании разное). Более того, в подавляющем большинстве случаев, если это можно отмакетировать на RaspberryPI или ее аналогах, то это можно и на обычном ПК. При этом на ПК удобнее и пользы будет сильно больше.
И, раз уж у Вас есть время писать статьи — можно просьбу. Доведите до широкой публики подводные камни разных накопителецй информации. Serial/Parallel Flash (NOR/NAND), QSPI Flash, (e)MMC/SecureDigital, (m)SATA. А то надоело каждый раз рассказывать одно и тоже. А сам не напишу.
Это все Вам не в упрек, а просто мысли от человека который всю жизнь занимался разработкой в разных компаниях. И, безусловно, основные мысли абсолютно правильны и справедливы.
olartamonov
23.10.2019 14:49+1Прототипировать надо на железе, по возможностям близком к финальному варианту, а не на том, где ядер больше и eMMC быстрее.
Даже если брать только линукс-совместимые микрокомпьютеры — разработчики, писавшие прототип на «четыре гига, четыре ядра», могут быть немного удивлены, в реальной железке встретив какую-нибудь Ситару на одном Cortex-A8 с 256М ОЗУ и 32M NAND-флэш.MinimumLaw
23.10.2019 15:43Крайне дискуссионный момент.
С одной стороны — безусловно. Если конечное изделие будет крайне ограничено в ресурсах, то чем быстрее эти ограничения станут очевидными тем лучше.
С другой стороны есть вопрос удобства отладки как ПО, так и взаимодействия с окружающим миром. Все же внутрисхемная отладка — это скорее прерогатива системщиков. А подавляющее большинство кода так или иначе пишется прикладниками. Особенно это касается сложных решений. Там системная составляющая сильно меньше прикладной. Опять же — нельзя впадать в крайности. А то прецеденты запуска PostgreSQL сервера c NAND & UBIFS конечно были. И это даже работало, но… По вполне понятным причинам ни на одном собеседовании я не стану упоминать об этом решении.
Подводя некую черту могу заметить что прототип и конечное изделие не обязаны быть максимально похожими. Это разные стадии проектирования с разными задачами. Однако, если всех заинтересованных устраивает прототип близкий к финальному изделию — то это один из лучших вариантов.olartamonov
23.10.2019 20:41+3А то прецеденты запуска PostgreSQL сервера c NAND & UBIFS конечно были. И это даже работало, но… По вполне понятным причинам ни на одном собеседовании я не стану упоминать об этом решении
Три четверти таких прецедентов случаются потому, что разработчики софта, которым дали «прототип» на NanoPi M4, совершенно искренне не представляли себе не только что в железке будет AM3358, но что вообще AM3358 существует в природе и кому-то нужен. А уж тем более — что это ещё и довольно мощный процессор, будете выпендриваться, в следующий раз AR9331 дадим.
И это касается всего, от объёмов памяти до скоростей каналов связи.
И с микроконтроллерами то же самое — я себя регулярно бью по рукам, когда на nRF52 перестаю считать память, потому что её там Очень Много (целых 64 КБ, это реально много же), и более чем насмотрелся на университетские проекты (а это изрядная часть микроконтроллерного опенсорса), сделанные в условиях университетских же лабораторий, где база — это отладки на старших моделях процессоров, на которых лишний десяток килобайт ОЗУ никто не замечает.MinimumLaw
23.10.2019 21:06Ну, в моем случае это была необходимость сменить платформу с x86 на ARM при этом сохранив и минимально модернизировав все наработки. Ибо проект делался чуть-ли не подпольно, преодолевая сопротивление всех структур каких только можно. В итоге мы сделали это. Просто показав, что это можно сделать. Увы, этот проект именно в таком виде ушел в продакшн. Ибо автономность (энергоэффективность) ARM в сравнении с тогдашними встраиваемыми 586/686'ми на наших задачах была просто космической. К счастью, сегодня он практически полностью выведен из эксплуатации. Хотя увы, местами еще работает.
И все же мы были одними из первых кто начал жить на ARM и Linux. Для понимания — это был период еще Intel PXA255, телефоны на котором едва работали на Windows Mobile и только некоторым гикам удалось запустить на Palm Tungsten T5 вполне себе живой Linux (и то без всяких U-Boot и прочего). Андроид если и был, то в зачаточном состоянии.
Но к чему я все это? Да все к тому же. Вечный спор с прикладниками. Их позиция «сегодня ресурсов мало — завтра поставят достаточно» вполне оправдана. Чего уж там. Прогресс на месте не стоит. Но к счастью и нашу позицию «какая бы не была производительная система подавляющее большинство времени она должна спать и экономит батарею» пусть и с трудом, но находит отклик. И это правильно. Именно этот конфликт и позволяет изделиям развиваться.olartamonov
24.10.2019 07:55+1Их позиция «сегодня ресурсов мало — завтра поставят достаточно» вполне оправдана
Не, если продукт надо выпускать не сегодня, а когда-нибудь там в будущем, когда ресурсов подвезут, не вопрос.
Но реальность обычно жёстче. И в реальности после прототипирования софта на больших, жирных, привычных программистам-прикладникам системах его регулярно приходится дальше попросту переписывать. Я не только про память или число ядер, я, например, знаю случаи, когда люди в софте закладывались на получение данных с внешних объектов в реальном времени — искренне не понимая, что прописанный в ТЗ LoRaWAN так вообще не работает. Или, например, на то, что обычный GPS им в реальной жизни даст погрешность ±2 метра. Или что в устройство размером с половину пачки сигарет можно поставить старший микроконтроллер, который будет непрерывно молотить нейросетку на потоке данных с гироакселерометра — и при этом жить неделю на одной зарядке.
Поэтому прототипирование должно делаться так, чтобы прикладники изначально были зажаты в тиски будущих ограничений.MinimumLaw
24.10.2019 10:51+2Вы напрасно думаете, что я выступаю Вашим alter-ego. Это не совсем так, если не сказать совсем не так. Я всячески стараюсь избегать «политических» вопросов. Не дело инженера решать их и давать какие-то рекомендации заказчику. Его дело довести объективную картинку. Обрисовать все сложности. Даже если из-за этого будет потерян заказ. Да, возможно я и не прав. Но строго IMHO — лучше потерять заказ, чем репутацию специалиста.
А теперь давайте вернемся к исходным предпосылкам. Смотрите — вы, как автор, знаете возможности Вашего изделия. И дальше Ваше с заказчиком совместное решение — или Вы делаете его целиком сами (что неизбежно увеличит сроки) или бьете задачу на части. Задираете себе схемотехнику, системную и драйверную часть и отдаете прикладную на откуп спецам заказчика. Это позволит сократить сроки получения готового изделия. Особенно если Вы сможете выдать прикладникам эмуляторы изделия (тот самый эмулятор LoRaWAN или трек с реального GPS). И, конечно, обговорите метрики производительности. В первом приближении аналогом современных ARM'ов вполне могут стать старые нетбуки c N270 атомом. Это и только это позволит избежать описываемых Вами проблем.
И еще раз — конечно, прототип с железкой близкой к реальной — это лучший вариант. Я нигде и никогда другого и не писал. Я писал только то, что далеко не всех такой вариант устроит. Хотя бы потому, что грамотно настроить систему кросс-сборки это тоже время, а собирать нативно на не блещущем производительностью ARM'е с ограниченной по размеру RAM — то еще удовольствие.olartamonov
24.10.2019 10:55Вы правда считаете, что подготовка реалистичного симулятора радиосети или данных GPS займёт у вас меньше времени, что настройка среды сборки под ARM?..
MinimumLaw
24.10.2019 11:15Еще раз — я не знаю Вашей кухни. Но GPS можно подключить и на прямую. При некоторой сноровке и радиоканал тоже. Если Вы постоянно работаете с этими интерфейсами, то возможно проще раз сделать оснастку, чем из раза в раз воевать за производительность.
olartamonov
24.10.2019 11:26Его мало подключить. Надо, например, знать, что с ним стоит реально походить, а не удовлетвориться его показаниями после трёх суток на подоконнике.
MinimumLaw
24.10.2019 11:46У нас тоже нет эмулятора. Дорого. Но мы решаем эту проблему совершенно простым способом. Эпизодически записываем треки в реальных условиях и скармливаем его системе. Благо темп выдачи предложение в NMEA известен. Другое дело, что не NMEA единым… Но варианты есть всегда. Было бы желание их найти.
MinimumLaw
23.10.2019 21:15целых 64 КБ, это реально много же
Боюсь, далеко не всем будет понятно НАСКОЛЬКО это много. Впрочем, оставлять неиспользованной встроенную SRAM… По мне за это отдельный котел приготовлен. Это ж какой нереализованный простор для оптимизации производительности.
Dima_Sharihin
23.10.2019 21:19И насколько это мало, если у микроконтроллера куча дуплексных TCP-сокетов и 100мбит ethernet под боком
MinimumLaw
23.10.2019 21:26Можно я не буду задавать Вам вопрос почему реализация задачи обмена данными через кучу TCP-сокетов на 100BASE-T поручена микроконтроллеру с 64Кб ОЗУ и боюсь спросит какой тактовой частотой?
Dima_Sharihin
23.10.2019 21:32Но вы его задали :3
Тактовая была довольно обычная, 120 МГц. Оперативки было тоже поболее, 256 кило. А так — мост TCP-UART в количестве восьми штук на одну микросхему.
Внезапно оказывается, что без zero-copy и ручной работы "где-то на нижем уровне" эффективно эту задачу не решить. Тот же POSIX-совместимый NuttX на этом уже захлебывался от пребывающих пакетов, а lwip с raw-api вполне себе работаетMinimumLaw
23.10.2019 21:57Но могли бы не отвечать :3
Не знаю. Смотрите, пусть скорость не большая. Этак 115200 на хвост. Будем грубо считать 10KiB в секунду на направление. Интерфейс дуплексный — значит 20KiB в секунду, да на 8 интерфейсов — это в пике 160KiB в секунду только на полезных данных. По сети. Если не резать MTU (а это 4KiB) то 4*8*2=64KiB только для сетевых буферов. А их еще по памяти и между памятью и периферией гонять надо. Вот и получается что ресурсов-то не много. Сильно не разгуляешься. Так что вполне очевидно, что без «ручной настройки» не обойдется.
Впрочем, не сказал бы что задача не решаемая. Вполне себе эпизод из жизни разработчиков подобной аппаратуры. Правда вот необходимость именно TCP меня как-то немного подгладывает. Впрочем, если это было в ТЗ, то с ТЗ, как известно, не спорят.Muzzy0
24.10.2019 20:04с ТЗ, как известно, не спорят.
Почему? Спорят. Не всегда успешно, правда.MinimumLaw
24.10.2019 20:18На данном этапе уже поздно спорить с ТЗ. Любые споры с ТЗ после его утверждения — минус в карму разработчика. Уже надо кровь из носу реализовывать.
Спорить надо было раньше. Только это называется не спорить, а согласовывать. И это, конечно, обязательный этап. От него слишком многое зависит.
olartamonov
24.10.2019 08:03У нас единая программная платформа на STM32L0/STM32L1/STM32F0/STM32L4/nRF52, с требованием, что в рамках понятных аппаратных ограничений с точки зрения прикладной части прошивки она должна на этом всём работать одинаково.
Работая на двух последних, надо очень чётко помнить, где ты правишь код, который нужен только вот в этом конкретном проекте, а где ты в общеплатформенных вещах начал плодить треды со стеками по несколько килобайт, потому что «ну ещё дофига памяти же».
Ибо завтра кому-то, возможно, тебе же, эти же вещи потребуется на STM32F030 запускать.romanetz_omsk
24.10.2019 08:27+1Когда компания делает примерно похожие устройства — вполне возможно, в одной из предыдущих компаний, где работал, вообще не заморачивались, ставили один процессор почти во всю номенклатуру, цена комплектухи растворилась в конечном изделии
MinimumLaw
24.10.2019 11:01В каждой избушке свои погремушки. И не мне кого-то чему-то учить. Все же в мире встраиваемых систем программирование пока (к счастью) остается искусством.
Однако (чисто на вскидку) я бы поразмыслил на тему выделения критичных к производительности функций в отдельную секцию. И размещал эту секцию либо в RAM (минимизация задержек на считывание и выполнение инструкция) либо во FLASH если RAM мало. Linker script все равно у каждого проекта свой.
Ну, и про унификацию ниже правильно написано. Тут правда вопрос — что первично, а что вторично. Если первичен премиум, а бюджет — это для самых бедных и жадных, то есть смысл унифицироваться. Если наоборот — то надо думать.
Но еще раз — я Вашей кухни не знаю. Потому это просто иллюстрация к сказанному.
chuck
23.10.2019 16:11Любопытно, а если не C/C++/Python, а Go?
MinimumLaw
23.10.2019 16:34Если ресурсы позволяют — то что угодно. JAVA, C#, Go. Нет проблем. Кроме, ресурсов, конечно. Ну, пожалуй еще вопросы правильного питания и охлаждения всегда актуальны. А так даже OpenCL/OpenGL не самые редкие гости в современных встраиваемых системах.
chuck
23.10.2019 17:48Я понимаю, что можно. Вопрос больше на тему – кто пробовал, какие результаты. На сколько хуже по производительности по сравнению с тем же С++?
MinimumLaw
23.10.2019 19:47+1Боюсь что конкретного ответа Вы не дождетесь. Все же в мире встраиваемых систем это экзотика. Мое персональное мнение — не стоит. Если только задача не заточена четко под Go. Да и в этом случае я бы подумал.
Понимаете тут все довольно человеко-ориентировано. Допустим Ваша задача решена на Go и необходима строго ее мобильная версия. Тогда можно думать в таком ключе. Но если задачу еще только предстоит решить, то с учетом ограниченности ресурсов (а уж поверьте, их всегда и всем мало) лучше брать более низкоуровневые языки. Даже больше — если можно обойтись без плюсов, лучше обходиться. Выкидывать все новомодные штучки и вспоминать о такой замечательной вещи как Unix-way.
Впрочем, python прополз и в этот мир. Думаю, что рано или поздно прикладники и здесь начнут диктовать свои условия. Потенциально даже исключать системщиков как лишнее звено между собой и схемотехниками. Во всяком случае есть некоторые сигналы, говорящие о том что такой расклад совсем не выглядит «страшной сказкой на ночь».
Но это позже. А пока разве что Rust способен что-то противопоставить C и C++. Но, «поверьте, здесь не все так однозначно» (с) Впрочем, темой Rust я с подачи Habr'а сам только недавно озадачился. Пока считаю что нет смысла писать на Rust как на C, когда есть непосредственно С. Впрочем, когда-то я тоже самое говорил про ассемблер. Потому ограничусь тем, что "… но это не точно" (с)Dima_Sharihin
23.10.2019 20:08+1python прополз и в этот мир
Не вижу ничего плохого в плюсософте в эмбеддеде, но python — это +30мегабайт к размеру дистрибьютива.
Если нужны тысячи мелких скриптов, то на это дело есть lua, как в OpenWRT. Если сильно повезет, и у вас платформа — ARM, то даже с LuaJITMinimumLaw
23.10.2019 20:16Если бы я мог себя клонировать раз хотя бы 30 — то весь системный код был бы написан на MISRA C, а GUI на QT. Но увы, у отдела прикладников свои взгляды на целесообразность тех или иных инструментов. К счастью, конкретно в моих изделиях +30MiB далеко не самое страшное.
Dima_Sharihin
23.10.2019 20:20+1А как MISRA-C сочетается с пингвином? Она же запрещает половину POSIX-стиля.
Разве что в гетерогенной системе вторую прошивку делать мисройMinimumLaw
23.10.2019 20:32+1Давайте я сразу обозначусь — все что ниже это мое персональное мнение. Жестко по MISRA у меня сертифицировалось всего пара проектов, и те по голому железу. Потому применительно к Linux у меня нет практического опыта, а есть только размышления.
И так — в принципе вполне. Если впадать в крайности и будет требоваться жесткое соответствие исходников MISRA, то это реализуемо. Другое дело, что разумнее конечно относиться к MISRA не как к ограничивающему стандарту, а как к «правилам хорошего тона».
В микроконтроллерной среде у этих рекомендаций, конечно, больше шансов, чем под операционной системой. Но даже там — если заказчик жестко не требует, то я для улучшения читаемости и сопровождаемости кода я в целом ряде случаев отступаю от требований. Они все же во главу угла ставят надежность. Для того и создавались. Временами разумнее плюнуть на надежность там, где и без MISRA уверен в результате, но написать понятный код. Это работает надежнее, чем комментарий на две страницы.
Но в целом рекомендации очень толковые. И как минимум один проект целиком и полностью по ним стоит сделать.
lingvo
23.10.2019 20:54А как MISRA-C сочетается с пингвином?
Да никак, наверное. Дело в том, что мизра заточена прежде всего на риал-тайм и детерминизм исполняемого кода. Об этом свидетельствует, например, прямой запрет на динамическое выделение памяти и рекурсивные функции — т. е. те вещи, что порядочный разработчик и так в данном случае использовать не будет. Тем более в этом случае в железяке нет места Линуксу.
Muzzy0
24.10.2019 20:08Думаю, что рано или поздно прикладники и здесь начнут диктовать свои условия. Потенциально даже исключать системщиков как лишнее звено между собой и схемотехниками.
Ну да. А потом — «Нафаняааа!» в ночь перед сдачей :)))MinimumLaw
24.10.2019 20:34Профессиональная гордость — это хорошо. Безусловно, по крутости с системщиками могут сравниться разве что электрики. И со своими прикладниками я могу договориться даже до мата (даром что Питер — культурная столица). Но ругаться с ними могу только я. Причем только лично.
Во всех остальных случаях они толковые специалисты, вполне способные самостоятельно справляться с задачами любой сложности. Как и схемотехники — настоящие кудесники припоя и контактов. Как и остальные подразделения в моей организации. И это правильный командный дух. А в ночь перед сдачей мы все со спокойной совестью спим дома. К этому моменту вся работа уже сделана. Поэтому я, пожалуй, просто сделаю вид что ничего не заметил.
ld100
24.10.2019 18:06+1Сейчас как раз делаем прототип железки на Raspberry PI, внутри которой наш софт крутится на Go. В начале года делали софт для другой железки на C и Go. Производитьельность сама по себе будет сопоставима, но основная разница не в производительности, а в возможностях.
Скажем, если вы прототипируете на Raspberry PI и в продакшене у вас будет он же или что-то аналогичной конфигурации, то пишите хоть на Go, хоть на Python. По сути Raspberry PI с Linux'ом с точки зрения разработки не особо отличается от обычного x86-сервера с линуксом.
Совсем другое дело, если вы, скажем, решили порезать затраты и в продакшене у вас будет железка с тем же линуксом, но с 10mb ROM и 16MB RAM. Тут, вдруг, окажется, что ваш бинарник на Go весит 15 мегабайтов и не влазит на ROM или окажется, что в 16Mb оперативки вы не влазите, потому что Garbage Collector Go не всегда своевременно освобождает память. Вот в подобных случаях хардкорные C/C++ с их ручным управлением памятью вполне могли бы подойти.
А может у вас железка — это не system on chip, в всего лишь микроконтроллер вроде ESP32 или STM32, такие стоят всего $3-5. На Go для них в принципе нельзя писать. Есть прошивки позволяющие их программировать на Python/JS но на мой взгляд это подходит разве что для домашнего баловства, если же делать что-то серьезное для этих микроконтроллеров то альтернатив C/C++ в принципе нет пока.
Думаю, для написания прошивок микроконтроллеров подошел бы отлично Rust, но пока такой возможности нет. Помимо этого есть еще важный нюанс — для микроконтроллеров уже есть сишные фреймворки Arduino, Esp-now и.т.п., есть сишные библиотеки для типичных задач (например, реализация Wiegand-протокола) или драйвера для периферии (те же камеры) и все это в первую очередь на C/C++.MinimumLaw
24.10.2019 20:13+1Ну что, если с конца то все не совсем так. Это про Rust. Мне подсказали, а я готов поделиться:
github.com/rust-embedded/cortex-m-quickstart — начало
github.com/rust-embedded/cortex-m — чуть более весело
rust-embedded.github.io/book — когда башню сорвет окончательно
В принципе с Cortex-M можно начинать работать. Конечно, это далеко не так хорошо как с С в части BSP (да даже CMSIS), но начинать можно. Боюсь только что кросскомпиляция далеко не самая приоритетная задача для авторов Rust.
В остальном со многим согласен. Хотя скажу честно — лично у меня вызывает некоторые сомнения Raspberry PI в конечном изделии. Мне спокойнее с хорошо зарекомендовавшими себя форматами от уважаемых и давно присутствующих на рынке производителей. Мое сердце рвется меду Phytec и Toradex. Но это мое. С Raspberry смущает ее доступность на длительных временных отрезках и относительная закрытость. Временами я с ней наблюдал загадочные явления, разгадать которые без Broadcom'а было практически невозможно. Ну и странная система старта (и безопасности обновлений как следствие) несколько охлаждает пыл.
anshev0
23.10.2019 16:53Отличная статья, спасибо. Полностью согласен, сам участвовал в проекте где перебробовали более 50 прототипов казалось бы очень простого устройства и программы на С. Даже не предполагаешь, что вылезет, особенно на дешёвых платах и запчастях заказанных с Ali. И про аутсорс верно, но это уже из ПО на полноценных PC и серверах, если вас подсаживают на аутсорс, то катастрофически убывает уровень понимания, что происходит в системе и скорость реакции на изменения в окружающем мире. Нет своих специалистов, которые на этапе тех.заданий и тех.решений предложат сразу лучший вариант.
olartamonov
23.10.2019 20:45+2А зачем вы заказываете запчасти с али?..
dernuss
24.10.2019 08:57Я ещё с Таобао заказываю. Потому что на Али нет
olartamonov
24.10.2019 09:31+1Я не спорю, что есть много способов прострелить себе ногу. Просто не понимаю — зачем, ведь потом врачи, костыли, заражение крови, гангрена, смерть?
dernuss
24.10.2019 10:58ну а ещё есть китайские комплектующие, которые на digikey не продаются
anshev0
24.10.2019 12:31Дешевле, а время не критично. Деньги собственные, проект как хобби. Клоны Arduino на разных Atmega или ESP8266 c USB, bluetooth, wi-fi и т.д. и т.п., больше для изучения и объяснения детям, не занимаюсь этим на постоянной основе. Доделают дети через пару месяцев, может напишу статью как это было.
lingvo
23.10.2019 17:55+10Сорри за стеб, но рукоплескаю автору — давно не читал такое веселое изобретение колеса, как описание разработки железа от программистов. Оказывается, Agile не работает! Юху! Оказывается, нужно прототипировать! Юху! Оказывается, нужно писать на Си! Юху! И это даже еще без намека на ее величество Сертификацию, которая может угробить ваши многомесячные труды на корню и добавить еще столько же времени на переделку, сколько вы уже потратили.
Особенно понравилось про минимизацию рисков — боже, я представляю, сколько стартапов на загнулось, так как они их просто не могли оценить. Аутсорсинг прототипов? Да ничего сложного, просто вы их не умеете готовить.MinimumLaw
23.10.2019 20:10+2Да ладно Вам. Во-первых это Yandex. В каждой избушке свои погремушки. А во вторых это все же интереснее очередной метеостанции на Arduino или Internet Radio на ESP32 или пивоварня на Raspberry. Меня, например, на ностальгию пробило. Вспомнились свои ощущения от первых проектов.
Про сертификацию Yandex, возможно, и не услышит. Их оборудование, как я понимаю, не включается в критические цепи автомобиля. Т.е. как видеорегистратор — формально сертификации не требует. Разве что на ЭМС. Да и не так уж страшен черт, как нам его малюют. Первые разы тяжело — потом привыкаешь. А аутсорсинг прототипов (как, собственно и всей разработки) — ну что Вы хотите. Хорошо что хоть до кого-то дошла сама глупость такой постановки вопроса.
Так почему бы и не похвалить авторов? Ну а на некоторые недостатки в комментариях уже указали. И Вы, lingvo, и kababok, и lelik363 и многие другие. А вот то, что на хабре есть не только прикладники меня радует. Хоть знать буду «коллег по цеху».
Впрочем, не думаю что хоть кто-то смог бы написать сильно лучше. Все же каждая компания, занимающаяся встраиваемыми системами уникальна и неповторима. У каждой своя методология разработки. Да что компания — по сути каждый проект уникален.lingvo
23.10.2019 20:22+2Ну я честно поставил плюс к статье, так что не надо на меня наседать. :-)
А насчет погремушек хотел ответить внизу, но отвечу тут — есть такие штуки, как "Design Practices" — документы для внутреннего пользования, которым стоит следовать при проектировании. В железе их очень ценят, так как это накопительный опыт предыдущих разработок, позволяющий избежать множество ошибок новичков и позволяющий получать A-Muster сразу и с первой итерации в серийном качестве. В Яндексе, похоже, эти Design Practices только пишут, так что удачи им с этим.
MinimumLaw
23.10.2019 20:48+1есть такие штуки, как «Design Practices» — документы для внутреннего пользования, которым стоит следовать при проектировании.
Увы. Боюсь не у каждой из Российских контор есть такой документ. И, конечно, эту практику у немцев стоит перенимать. Им отчасти повезло. Все же крылатая фраза из фильма (дай бог памяти) «нет такой работы, которую не смог бы делать солдат кайзеровской армии при наличии инструкции» достойна восхищения. Создание, поддерживание актуальности и следование данным рекомендациям действительно сильно сокращает затраты.
В наших же условиях этими самыми рекомендациями каждый разработчик обзаводится в курилке. Перенимая и творчески переосмысливая опыт старших товарищей и набивая собственные шишки. Тоже путь. Местами приводящий к революционным прорывам. Но чаще — к крайне нестабильному качеству выпускаемой продукции.
Кстати, а не поделитесь секретом — как поддерживается актуальность «Design Practices»?
kababok
23.10.2019 18:49Эх, вот много горького и справедливого в словах lingvo в комментарии выше.
В реальности автомобильные проекты не делают "водопадом" — заранее проектируются как минимум 3 фазы железа: A-Sample / B-Sample / C-Sample (или A-Muster и т.д. на немецком)
Где C-Sample — это уже серийный образец железа с удалёнными всеми отладочными интерфейсами.
А бывает даже A...F-Sample
Что, по сути, те же самые итерации, просто более жёстко запланированные.
kababok
23.10.2019 18:55А ещё от ведущих поставщиков железных компонентов можно заказать evaluation board.
Или, например, если говорить о модных робомобилях — у тех же Интела / nVidia / Bosch / Continental / TI и пр. можно прямо-таки взять напрокат те или иные сборки ECU/GPU и обвесок и покататься со своим софтом на них.
(здесь можно подергать saul со стороны Интела и, например, Boomburum как представителя БМВ :)))
lingvo
23.10.2019 19:30Что, по сути, те же самые итерации, просто более жёстко запланированные.
Причем эти итерации для железа имеют еще и вполне определенные названия, и прототипы для них тоже. Proof of Concept, Design Prototype, Validation Prototype, Redesign-to-cost и прочие. И весь смысл, в том, что количество повторений каждой итерации желательно уменьшить до одного раза. А не то и время и деньги закончатся очень быстро.
kababok
23.10.2019 19:32В автоиндустрии вообще не напрягаются — реально так и делают: A-Muster — и в путь.
"Зачем писать больше?!" :)
Dima_Sharihin
23.10.2019 19:10На C++ выстрелить себе в ногу чуть-чуть проще
То, что С++ раздувает бинарь я согласен (особенно стандартный iostream и иже с ними), но вот то, что в крестах легче выстрелить в ногу? В Си нет std::unique_ptr, нет RAII, нет многих восхитительных вещей, что есть в крестах.
brun4eg Автор
23.10.2019 19:15+1Если совсем упростить, то С работает примерно везде, если есть компилятор, ваш код скорее всего заработает.
Если писать на С++, есть очень высокая вероятность, что на какой-то конкретной железке компилятор и тулчейн устарели, не обновляются, а вы уже написали код с использованием каких-то модных вещей.
Можно ли этого избежать? Да, но проще писать на С :)Dima_Sharihin
23.10.2019 19:25В тексте документа были в основном всякие линуксожелезки, в них в 99.999% случаев есть gcc, и можно собрать свежий из исходников. А значит автоматом есть и свежайший С++.
Просто нужно не давиться тем, что дал вендор платы, а сразу брать buildroot/yocto project и жить с новым компилятором
brun4eg Автор
23.10.2019 19:27+1Я про то, что когда понадобится переходить на узкоспециализированное железо, где уже не будет нормального линукса или будет, но очень древний, вариантов найти нормальный тулчейн и компилятор может не быть.
Dima_Sharihin
23.10.2019 19:28Поэтому вместо того, чтобы написать ПО за N дней, будем давиться голым ANSI C89, чтобы написать то же самое за N*3 дней?
Инструментарий выбирается "на берегу", когда еще ни одной строчки кода не написано
NiPh
23.10.2019 22:47+2Ну, если экономия на железе покроет N*3 дней (а при массовом производстве — покроет), то да, давиться.
Не очень понятно про какой этап выговорите, возможно поэтому непонимание.
Если про первый, где прототип — то можно действительно на ноде в распбери писать, но если это следующий шаг, где прототип более приближен к конечному железу — то есть смысл переходить на конечные инструменты.
potan
23.10.2019 20:49+1За то в C нет невиртуальных диструкторов, переопределения операций…
humbug
23.10.2019 22:42+3В Си нет std::unique_ptr, нет RAII, нет многих восхитительных вещей, что есть в крестах.
В C++ нет борроу чекера, нормальной системы владения, нет многих восхитительных вещей, что есть в расте. И выстрелить в ногу сложнее. Почему ты не рассматриваешь этот вариант?
Dima_Sharihin
24.10.2019 07:38+1Потому что на цепепе я пишу четыре года, а на расте даже хелло ворлда не писал. Учиться новому это хорошо, но не на проектах с заранее оговоренными сроками :)
Да и не очень уверен, как у последнего с поддержкой в yocto/openembedded, свежий GCC у которого есть искоробки.
potan
23.10.2019 19:35+3В плане языка разработки — почему не Rust? Как и в питоне не надо будет мучительно отлаживать работу с памятью, но при этом доступно реальное время, как на C/C++.
CodeRush
23.10.2019 22:40Сыровато пока, и разработчиков нет толком. Я стараюсь для себя больше на С и С++ не писать (за исключением поддержки уже написанных проектов), но на работе альтернативы С пока нет.
humbug
23.10.2019 22:46А что именно сыровато?
CodeRush
23.10.2019 23:04+1Вся инфраструктура сыроватая, стандарта у языка нет, компилятор единственный и не сертифицированный.
Если прошивку прямо с нуля на нем разрабатывать — можно уже сейчас, если вот эти проблемы выше не блокируют, а вот если внедрять какие-то куски на Расте в уже существующую большую кодовую базу на С, то начинаются проблемы вроде невозможности использования заголовочных файлов с typedef, и неполной совместимости моделей памяти и владения (отчего половина glue-кода получается внутри unsafe-блоков), различия в подходах и т.п.
Короче — работы по внедрению много, а то, что результат в итоге получится сильно лучше, чем без такого внедрения — на воде вилами писано, поэтому бизнес пока что вставать в стройные ряды Rust Evangelism Task Force не спешит.humbug
23.10.2019 23:33поэтому бизнес пока что вставать в стройные ряды Rust Evangelism Task Force не спешит.
Бизнес бизнесу рознь. Особенно круто к таким гигантам как AWS, Cloudflare и Mozilla присоединился Microsoft в недавней статье:
My job was to port a security critical network processing agent into Rust to eliminate the memory safety bugs that had plagued it.
А вообще вы описываете проблемы, которые возникнут при смешивании двух разных языков.
Какие такие заголовочные файлы с typedef, которые (.h) в расте в принципе отсутствуют?
KanuTaH
24.10.2019 03:15Какие такие заголовочные файлы с typedef, которые (.h) в расте в принципе отсутствуют?
Такие, которые вендорами железок обычно поставляются. Естественно, они отсутствуют в расте, как и вообще поддержка раста вендорами железа, и это одна из его многочисленных проблем.humbug
24.10.2019 04:23Ваше мнение очень интересно, но мне бы хотелось услышать CodeRush
KanuTaH
24.10.2019 04:25Это как бы не мнение, а факт. Я понимаю, что евангелисты раста неудобные для себя факты предпочитают игнорировать, ну или в крайнем случае заминусовывать, но факты — упрямая весчь.
CodeRush
24.10.2019 05:32KanuTaH дело говорит, пока на вендоры железа не начнут писать на Расте свои BSP, потребителей этих BSP, всяких OEM, ODM и IBV пересадить на него будет очень сложно, потому что сразу вылезут все проблемы с интеграцией (и реинтеграцией постоянной, потому что вендор обновляет свой код регулярно), о которых я тут и пишу.
Я не соглашусь с тем, что это проблема Раста, нет, это проблема косности и нежелания вендоров переходить на более качественный язык, но пока их все устраивает на С (а их все устаивает, они с ассемблера кое-как перелезли совсем недавно, меньше 15 лет назад), ничего со своей стороны они менять не станут — это дорого, а софтом они не торгуют (т.е. софт может быть любого качества, лишь бы работал хоть как-то).KanuTaH
24.10.2019 06:00Вендоров тоже можно понять, ресурсов на перелезание на раст нужно много, а будет ли из этого какой-то толк — вовсе не очевидно. Я бы не назвал это "косностью", это обычная прагматичность.
CodeRush
24.10.2019 06:20Толк будет в любом случае, я думаю, потому что затраты на поддержку низкого уровня ошибок теперь переложены на компилятор (который не устает), и в долгую эта стратегия все-таки окупается так или иначе. Безопасники давят со своей стороны, хоть и несильно, но стабильно, плюс можно оказаться в авангарде прогресса и получить бесплатную рекламу, плюс те подходы к дизайну, которые вынуждает применять Раст (иммутабельность по умолчанию, RAII, pattern matching, data race safety) — они сами по себе часто приводят к ускорению и упрощению кода, и получается тут на 5% быстрее стало, тут на 10% меньше ошибок, с миру по нитке — вот новый телевизор.
Рано или поздно на Раст (или другой более безопасный, но все еще достаточно низкоуровневый ЯП) все равно перейдут (т.к. С для потоковой коммерческой разработки — это все-таки очень плохой инструмент, скальпель в руках коновала), потому что их додавят таки безопасники, но не думаю, что это получится сделать скоро.
NVIDIA, кстати, недавно перешла на ADA/SPARK для своих automotive-проектов.KanuTaH
24.10.2019 06:31У меня несколько более скептическое к этому отношение, коновал — он коновал и есть, что ему ни дай, все будет плохим. Дадут раст — будет злоупотребление unsafe во имя срезания углов и т.п. Сейчас вон для C тоже и практик и инструментов хватает: и анализаторы всякие статические, и TTD, и MISRA, но сроки горят, и все такое, и с растом все будет то же самое.
CodeRush
24.10.2019 06:58Согласен с тем, что свидетелям святого дедлайна и поборникам стиля куяк-куяк-и-в-прод замена С на Раст поможет мало, и они в своем новом коде тоже начнут срезать углы направо и налево. При этом даже в таком говно-расте срезанные углы можно искать поиском по unsafe, плюс компилятор не даст собрать совсем уже невообразимую херню вроде замены "&" на "&&" или "&&" на ",".
В приличных местах (где за качество результата все таки готовы сколько-нибудь отвечать) говнокодеров рано или поздно либо перевоспитывают, либо изгоняют, и остаются люди, которые хотели бы писать на С хороший, добротный код, решающий их задачи и не отнимающий на написание слишком много времени, но они не могут, даже если хотят, потому что это выше человеческих сил.
На Расте, все же, намного проще писать, потому что нужно меньше вещей держать в голове (управление ресурсами в коде, переполнение буферов отслеживается компилятором, инициализация автоматическая, молчаливых приведений типов нет, молчаливых знаковых расширений нет, за арифметику с указателями бьют по рукам, за накидывание структур на память бьют по рукам, и т.п.), т.е. по итогу писать нормально, стабильно выдавая подходящий результат за разумное время, на нем может большее количество людей, и ошибок в коде получается в среднем меньше, по крайней мере мне так показалось. На С же нужна предельная концентрация внимания, постоянные проверки и перепроверки, вагон всякого тулинга и анализаторов, а в результате все равно имеем вот такое:
KanuTaH
24.10.2019 07:09В растовских крейтах такого добра тоже хватает, причём, казалось бы, никакие дедлайны на авторов не давят. Ну, поживём-увидим.
MinimumLaw
24.10.2019 07:23Интересная ветка. И интересные выводы. Я бы, правда, сказал что они довольно спорные.
Я думаю, что C умрет ровно в тот момент, когда исчезнет необходимость ради производительности расшивать сложные места на уровне ассемблера. На ПК это счастливое событие давно произошло. И спровоцировало рост непонятного по качеству и постоянно растущего в размере кода. Встраиваемые системы пока держатся, но Cortex-M на несколько сотен мегагерц да с мегабайтами памяти — это очень хороший шаг в этом направлении. Видимо первым языком, который в этот момент потеснит С, станет как раз Rust. Правда не уверен, что его быстренько не сменить какой-то интерпретатор байт-кода. Но это пока не увидишь — не узнаешь.
А вопрос сертификации, сроков и прочего… Я думаю, что это скорее вопрос грамотного планирования и управления разработкой. Ну, и конечно, квалификации разработчика. Тут действительно от языка мало что зависит.CodeRush
24.10.2019 08:05Запрос на замену С на низком уровне идет сейчас с нескольких сторон, и производительность — не самая популярная из них, на мой взгляд. Код на и на Расте, и на С — достаточно быстрый, а критические части все равно придется писать на чем-то, напрямую ложащемся на архитектуру, будь это ассемблер или что-то еще похожее.
Я безопасник, и потому мне замена С нужна для того, чтобы среднестатистический код, написанный среднестатистическим обычным разработчиком-мидлом (который мало что понимает во всей этой безопасности ненужной, он по своей предметной области специалист) перестал быть невыносимо отвратительным с точки зрения сопротивления внешним воздействиям. Если такой достаточно-безопасный код при этом еще и нормально переживет нахождение в большом репозитории на несколько десятков проектов, в который каждый день коммитят несколько десятков человек, и его безопасность не деградирует со временем до состояния «след простыл» — моя жизнь станет значительно лучше, и CVE станет значительно меньше.
Опыт при этом показывает, что С в данном случае не помогает ничего, ни тулинг, ни грамотное управление, ни внедрение SDL, ни обучение всех разработчиков основам security mindset, потому что инструмент никогда под безопасность не затачивался, и требует соблюдение железной дисциплины не просто от программиста, а вообще от всех программистов, когда либо трогавших код на нем.
Писать безопасный код на С нечеловечески сложно, медленно, и потому дорого, от этого дырявое нынче абсолютно все, и очень много усилий направлено в итоге на то, чтобы заставить всю эту гору кода на С и его производных, которую мы все уже написали и вынуждены использовать и поддерживать, вести себя хоть в каких то рамках приличия. В железо пришлось затащить и теневой стек (чтобы хоть как-то бороться с ROP), и шифрованную и\или тегированную память, и компартментализацию (многоуровневую), и даже контракты (CHERI), и занесут еще вагон всего, только бы ПО не чинить.
В общем, Раст — это шаг в очень правильном направлении, и я его приветствую всеми фибрами души.MinimumLaw
24.10.2019 11:33Сложно что-то возразить. Грамотная и абсолютно правильная постановка вопроса. Впрочем, сложно — не значит невозможно.
На меня в свое время произвела большое впечатление замечательная публикация Шенона «Надежные схемы из ненадежных реле». Я тогда впервые задумался над тем насколько реально писать надежный код на любой из современных архитектур. Ведь по сути чем ниже язык, тем больше он подвержен специфическим особенностям каждой конкретной архитектуры. И язык C, как один из самых низкоуровневых языков просто вынужден наследовать все косяки, которые только реализованы непосредственно в архитектуре вычислительной системы. А любой подъем выше порождает не менее известную проблему «кто контролирует контролеров». А если добавить сюда все возможные аппаратные сбои, на которые тоже надо адекватно реагировать, то все становится совсем грустно.
И по сути хотим мы того или нет, а у нас не остается выбора кроме как крутиться внутри этой ненадежной системы впадая в ту или другую крайность при этом постоянно исправляя те или иные косяки в тех или иных частях кода. Потому, думаю, даже в среднесрочной перспективе спрос на «безопасников» и «системщиков» никуда не денется. Как и спрос на прикладников.lingvo
24.10.2019 12:05Ну, в принципе во многих сферах эти проблемы все-таки успешно решили. Да, дорого, да, возможно не так эффективно, как хотелось бы. Да, порог вхождения достаточно высокий. Но лучше ничего нет.
Ну и поэтому немного смешно и одновременно грустно, что кто-то вдруг может решить, что эти проблемы можно решить вот так с наскока, просто перейдя на другой ЯП. А грустно от того, что все эти заморочки с Boeing 737 MAX или авариями автопилотов Теслы, покажутся нам детским лепетом, когда начнет падать такой "безопаснонадежно" написанный софт.
MinimumLaw
24.10.2019 13:22Я ничего не скажу про Tesla. Во-первых даже близко не владею вопросом, во вторых для меня до сих пор вопрос больше или меньше единицы соотношение хайпа к технике в этом проекте.
А вот по 737 MAX… Это действительно грустно. Уж казалось бы есть крайне немного сфер, где надежность и безопасность поставлена во главу угла. И авиация одна из них. И такой вот результат. Впрочем, наглядная демонстрация того самого философского вопроса про контроллеров контроллеров.
Впрочем, я не настолько пессимистичен как Вы. Мне кажется просто будет более жесткий водораздел между уровнями. Простейшая аналогия есть в области медицины. Там тоже времена универсальных специалистов прошли и наступила довольно жесткая специализация при обязательном владении базовыми принципами. Думаю, что IT рано или поздно постигнет та же участь. Оно уже есть. Я свою карму уронил до предела в спорах с прикладниками. Наивен был — думал удастся убедить. Ну да ладно, не о том сейчас. Сейчас о том, что прикладникам так или иначе нужны языки без «указателя на указатель по указателю», а системщикам не останется выбора кроме как использовать такую конструкцию. Конечно, системщиков нужно будет сильно меньше, чем прикладников. Но водораздел думаю будет, и будет довольно четкий. Это сейчас условный PHP-разработчик может довольно легко реализовать свой драйвер под тот же Linux. И даже довести его до mainline при должном желании. Думаю, в недалеком будущем нынешние программисты на C будут такими же странным товарищами, как сегодняшние Cobol'щики в финансовых сферах. Но спрос на них все равно останется.
И, конечно, у будущих системщиков не останется другого выбора кроме как осваивать безопасное написание своего кода. Хорошо, если к тому моменту появятся инструменты облегчающие данную задачу. Тот же Rust вполне годится как такой инструмент.
CodeRush
24.10.2019 16:55Мы тут, мне кажется, говорим про разную безопасность, я — про «security», а вы — про «safety». Более того, одним только переходом на другой ЯП дело точно не ограничится, и это вовсе не серебряная пуля, но без этого перехода ограничения становятся слишком сильные, разработка слишком медленной и дорогой, и потому security продолжают заметать под ковер в погоне за сроками.
Safety — это отдельная тема, которой я касался не очень сильно, и довольно давно, поэтому разговор предметный по ней не поддержу, прошу пардону.lingvo
24.10.2019 18:07Мне кажется мы просто обсуждаем два варианта отказа кода.
один — это когда правильно написанный и проверенный код вследствие ошибки компилятора или другой архитектуры процессора вдруг поведет себя неверно. Тут программист практически бессилен, кроме принудительного введения дополнительных ограничений, которые не позволят ему использовать некоторые свойства языка, которые потенциально могут привести к данной проблеме.
второй — это когда в силу явных или неявных особенностей языка закрадываются программные ошибки в сам исходный код, и которые возникают именно из-за программистов и их косяков, а компилятор или архитектура ни причем. То есть компилятор и железо ведут себя абсолютно правильно.
При этом что safety, что security страдают от обоих этих косяков.
MinimumLaw
24.10.2019 21:22Да, Вы абсолютно правы. Говоря о безопасности и надежности я имею в виду в первую очередь «Safety first». Пожалуй в пору признавать что это уже профессиональная деформация и меня так или иначе а будет клонить именно в эту сторону.
С другой стороны, а скажите — то, что реализовано в части того же SecureBoot не кажется Вам некоторой чужеродной надстройкой. По мне так тут как раз стык безопасности и секретности. Секретность как в первую очередь следствие потенциальной небезопасности написанного кода, а во вторую защиты коммерческих интересов. Впрочем, что первично что вторично — вопрос открытый.
Да и вообще. До поры человек с программатором или паяльником мог творить что угодно. И извечное простивостояние меча и щита никогда не закончится. Это ж один из ключевых двигателей прогресса.
Исходя из таких соображений крайне сложно отделить секретность (гарантированную неприкосновенность ключей в чипе) от безопасности (защиты программного продукта от недокументированного воздействия извне и адекватной реакции на него).
Вообще удивительно — но большинство тем уходит именно в эту область. А если уж до конца честно, то вопрос «security» я бы оставил исключительно для специальных применений. Сильно больше уделяя внимание именно «safety». Да, первое жизнь миллионов в руках политиков, но ведь второе жизнь каждого отдельно взятого индивидума. При чем практически всегда. Тут и боровые компьютеры в транспорте, и системы контроля утечек газа и много чего еще.
Muzzy0
24.10.2019 20:20С для потоковой коммерческой разработки — это все-таки очень плохой инструмент, скальпель в руках коновала
Скальпель, который должен быть в руках хирурга. Но все хотят сэкономить и нанимают коновалов…
CodeRush
24.10.2019 05:16вы описываете проблемы, которые возникнут при смешивании двух разных языков
Действительно, потому что уже писал, что если начинать писать с нуля — Раст нормальный уже сейчас, но с нуля прошивки сейчас мало кто пишет, начинают с существующей кодовой базы из BSP, EDK2 и набора собственного уже написанного кода, который весь переписывать никому не интересно — он работает уже сейчас.
Какие такие заголовочные файлы с typedef, которые (.h) в расте в принципе отсутствуют?
Почти все интерфейсы между модулями в EFI описаны в виде т.н. протоколов, которые по факту — С-структуры с указателями на функции. Выглядят они примерно вот так. Таких файлов в проекте — море разливаное, и нужен инструмент, который автоматически генерировал бы из них определения, понятные коду на Расте (потому что держать два источника этих определений — преступление, они тут же разойдутся). Смотрел полгода назад — утилиты такой не нашел, все конвертеры c2rust не могут прожевать typedef'ы, union'ы и битовые поля, а в коде прошивки их очень много.
potan
24.10.2019 01:11Инфраструктура Rust одна из самых проработанных. У C/C++ инфраструктуры в принципе нет.
Стандарт то есть, но точно почти ни где не реализован. Да и неопределенного поведения в нем полно.
Вы правда пользуетесь сертифицированным компилятором C?CodeRush
24.10.2019 05:25От того, что инфраструктуры у С в принципе нет, ее каждый крупный проект и каждая крупная компания пишет самостоятельно и под свои задачи. В итоге, когда требуется интеграция Раста как еще одного ЯП в добавок к ассемблеру, С, ASL и VFR, начинаются сложности, потому что либо придется лишаться преимуществ cargo, либо придется как-то женить cargo и существующую инфраструктуру, чтобы не разломать обе. Это вот — целый проект на несколько месяцев само по себе, а всем некогда — задач полно, сроки подходят. Апдейты EDK2 — целое приключение, а тут нужно добавить целый новый ЯП…
Про стандарт: дело не в том, что он нигде не реализован весь (весь он и не нужен), а в том, что в компиляторе можно быть уверенным сколько-нибудь, особенно если у вас архитектура какая-нибудь непопулярная. Мне от этой уверенности не жарко и не холодно (потому что EFI использует последние версии clang, а не сертифицированный компилятор, отлитый в бронзе), но я знаю людей, которым нужен и стандарт, и сертифицированный компилятор, и которые без них никуда не перейдут.potan
24.10.2019 08:10К обсуждаемому в статье типу проектов эти аргументы не очень подходят. Особенно еслм вспомнить, что один из вариантов рассматривается питон.
Да и доверие к коду компилятора, написанного на Rust у меня больше, чем к коду компилятора, написанного на C/C++.
Ну и работы по формальной семантике языка Rust идут довально активно.CodeRush
24.10.2019 08:13Мы тут, мне кажется, уже перешли на обсуждение проектов вообще, а не только таких мелких, как в этой статье. Я согласен с тем, что там, где можно использовать Питон, Раст тоже отлично зайдет.
peacemakerv
23.10.2019 20:55Хорошая статья, для совсем начинающих.
Вопрос в тему выбора железа: а есть ли уже на рынке устройства на базе Android с аккумулятором, но без дисплея? Типа недотелефон.
Т.е. как HDMI-stick\dongle для телевизора, но с батареей (и может с камерой; конечно же, слот nanoSIM-карты (4G), WiFi (2.4 & 5 GHz) и BT4+ должны быть как обычно; OTG тоже явно полезный бонус; MicroHDMI для разработок и локального контроля, конечно нужен обязательно).
Суть в малогабаритности и небольшой автономности для работы в качестве контроллеров различной тематики.Dima_Sharihin
23.10.2019 21:01Но зачем там Android?
peacemakerv
23.10.2019 21:09Нааадо. IMHO, писать и обновлять софт для большинства из перечисленных интерфейсов одновременно — удобнее именно под Android. Но это хотя кто-что умеет.
p.s. я утверждаю не голословно, а потому, что сейчас эксплуатирую один образец подобного контроллера (уже 3ий месяц без выключения, когда-нибудь статью запилю по результатам) именно на базе стандартного андроидфона. Вот нужна бОльшая миниатюризация и удешевление бы, но не массовая.lelik363
23.10.2019 21:24Android, чтобы только обновляться по воздуху?
peacemakerv
23.10.2019 21:27Вопрос был не об этом, а все-таки с каким-то Андроид. Ну, чтобы писать софт под него, если умеешь.
brun4eg Автор
24.10.2019 10:17Основная проблема с андроидом в том, что вы почти ничего не контролируете в системе. Она ведёт себя непредсказуемо и этим нельзя управлять.
longtolik
24.10.2019 14:00Меня терзают смутные сомнения, что Андроид им нужен потому, что на нём легко запустить нейросеть, например, Tensor Flow Lite. Потом сделают срезы с видео про уставшего водителя, злого него же и т.д. Обучат сеть, и проект готов.
Тут я цветы распознавал: youtu.be/5EN-wQU7bxs, а они будут водителей.
ermakovd
24.10.2019 06:37+2ИМХО, при сравнении одноплатников большинство аргументов притянуты за уши. Реальная ситуация совсем другая. Местами с точностью до наоборот.
Выглядит так, как будто автору очень хотелось оправдать свой отказ от Малины.Londoner
24.10.2019 08:18Тогда интересно было бы взглянуть на Ваш собственный список плюсов и минусов. Напишете?
ermakovd
24.10.2019 21:32Много писать, к сожалению, некогда. Вот вам честный обзор: www.youtube.com/watch?v=XfM7hhwr6to
Отмечу следующие моменты:
— Нано Пи под нагрузкой потребляет (и рассеивает) больше четвёртой Малины (не говоря уже о третьей),
— в целом производительность прямо пропорциональна потребляемой мощности (также зависит от техпроцесса и оптимизации чипа, но не кардинально у сравнимых чипов),
— самое главное, использовать китайский процессор в разработке Яндекса — это, как минимум, нестандартно и смело (ни документации нормальной, ни поддержки, ни инструментов). Из перечисленных в статье, Малина, по крайней мере, вдоль и поперёк изучена. А вообще есть отладочные платы и на процессорах TI, NXP и на том же Qualcomm (DragonBoard).
Ну и да, Raspberry Pi 3 compute module 32Gb eMMC — ИМХО, неплохой вариант.
longtolik
24.10.2019 10:18Согласен с Вами.
Например, для Raspberry Pi Андроид есть: emteria.com (нашел с помощью Google :). Аргумент, что он — платный, не принимается, такая компания, как Яндекс, может и сама такие вещи делать, и продавать их.
Температура и eMMC — другое дело, но есть CM с параметрами
«The eMMC and LPDDR2 have the narrowest range, these are rated for -25 to +80 degrees Celsius. Therefore the nominal range for the CM3 and CM3L is -25C to +80C.»
С Raspberry Pi 3 A+ я имел дело на «голом железе», все 4 ядра работают отлично и параллельно, процессор не греется.
Еще пропущен, например, Asus Tinker S, у него есть фирменный Android.
C FriendlyARM я тоже дело имел (mini2440, mini210s, nanoPC-T1 — Samsung SBC фактически), у них тоже всё меньше «открытости».
Если уж «делать всё своими руками», то и плату свою делать, вместо всяких nanoPi neo.
А то получается, как в древнем анекдоте: «Арабская Республика Египет и Япония организовали совместное производство наручных часов. Электроника будет японская, а цифры — арабские».
В России есть компании, которые могут и плату изготовить с процессором и памятью, и Linux на нее поставить. (Применение Линукс еще то — лично я не люблю ждать несколько секунд, пока телевизор или еще какие устройства его загрузят). А для транспорта нужно вообще делать на ОСРВ).
Есть еще такое: www.sifive.com RISC-V потребляют ещё меньше энергии, чем ARM.
И есть с AI capabilities на чипе и с интерфейсом камеры, как раз, чтобы усталость определять чью-нибудь…brun4eg Автор
24.10.2019 10:29Ну одноплатных ПК много и ASUS мы тоже пробовали.
Главный недостаток Raspberry — отсутствие нормального накопителя для системы, всё остальное как-то решается (кроме минусовых температур). Да, 3 модель греется не так сильно, как 4-я, но и производительность там весьма средняя.
Всё, что мы использовали от FriendlyARM вполне открытое, понятное и есть все исходники, поэтому мне не вполне понятно, что именно там не очень открытое.longtolik
24.10.2019 11:29Вычислительный модуль подразумевался, с eMMC и от -25 до 80 градусов.
С 2011 года я с FriendlyARM (вот первый пост: www.friendlyarm.net/forum/topic/3018). Тогда с mini2440 присылали три (!) DVD со всевозможными исходными кодами. На их основе можно было сделать программу, например, для камеры, которая давала картинку через пару секунд после включения питания. Mini210s (она же SBC-210 от Samsung) уже была не совсем открыта. Для запуска своих программ нужно было использовать проприетарный .bin файл. Один из загрузчиков ещё Samsung так настроила, что он мог выполнять код второго загрузчика только с определенной контрольной суммой. Форум и поддержка зависли, на NanoPC-T1 я остановил своё общение с ними, да и другие пользователи тоже.
Это хорошо, что у Вас есть исходники и Вы довольны.
Я не хвалю ни Raspberry Pi, ни Asus Tinker S. У них — свои проблемы, но надо их использовать там, где они нужны.
Мне не свойственно «умничать», но если Вы ведете речь о приложении для распознавания усталости (или эмоций), то, на всякий случай, посмотрите ещё в сторону Maix Bit с его Kendryte K210. По ссылке youtu.be/R8EXgdUI194 можно сразу увидеть.
И ещё тут с Ардуино началось. А у него есть Arduino Vidor 4000. К нему подключается камера, на Github есть проекты с самодельными нейронами, также можно купить IP. Тогда бы получилась серьезная система распознавания, нейроморфная. Но — это дело будущего.
dim2r
24.10.2019 10:31Уважаемые, подскажите, есть ли модуль, который представляется, как usb клавиатура и который можно программировать, чтобы он выдавал последовательности символов?
Dima_Sharihin
24.10.2019 10:38Вообще есть модуль gadgetfs, который позволяет настраивать USB-контроллер на различные функции. В зависимости от конфига это будет Mass Storage Device, CDC-ACM, RNDIS, HID, или все вместе.
longtolik
24.10.2019 11:35Arduino Leonardo, или другие (есть в микроисполнении), на базе ATmega32u4.
При попадании в недобрые руки, такое устройство может принести немало проблем владельцу компьютера, в который он будет вставлен.
romanetz_omsk
24.10.2019 13:14На платке blue pill и фреймворке stm32cube такая штука делается недорого и довольно быстро (есть положительный опыт с имитацией hid-устройства и режимом usb passthrough на stm32f407)
DmitrySpb79
24.10.2019 11:44Спасибо за текст.
Удалось ли решить проблему с надежностью записи, насколько eMMC в этом плане лучше обычных SD-карт? Не раз слышал что стандартные карты помирают через год эксплуатации.
crustal
24.10.2019 20:24+1«Мiй продакшн виробляе контент виключно украiнською мовою. Онли ориджинал продакт, хэндмэйд» — тащусь с этого братско-хохляцкого видоса от Дизель шоу www.youtube.com/watch?v=ukonBMs0WM0
Респект автору, он почти переплюнул того гика из этого видоса по объему гик-сленга. Я так думаю, все это для того, чтобы убедить как минимум самого себя, что бабки были потрачены все-таки не зря. Ну не прототип это ни разу, а как он мудро заметил в самом начале статьи все тот же proof of concept.
Ничего из этого прототипа не идет в «продакшн», кроме концепции алгоритма, ну может быть каких-то фрагментов кода под линукс. Ни веб камера, а чистый сенсор с интерфейсом DCMI в связке с микроконтроллером, к примеру какой-нибудь STM32H7 (AN5020 Digital camera interface (DCMI) for STM32 MCUs), никаких PI, никаких питонов, вообще ничего, кроме какой-то идеи алгоритма.
На эти неслабые деньги покататься туда-сюда вокруг земного шара плюс скупить сотню другую всяких PI и других железяк вполне можно было бы купить много портативных PC в автомобильном исполнении, прикрути где-нибудь там в авто, где не мешает и проверяй концепцию пока не надоест.
Pilat
Очень хорошая и полезная статья.
Дополнение по процессорным платам. В семействе NanoPI NEO есть NanoPI NEO Core и NanoPI NEO Core2 — те же NEO, но БЕЗ распаянных разъёмов ethernet, USB и т.д. — только USB питания и SDCARD (которая может и не нужна так как есть EMMC) плюс у них расширенный диапазон по температурам.
lelik363
Статья так себе. Те сроки(3-8 недель до получения прототипа), могли бы быть указаны для того класса устройств, про которые говорил спикер.
О чём говорить, если компоненты на более или менее сложную плату поставляются 8-12 недель?
MinimumLaw
Накинулись на Вас. По мне напрасно накинулись. Увы, реали таковы что часть комплектующих иногда приходится ждать и пол года. Такова она — доля разработчиков реальных железок. И конечно, этот прискорбный факт отодвигает момент получения прототипа.
С другой стороны, ведь Вы и Yandex под прототипом понимаете разные вещи. С позиции автора статьи — прототип это железка, позволяющая начать реализовывать и отлаживать ПО. При чем по большей части прикладное. Для Вас прототип — это первая (если хотите отладочная) плата. По сути и то и другое можно назвать прототипом.
Впрочем, согласен. Из статьи разница между EVT, DVT и PVT совершенна не очевидна. Или слишком сложно, или слишком просто — но в любом случае оставляет очень много простора для домыслов. И еще — никто ведь не говорит, что не может быть, допустим, DVT rev1, rev2, revN. Разработка (особенно связанная с железом) — это не производство по готовой документации. Мало что удается сделать с первой попытки.
lelik363
Благодарю за поддержку.
Я не зря акцентировал внимание на уровне сложности изделия. Автор доклада взялся рассуждать об абстрактном проекте, а не частном (своем случае).
В качестве примера я закупку компонентов — это самый очевидный пример того, где можно потерять много времени. Закупить ВОМ в состав, которого входит около сотни наименований, что выливается 1000-1500 компонентов (одна плата) очень не простое дело. Так что я категорический не согласен с теми сроками разработки и внедрения, которые указаны в презентации.
MinimumLaw
Ну что тут скажешь, кроме очевидного — сроки сильно зависят от сложности. И есть единственный вариант их сокращать — как можно больше частей проекта выполнять параллельно. Пока схемотехники «колдуют» со схемой и платой системщики готовят загрузчики и системы на близкой к проекту отладке а прикладники пишут и отлаживают прикладное ПО на обычных ПК. Потом все собирается вместе. Впрочем, это вполне обычный путь любой разработки.
Но посыл Ваш абсолютно правильный. Не при каких обстоятельствах нельзя называть конкретные сроки для абстрактного проекта. Впрочем, думаю что автор статьи это тоже прекрасно понимает.
lelik363
Почему это плохо? Такие посылы приводят к ложным надеждам неискушённых заказчиков.
checkpoint
Подолью маслица…
Автор статьи делает допущение, что у него получается рабочий прототип с первой попытки. Мой, уже почти 10-ти летний, опыт разработки электроники показывает, что ни с первого, ни даже со второго раза рабочей платы уровня сложности RaspPI не получить! А на каждую итерацию требуется не менее месяца, это при условии что все необходимые компоненты уже лежат на полках и у вас есть свободный доступ к сборочному автомату. 7-8 месяцев на прототип железа — более реальный срок. Добавьте сюда еще столько же на написание софта и получите год-полтора на разработку изделия. Запуск в серию — тоже отдельная тема. Пока не попробуешь несколько производителей — не поймешь с кем работать (у каждого производства свои тонкости и требования). А это время, деньги и еще раз время.
Ну и про разводку DDR3 автор как-то не упомянул совсем, а на этой теме можно буксовать бесконечно долго.
Разработка прототипа корпуса с помощью 3D печати это конечно чудесно. Но находится несколько перпендикулярно промышленному подходу, где все производится либо методом фрезерования (мелкие серии), либо литьем с последующей машинной обработкой. Иными словами — это лишний бесполезный труд.
MinimumLaw
Ну что Вам ответить? Еще через 5 лет платы класса Raspberry будут уверенно получаться со второй попытки, а через 10 с первой. Опыт
, как и половое бессилие,приходит с годами. Я прекрасно помню времена развесных 1533/1554, казавшиеся невозможными технологии позволяющие провести аж два печатных проводника между их выводами и казавшийся высокочастотным сигнал в целых 4.096МГц.И трассировка DDR2/3/4 — далеко не самая страшная часть. Я больше скажу — грамотная трассировка питания, особенно в современных процессорных системах, пожалуй посложнее будет. Ну, или по крайней мере не проще. Просто DDR на слуху. Сегодня это своего рода пугалка про «черную-черную комнату». А граблей везде накидано — только успевай уворачиваться.
Про корпус на принтере. Да нет, не лишний шаг. Наоборот. Возможность быстро пощупать. А за одно хорошее подспорье технологу. Живой корпус и чертеж всегда лучше, чем просто чертеж. Так что абсолютно точно не лишний и бесполезный труд.