Комментарии 149
Очень хорошая и полезная статья.
Дополнение по процессорным платам. В семействе NanoPI NEO есть NanoPI NEO Core и NanoPI NEO Core2 — те же NEO, но БЕЗ распаянных разъёмов ethernet, USB и т.д. — только USB питания и SDCARD (которая может и не нужна так как есть EMMC) плюс у них расширенный диапазон по температурам.
Дополнение по процессорным платам. В семействе NanoPI NEO есть NanoPI NEO Core и NanoPI NEO Core2 — те же NEO, но БЕЗ распаянных разъёмов ethernet, USB и т.д. — только USB питания и SDCARD (которая может и не нужна так как есть EMMC) плюс у них расширенный диапазон по температурам.
Очень хорошая и полезная статья.
Статья так себе. Те сроки(3-8 недель до получения прототипа), могли бы быть указаны для того класса устройств, про которые говорил спикер.
Давайте посмотрим, как же делаются устройства, прежде чем дойти до прототипов, потому что это многое определяет. Это абстрактный проект, он не привязан к каким-то конкретным обстоятельствам, я привожу его просто для примера.
О чём говорить, если компоненты на более или менее сложную плату поставляются 8-12 недель?
компоненты на более или менее сложную плату поставляются 8-12 недель
Накинулись на Вас. По мне напрасно накинулись. Увы, реали таковы что часть комплектующих иногда приходится ждать и пол года. Такова она — доля разработчиков реальных железок. И конечно, этот прискорбный факт отодвигает момент получения прототипа.
С другой стороны, ведь Вы и Yandex под прототипом понимаете разные вещи. С позиции автора статьи — прототип это железка, позволяющая начать реализовывать и отлаживать ПО. При чем по большей части прикладное. Для Вас прототип — это первая (если хотите отладочная) плата. По сути и то и другое можно назвать прототипом.
Впрочем, согласен. Из статьи разница между EVT, DVT и PVT совершенна не очевидна. Или слишком сложно, или слишком просто — но в любом случае оставляет очень много простора для домыслов. И еще — никто ведь не говорит, что не может быть, допустим, DVT rev1, rev2, revN. Разработка (особенно связанная с железом) — это не производство по готовой документации. Мало что удается сделать с первой попытки.
Благодарю за поддержку.
Я не зря акцентировал внимание на уровне сложности изделия. Автор доклада взялся рассуждать об абстрактном проекте, а не частном (своем случае).
В качестве примера я закупку компонентов — это самый очевидный пример того, где можно потерять много времени. Закупить ВОМ в состав, которого входит около сотни наименований, что выливается 1000-1500 компонентов (одна плата) очень не простое дело. Так что я категорический не согласен с теми сроками разработки и внедрения, которые указаны в презентации.
Я не зря акцентировал внимание на уровне сложности изделия. Автор доклада взялся рассуждать об абстрактном проекте, а не частном (своем случае).
В качестве примера я закупку компонентов — это самый очевидный пример того, где можно потерять много времени. Закупить ВОМ в состав, которого входит около сотни наименований, что выливается 1000-1500 компонентов (одна плата) очень не простое дело. Так что я категорический не согласен с теми сроками разработки и внедрения, которые указаны в презентации.
Ну что тут скажешь, кроме очевидного — сроки сильно зависят от сложности. И есть единственный вариант их сокращать — как можно больше частей проекта выполнять параллельно. Пока схемотехники «колдуют» со схемой и платой системщики готовят загрузчики и системы на близкой к проекту отладке а прикладники пишут и отлаживают прикладное ПО на обычных ПК. Потом все собирается вместе. Впрочем, это вполне обычный путь любой разработки.
Но посыл Ваш абсолютно правильный. Не при каких обстоятельствах нельзя называть конкретные сроки для абстрактного проекта. Впрочем, думаю что автор статьи это тоже прекрасно понимает.
Но посыл Ваш абсолютно правильный. Не при каких обстоятельствах нельзя называть конкретные сроки для абстрактного проекта. Впрочем, думаю что автор статьи это тоже прекрасно понимает.
Подолью маслица…
Автор статьи делает допущение, что у него получается рабочий прототип с первой попытки. Мой, уже почти 10-ти летний, опыт разработки электроники показывает, что ни с первого, ни даже со второго раза рабочей платы уровня сложности RaspPI не получить! А на каждую итерацию требуется не менее месяца, это при условии что все необходимые компоненты уже лежат на полках и у вас есть свободный доступ к сборочному автомату. 7-8 месяцев на прототип железа — более реальный срок. Добавьте сюда еще столько же на написание софта и получите год-полтора на разработку изделия. Запуск в серию — тоже отдельная тема. Пока не попробуешь несколько производителей — не поймешь с кем работать (у каждого производства свои тонкости и требования). А это время, деньги и еще раз время.
Ну и про разводку DDR3 автор как-то не упомянул совсем, а на этой теме можно буксовать бесконечно долго.
Разработка прототипа корпуса с помощью 3D печати это конечно чудесно. Но находится несколько перпендикулярно промышленному подходу, где все производится либо методом фрезерования (мелкие серии), либо литьем с последующей машинной обработкой. Иными словами — это лишний бесполезный труд.
Автор статьи делает допущение, что у него получается рабочий прототип с первой попытки. Мой, уже почти 10-ти летний, опыт разработки электроники показывает, что ни с первого, ни даже со второго раза рабочей платы уровня сложности RaspPI не получить! А на каждую итерацию требуется не менее месяца, это при условии что все необходимые компоненты уже лежат на полках и у вас есть свободный доступ к сборочному автомату. 7-8 месяцев на прототип железа — более реальный срок. Добавьте сюда еще столько же на написание софта и получите год-полтора на разработку изделия. Запуск в серию — тоже отдельная тема. Пока не попробуешь несколько производителей — не поймешь с кем работать (у каждого производства свои тонкости и требования). А это время, деньги и еще раз время.
Ну и про разводку DDR3 автор как-то не упомянул совсем, а на этой теме можно буксовать бесконечно долго.
Разработка прототипа корпуса с помощью 3D печати это конечно чудесно. Но находится несколько перпендикулярно промышленному подходу, где все производится либо методом фрезерования (мелкие серии), либо литьем с последующей машинной обработкой. Иными словами — это лишний бесполезный труд.
Ну что Вам ответить? Еще через 5 лет платы класса Raspberry будут уверенно получаться со второй попытки, а через 10 с первой. Опыт, как и половое бессилие, приходит с годами. Я прекрасно помню времена развесных 1533/1554, казавшиеся невозможными технологии позволяющие провести аж два печатных проводника между их выводами и казавшийся высокочастотным сигнал в целых 4.096МГц.
И трассировка DDR2/3/4 — далеко не самая страшная часть. Я больше скажу — грамотная трассировка питания, особенно в современных процессорных системах, пожалуй посложнее будет. Ну, или по крайней мере не проще. Просто DDR на слуху. Сегодня это своего рода пугалка про «черную-черную комнату». А граблей везде накидано — только успевай уворачиваться.
Про корпус на принтере. Да нет, не лишний шаг. Наоборот. Возможность быстро пощупать. А за одно хорошее подспорье технологу. Живой корпус и чертеж всегда лучше, чем просто чертеж. Так что абсолютно точно не лишний и бесполезный труд.
И трассировка DDR2/3/4 — далеко не самая страшная часть. Я больше скажу — грамотная трассировка питания, особенно в современных процессорных системах, пожалуй посложнее будет. Ну, или по крайней мере не проще. Просто DDR на слуху. Сегодня это своего рода пугалка про «черную-черную комнату». А граблей везде накидано — только успевай уворачиваться.
Про корпус на принтере. Да нет, не лишний шаг. Наоборот. Возможность быстро пощупать. А за одно хорошее подспорье технологу. Живой корпус и чертеж всегда лучше, чем просто чертеж. Так что абсолютно точно не лишний и бесполезный труд.
Хорошо написано. Не поспоришь.
Но не кажется Вам, что процесс разработки крайне сложно поддается алгоритмизации? Не все можно отмакетировать на коммерческих платах. Не всегда стоит думать о массовом производстве (уже не говоря о том, что массовое производство у каждой компании разное). Более того, в подавляющем большинстве случаев, если это можно отмакетировать на RaspberryPI или ее аналогах, то это можно и на обычном ПК. При этом на ПК удобнее и пользы будет сильно больше.
И, раз уж у Вас есть время писать статьи — можно просьбу. Доведите до широкой публики подводные камни разных накопителецй информации. Serial/Parallel Flash (NOR/NAND), QSPI Flash, (e)MMC/SecureDigital, (m)SATA. А то надоело каждый раз рассказывать одно и тоже. А сам не напишу.
Это все Вам не в упрек, а просто мысли от человека который всю жизнь занимался разработкой в разных компаниях. И, безусловно, основные мысли абсолютно правильны и справедливы.
Но не кажется Вам, что процесс разработки крайне сложно поддается алгоритмизации? Не все можно отмакетировать на коммерческих платах. Не всегда стоит думать о массовом производстве (уже не говоря о том, что массовое производство у каждой компании разное). Более того, в подавляющем большинстве случаев, если это можно отмакетировать на RaspberryPI или ее аналогах, то это можно и на обычном ПК. При этом на ПК удобнее и пользы будет сильно больше.
И, раз уж у Вас есть время писать статьи — можно просьбу. Доведите до широкой публики подводные камни разных накопителецй информации. Serial/Parallel Flash (NOR/NAND), QSPI Flash, (e)MMC/SecureDigital, (m)SATA. А то надоело каждый раз рассказывать одно и тоже. А сам не напишу.
Это все Вам не в упрек, а просто мысли от человека который всю жизнь занимался разработкой в разных компаниях. И, безусловно, основные мысли абсолютно правильны и справедливы.
Прототипировать надо на железе, по возможностям близком к финальному варианту, а не на том, где ядер больше и eMMC быстрее.
Даже если брать только линукс-совместимые микрокомпьютеры — разработчики, писавшие прототип на «четыре гига, четыре ядра», могут быть немного удивлены, в реальной железке встретив какую-нибудь Ситару на одном Cortex-A8 с 256М ОЗУ и 32M NAND-флэш.
Даже если брать только линукс-совместимые микрокомпьютеры — разработчики, писавшие прототип на «четыре гига, четыре ядра», могут быть немного удивлены, в реальной железке встретив какую-нибудь Ситару на одном Cortex-A8 с 256М ОЗУ и 32M NAND-флэш.
Крайне дискуссионный момент.
С одной стороны — безусловно. Если конечное изделие будет крайне ограничено в ресурсах, то чем быстрее эти ограничения станут очевидными тем лучше.
С другой стороны есть вопрос удобства отладки как ПО, так и взаимодействия с окружающим миром. Все же внутрисхемная отладка — это скорее прерогатива системщиков. А подавляющее большинство кода так или иначе пишется прикладниками. Особенно это касается сложных решений. Там системная составляющая сильно меньше прикладной. Опять же — нельзя впадать в крайности. А то прецеденты запуска PostgreSQL сервера c NAND & UBIFS конечно были. И это даже работало, но… По вполне понятным причинам ни на одном собеседовании я не стану упоминать об этом решении.
Подводя некую черту могу заметить что прототип и конечное изделие не обязаны быть максимально похожими. Это разные стадии проектирования с разными задачами. Однако, если всех заинтересованных устраивает прототип близкий к финальному изделию — то это один из лучших вариантов.
С одной стороны — безусловно. Если конечное изделие будет крайне ограничено в ресурсах, то чем быстрее эти ограничения станут очевидными тем лучше.
С другой стороны есть вопрос удобства отладки как ПО, так и взаимодействия с окружающим миром. Все же внутрисхемная отладка — это скорее прерогатива системщиков. А подавляющее большинство кода так или иначе пишется прикладниками. Особенно это касается сложных решений. Там системная составляющая сильно меньше прикладной. Опять же — нельзя впадать в крайности. А то прецеденты запуска PostgreSQL сервера c NAND & UBIFS конечно были. И это даже работало, но… По вполне понятным причинам ни на одном собеседовании я не стану упоминать об этом решении.
Подводя некую черту могу заметить что прототип и конечное изделие не обязаны быть максимально похожими. Это разные стадии проектирования с разными задачами. Однако, если всех заинтересованных устраивает прототип близкий к финальному изделию — то это один из лучших вариантов.
А то прецеденты запуска PostgreSQL сервера c NAND & UBIFS конечно были. И это даже работало, но… По вполне понятным причинам ни на одном собеседовании я не стану упоминать об этом решении
Три четверти таких прецедентов случаются потому, что разработчики софта, которым дали «прототип» на NanoPi M4, совершенно искренне не представляли себе не только что в железке будет AM3358, но что вообще AM3358 существует в природе и кому-то нужен. А уж тем более — что это ещё и довольно мощный процессор, будете выпендриваться, в следующий раз AR9331 дадим.
И это касается всего, от объёмов памяти до скоростей каналов связи.
И с микроконтроллерами то же самое — я себя регулярно бью по рукам, когда на nRF52 перестаю считать память, потому что её там Очень Много (целых 64 КБ, это реально много же), и более чем насмотрелся на университетские проекты (а это изрядная часть микроконтроллерного опенсорса), сделанные в условиях университетских же лабораторий, где база — это отладки на старших моделях процессоров, на которых лишний десяток килобайт ОЗУ никто не замечает.
Ну, в моем случае это была необходимость сменить платформу с x86 на ARM при этом сохранив и минимально модернизировав все наработки. Ибо проект делался чуть-ли не подпольно, преодолевая сопротивление всех структур каких только можно. В итоге мы сделали это. Просто показав, что это можно сделать. Увы, этот проект именно в таком виде ушел в продакшн. Ибо автономность (энергоэффективность) ARM в сравнении с тогдашними встраиваемыми 586/686'ми на наших задачах была просто космической. К счастью, сегодня он практически полностью выведен из эксплуатации. Хотя увы, местами еще работает.
И все же мы были одними из первых кто начал жить на ARM и Linux. Для понимания — это был период еще Intel PXA255, телефоны на котором едва работали на Windows Mobile и только некоторым гикам удалось запустить на Palm Tungsten T5 вполне себе живой Linux (и то без всяких U-Boot и прочего). Андроид если и был, то в зачаточном состоянии.
Но к чему я все это? Да все к тому же. Вечный спор с прикладниками. Их позиция «сегодня ресурсов мало — завтра поставят достаточно» вполне оправдана. Чего уж там. Прогресс на месте не стоит. Но к счастью и нашу позицию «какая бы не была производительная система подавляющее большинство времени она должна спать и экономит батарею» пусть и с трудом, но находит отклик. И это правильно. Именно этот конфликт и позволяет изделиям развиваться.
И все же мы были одними из первых кто начал жить на ARM и Linux. Для понимания — это был период еще Intel PXA255, телефоны на котором едва работали на Windows Mobile и только некоторым гикам удалось запустить на Palm Tungsten T5 вполне себе живой Linux (и то без всяких U-Boot и прочего). Андроид если и был, то в зачаточном состоянии.
Но к чему я все это? Да все к тому же. Вечный спор с прикладниками. Их позиция «сегодня ресурсов мало — завтра поставят достаточно» вполне оправдана. Чего уж там. Прогресс на месте не стоит. Но к счастью и нашу позицию «какая бы не была производительная система подавляющее большинство времени она должна спать и экономит батарею» пусть и с трудом, но находит отклик. И это правильно. Именно этот конфликт и позволяет изделиям развиваться.
Их позиция «сегодня ресурсов мало — завтра поставят достаточно» вполне оправдана
Не, если продукт надо выпускать не сегодня, а когда-нибудь там в будущем, когда ресурсов подвезут, не вопрос.
Но реальность обычно жёстче. И в реальности после прототипирования софта на больших, жирных, привычных программистам-прикладникам системах его регулярно приходится дальше попросту переписывать. Я не только про память или число ядер, я, например, знаю случаи, когда люди в софте закладывались на получение данных с внешних объектов в реальном времени — искренне не понимая, что прописанный в ТЗ LoRaWAN так вообще не работает. Или, например, на то, что обычный GPS им в реальной жизни даст погрешность ±2 метра. Или что в устройство размером с половину пачки сигарет можно поставить старший микроконтроллер, который будет непрерывно молотить нейросетку на потоке данных с гироакселерометра — и при этом жить неделю на одной зарядке.
Поэтому прототипирование должно делаться так, чтобы прикладники изначально были зажаты в тиски будущих ограничений.
Вы напрасно думаете, что я выступаю Вашим alter-ego. Это не совсем так, если не сказать совсем не так. Я всячески стараюсь избегать «политических» вопросов. Не дело инженера решать их и давать какие-то рекомендации заказчику. Его дело довести объективную картинку. Обрисовать все сложности. Даже если из-за этого будет потерян заказ. Да, возможно я и не прав. Но строго IMHO — лучше потерять заказ, чем репутацию специалиста.
А теперь давайте вернемся к исходным предпосылкам. Смотрите — вы, как автор, знаете возможности Вашего изделия. И дальше Ваше с заказчиком совместное решение — или Вы делаете его целиком сами (что неизбежно увеличит сроки) или бьете задачу на части. Задираете себе схемотехнику, системную и драйверную часть и отдаете прикладную на откуп спецам заказчика. Это позволит сократить сроки получения готового изделия. Особенно если Вы сможете выдать прикладникам эмуляторы изделия (тот самый эмулятор LoRaWAN или трек с реального GPS). И, конечно, обговорите метрики производительности. В первом приближении аналогом современных ARM'ов вполне могут стать старые нетбуки c N270 атомом. Это и только это позволит избежать описываемых Вами проблем.
И еще раз — конечно, прототип с железкой близкой к реальной — это лучший вариант. Я нигде и никогда другого и не писал. Я писал только то, что далеко не всех такой вариант устроит. Хотя бы потому, что грамотно настроить систему кросс-сборки это тоже время, а собирать нативно на не блещущем производительностью ARM'е с ограниченной по размеру RAM — то еще удовольствие.
А теперь давайте вернемся к исходным предпосылкам. Смотрите — вы, как автор, знаете возможности Вашего изделия. И дальше Ваше с заказчиком совместное решение — или Вы делаете его целиком сами (что неизбежно увеличит сроки) или бьете задачу на части. Задираете себе схемотехнику, системную и драйверную часть и отдаете прикладную на откуп спецам заказчика. Это позволит сократить сроки получения готового изделия. Особенно если Вы сможете выдать прикладникам эмуляторы изделия (тот самый эмулятор LoRaWAN или трек с реального GPS). И, конечно, обговорите метрики производительности. В первом приближении аналогом современных ARM'ов вполне могут стать старые нетбуки c N270 атомом. Это и только это позволит избежать описываемых Вами проблем.
И еще раз — конечно, прототип с железкой близкой к реальной — это лучший вариант. Я нигде и никогда другого и не писал. Я писал только то, что далеко не всех такой вариант устроит. Хотя бы потому, что грамотно настроить систему кросс-сборки это тоже время, а собирать нативно на не блещущем производительностью ARM'е с ограниченной по размеру RAM — то еще удовольствие.
Вы правда считаете, что подготовка реалистичного симулятора радиосети или данных GPS займёт у вас меньше времени, что настройка среды сборки под ARM?..
Еще раз — я не знаю Вашей кухни. Но GPS можно подключить и на прямую. При некоторой сноровке и радиоканал тоже. Если Вы постоянно работаете с этими интерфейсами, то возможно проще раз сделать оснастку, чем из раза в раз воевать за производительность.
целых 64 КБ, это реально много же
Боюсь, далеко не всем будет понятно НАСКОЛЬКО это много. Впрочем, оставлять неиспользованной встроенную SRAM… По мне за это отдельный котел приготовлен. Это ж какой нереализованный простор для оптимизации производительности.
И насколько это мало, если у микроконтроллера куча дуплексных TCP-сокетов и 100мбит ethernet под боком
Можно я не буду задавать Вам вопрос почему реализация задачи обмена данными через кучу TCP-сокетов на 100BASE-T поручена микроконтроллеру с 64Кб ОЗУ и боюсь спросит какой тактовой частотой?
Но вы его задали :3
Тактовая была довольно обычная, 120 МГц. Оперативки было тоже поболее, 256 кило. А так — мост TCP-UART в количестве восьми штук на одну микросхему.
Внезапно оказывается, что без zero-copy и ручной работы "где-то на нижем уровне" эффективно эту задачу не решить. Тот же POSIX-совместимый NuttX на этом уже захлебывался от пребывающих пакетов, а lwip с raw-api вполне себе работает
Но могли бы не отвечать :3
Не знаю. Смотрите, пусть скорость не большая. Этак 115200 на хвост. Будем грубо считать 10KiB в секунду на направление. Интерфейс дуплексный — значит 20KiB в секунду, да на 8 интерфейсов — это в пике 160KiB в секунду только на полезных данных. По сети. Если не резать MTU (а это 4KiB) то 4*8*2=64KiB только для сетевых буферов. А их еще по памяти и между памятью и периферией гонять надо. Вот и получается что ресурсов-то не много. Сильно не разгуляешься. Так что вполне очевидно, что без «ручной настройки» не обойдется.
Впрочем, не сказал бы что задача не решаемая. Вполне себе эпизод из жизни разработчиков подобной аппаратуры. Правда вот необходимость именно TCP меня как-то немного подгладывает. Впрочем, если это было в ТЗ, то с ТЗ, как известно, не спорят.
Не знаю. Смотрите, пусть скорость не большая. Этак 115200 на хвост. Будем грубо считать 10KiB в секунду на направление. Интерфейс дуплексный — значит 20KiB в секунду, да на 8 интерфейсов — это в пике 160KiB в секунду только на полезных данных. По сети. Если не резать MTU (а это 4KiB) то 4*8*2=64KiB только для сетевых буферов. А их еще по памяти и между памятью и периферией гонять надо. Вот и получается что ресурсов-то не много. Сильно не разгуляешься. Так что вполне очевидно, что без «ручной настройки» не обойдется.
Впрочем, не сказал бы что задача не решаемая. Вполне себе эпизод из жизни разработчиков подобной аппаратуры. Правда вот необходимость именно TCP меня как-то немного подгладывает. Впрочем, если это было в ТЗ, то с ТЗ, как известно, не спорят.
У нас единая программная платформа на STM32L0/STM32L1/STM32F0/STM32L4/nRF52, с требованием, что в рамках понятных аппаратных ограничений с точки зрения прикладной части прошивки она должна на этом всём работать одинаково.
Работая на двух последних, надо очень чётко помнить, где ты правишь код, который нужен только вот в этом конкретном проекте, а где ты в общеплатформенных вещах начал плодить треды со стеками по несколько килобайт, потому что «ну ещё дофига памяти же».
Ибо завтра кому-то, возможно, тебе же, эти же вещи потребуется на STM32F030 запускать.
Работая на двух последних, надо очень чётко помнить, где ты правишь код, который нужен только вот в этом конкретном проекте, а где ты в общеплатформенных вещах начал плодить треды со стеками по несколько килобайт, потому что «ну ещё дофига памяти же».
Ибо завтра кому-то, возможно, тебе же, эти же вещи потребуется на STM32F030 запускать.
Когда компания делает примерно похожие устройства — вполне возможно, в одной из предыдущих компаний, где работал, вообще не заморачивались, ставили один процессор почти во всю номенклатуру, цена комплектухи растворилась в конечном изделии
В каждой избушке свои погремушки. И не мне кого-то чему-то учить. Все же в мире встраиваемых систем программирование пока (к счастью) остается искусством.
Однако (чисто на вскидку) я бы поразмыслил на тему выделения критичных к производительности функций в отдельную секцию. И размещал эту секцию либо в RAM (минимизация задержек на считывание и выполнение инструкция) либо во FLASH если RAM мало. Linker script все равно у каждого проекта свой.
Ну, и про унификацию ниже правильно написано. Тут правда вопрос — что первично, а что вторично. Если первичен премиум, а бюджет — это для самых бедных и жадных, то есть смысл унифицироваться. Если наоборот — то надо думать.
Но еще раз — я Вашей кухни не знаю. Потому это просто иллюстрация к сказанному.
Однако (чисто на вскидку) я бы поразмыслил на тему выделения критичных к производительности функций в отдельную секцию. И размещал эту секцию либо в RAM (минимизация задержек на считывание и выполнение инструкция) либо во FLASH если RAM мало. Linker script все равно у каждого проекта свой.
Ну, и про унификацию ниже правильно написано. Тут правда вопрос — что первично, а что вторично. Если первичен премиум, а бюджет — это для самых бедных и жадных, то есть смысл унифицироваться. Если наоборот — то надо думать.
Но еще раз — я Вашей кухни не знаю. Потому это просто иллюстрация к сказанному.
Любопытно, а если не C/C++/Python, а Go?
Если ресурсы позволяют — то что угодно. JAVA, C#, Go. Нет проблем. Кроме, ресурсов, конечно. Ну, пожалуй еще вопросы правильного питания и охлаждения всегда актуальны. А так даже OpenCL/OpenGL не самые редкие гости в современных встраиваемых системах.
Я понимаю, что можно. Вопрос больше на тему – кто пробовал, какие результаты. На сколько хуже по производительности по сравнению с тем же С++?
Боюсь что конкретного ответа Вы не дождетесь. Все же в мире встраиваемых систем это экзотика. Мое персональное мнение — не стоит. Если только задача не заточена четко под Go. Да и в этом случае я бы подумал.
Понимаете тут все довольно человеко-ориентировано. Допустим Ваша задача решена на Go и необходима строго ее мобильная версия. Тогда можно думать в таком ключе. Но если задачу еще только предстоит решить, то с учетом ограниченности ресурсов (а уж поверьте, их всегда и всем мало) лучше брать более низкоуровневые языки. Даже больше — если можно обойтись без плюсов, лучше обходиться. Выкидывать все новомодные штучки и вспоминать о такой замечательной вещи как Unix-way.
Впрочем, python прополз и в этот мир. Думаю, что рано или поздно прикладники и здесь начнут диктовать свои условия. Потенциально даже исключать системщиков как лишнее звено между собой и схемотехниками. Во всяком случае есть некоторые сигналы, говорящие о том что такой расклад совсем не выглядит «страшной сказкой на ночь».
Но это позже. А пока разве что Rust способен что-то противопоставить C и C++. Но, «поверьте, здесь не все так однозначно» (с) Впрочем, темой Rust я с подачи Habr'а сам только недавно озадачился. Пока считаю что нет смысла писать на Rust как на C, когда есть непосредственно С. Впрочем, когда-то я тоже самое говорил про ассемблер. Потому ограничусь тем, что "… но это не точно" (с)
Понимаете тут все довольно человеко-ориентировано. Допустим Ваша задача решена на Go и необходима строго ее мобильная версия. Тогда можно думать в таком ключе. Но если задачу еще только предстоит решить, то с учетом ограниченности ресурсов (а уж поверьте, их всегда и всем мало) лучше брать более низкоуровневые языки. Даже больше — если можно обойтись без плюсов, лучше обходиться. Выкидывать все новомодные штучки и вспоминать о такой замечательной вещи как Unix-way.
Впрочем, python прополз и в этот мир. Думаю, что рано или поздно прикладники и здесь начнут диктовать свои условия. Потенциально даже исключать системщиков как лишнее звено между собой и схемотехниками. Во всяком случае есть некоторые сигналы, говорящие о том что такой расклад совсем не выглядит «страшной сказкой на ночь».
Но это позже. А пока разве что Rust способен что-то противопоставить C и C++. Но, «поверьте, здесь не все так однозначно» (с) Впрочем, темой Rust я с подачи Habr'а сам только недавно озадачился. Пока считаю что нет смысла писать на Rust как на C, когда есть непосредственно С. Впрочем, когда-то я тоже самое говорил про ассемблер. Потому ограничусь тем, что "… но это не точно" (с)
python прополз и в этот мир
Не вижу ничего плохого в плюсософте в эмбеддеде, но python — это +30мегабайт к размеру дистрибьютива.
Если нужны тысячи мелких скриптов, то на это дело есть lua, как в OpenWRT. Если сильно повезет, и у вас платформа — ARM, то даже с LuaJIT
Если бы я мог себя клонировать раз хотя бы 30 — то весь системный код был бы написан на MISRA C, а GUI на QT. Но увы, у отдела прикладников свои взгляды на целесообразность тех или иных инструментов. К счастью, конкретно в моих изделиях +30MiB далеко не самое страшное.
А как MISRA-C сочетается с пингвином? Она же запрещает половину POSIX-стиля.
Разве что в гетерогенной системе вторую прошивку делать мисрой
Давайте я сразу обозначусь — все что ниже это мое персональное мнение. Жестко по MISRA у меня сертифицировалось всего пара проектов, и те по голому железу. Потому применительно к Linux у меня нет практического опыта, а есть только размышления.
И так — в принципе вполне. Если впадать в крайности и будет требоваться жесткое соответствие исходников MISRA, то это реализуемо. Другое дело, что разумнее конечно относиться к MISRA не как к ограничивающему стандарту, а как к «правилам хорошего тона».
В микроконтроллерной среде у этих рекомендаций, конечно, больше шансов, чем под операционной системой. Но даже там — если заказчик жестко не требует, то я для улучшения читаемости и сопровождаемости кода я в целом ряде случаев отступаю от требований. Они все же во главу угла ставят надежность. Для того и создавались. Временами разумнее плюнуть на надежность там, где и без MISRA уверен в результате, но написать понятный код. Это работает надежнее, чем комментарий на две страницы.
Но в целом рекомендации очень толковые. И как минимум один проект целиком и полностью по ним стоит сделать.
И так — в принципе вполне. Если впадать в крайности и будет требоваться жесткое соответствие исходников MISRA, то это реализуемо. Другое дело, что разумнее конечно относиться к MISRA не как к ограничивающему стандарту, а как к «правилам хорошего тона».
В микроконтроллерной среде у этих рекомендаций, конечно, больше шансов, чем под операционной системой. Но даже там — если заказчик жестко не требует, то я для улучшения читаемости и сопровождаемости кода я в целом ряде случаев отступаю от требований. Они все же во главу угла ставят надежность. Для того и создавались. Временами разумнее плюнуть на надежность там, где и без MISRA уверен в результате, но написать понятный код. Это работает надежнее, чем комментарий на две страницы.
Но в целом рекомендации очень толковые. И как минимум один проект целиком и полностью по ним стоит сделать.
А как MISRA-C сочетается с пингвином?
Да никак, наверное. Дело в том, что мизра заточена прежде всего на риал-тайм и детерминизм исполняемого кода. Об этом свидетельствует, например, прямой запрет на динамическое выделение памяти и рекурсивные функции — т. е. те вещи, что порядочный разработчик и так в данном случае использовать не будет. Тем более в этом случае в железяке нет места Линуксу.
Думаю, что рано или поздно прикладники и здесь начнут диктовать свои условия. Потенциально даже исключать системщиков как лишнее звено между собой и схемотехниками.Ну да. А потом — «Нафаняааа!» в ночь перед сдачей :)))
Профессиональная гордость — это хорошо. Безусловно, по крутости с системщиками могут сравниться разве что электрики. И со своими прикладниками я могу договориться даже до мата (даром что Питер — культурная столица). Но ругаться с ними могу только я. Причем только лично.
Во всех остальных случаях они толковые специалисты, вполне способные самостоятельно справляться с задачами любой сложности. Как и схемотехники — настоящие кудесники припоя и контактов. Как и остальные подразделения в моей организации. И это правильный командный дух. А в ночь перед сдачей мы все со спокойной совестью спим дома. К этому моменту вся работа уже сделана. Поэтому я, пожалуй, просто сделаю вид что ничего не заметил.
Во всех остальных случаях они толковые специалисты, вполне способные самостоятельно справляться с задачами любой сложности. Как и схемотехники — настоящие кудесники припоя и контактов. Как и остальные подразделения в моей организации. И это правильный командный дух. А в ночь перед сдачей мы все со спокойной совестью спим дома. К этому моменту вся работа уже сделана. Поэтому я, пожалуй, просто сделаю вид что ничего не заметил.
Есть мнение, что массово в железном программировании от Rust будет толк тогда, когда он будет поддерживаться производителями железа. Не кучкой энтузиастов, а когда это будет официальный компилятор от какого-нибудь Analog Devices под их Sharc или Blackfin. Когда такое случится — не очень понятно. Так-то под х86 и армы уже давно пишут на Rust всякое.
Сейчас как раз делаем прототип железки на 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++.
Скажем, если вы прототипируете на 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++.
Ну что, если с конца то все не совсем так. Это про 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'а было практически невозможно. Ну и странная система старта (и безопасности обновлений как следствие) несколько охлаждает пыл.
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'а было практически невозможно. Ну и странная система старта (и безопасности обновлений как следствие) несколько охлаждает пыл.
Если найдете компилятор под нужную систему, то пожалуйста.
Отличная статья, спасибо. Полностью согласен, сам участвовал в проекте где перебробовали более 50 прототипов казалось бы очень простого устройства и программы на С. Даже не предполагаешь, что вылезет, особенно на дешёвых платах и запчастях заказанных с Ali. И про аутсорс верно, но это уже из ПО на полноценных PC и серверах, если вас подсаживают на аутсорс, то катастрофически убывает уровень понимания, что происходит в системе и скорость реакции на изменения в окружающем мире. Нет своих специалистов, которые на этапе тех.заданий и тех.решений предложат сразу лучший вариант.
А зачем вы заказываете запчасти с али?..
НЛО прилетело и опубликовало эту надпись здесь
Дешевле, а время не критично. Деньги собственные, проект как хобби. Клоны Arduino на разных Atmega или ESP8266 c USB, bluetooth, wi-fi и т.д. и т.п., больше для изучения и объяснения детям, не занимаюсь этим на постоянной основе. Доделают дети через пару месяцев, может напишу статью как это было.
Сорри за стеб, но рукоплескаю автору — давно не читал такое веселое изобретение колеса, как описание разработки железа от программистов. Оказывается, Agile не работает! Юху! Оказывается, нужно прототипировать! Юху! Оказывается, нужно писать на Си! Юху! И это даже еще без намека на ее величество Сертификацию, которая может угробить ваши многомесячные труды на корню и добавить еще столько же времени на переделку, сколько вы уже потратили.
Особенно понравилось про минимизацию рисков — боже, я представляю, сколько стартапов на загнулось, так как они их просто не могли оценить. Аутсорсинг прототипов? Да ничего сложного, просто вы их не умеете готовить.
Да ладно Вам. Во-первых это Yandex. В каждой избушке свои погремушки. А во вторых это все же интереснее очередной метеостанции на Arduino или Internet Radio на ESP32 или пивоварня на Raspberry. Меня, например, на ностальгию пробило. Вспомнились свои ощущения от первых проектов.
Про сертификацию Yandex, возможно, и не услышит. Их оборудование, как я понимаю, не включается в критические цепи автомобиля. Т.е. как видеорегистратор — формально сертификации не требует. Разве что на ЭМС. Да и не так уж страшен черт, как нам его малюют. Первые разы тяжело — потом привыкаешь. А аутсорсинг прототипов (как, собственно и всей разработки) — ну что Вы хотите. Хорошо что хоть до кого-то дошла сама глупость такой постановки вопроса.
Так почему бы и не похвалить авторов? Ну а на некоторые недостатки в комментариях уже указали. И Вы, lingvo, и kababok, и lelik363 и многие другие. А вот то, что на хабре есть не только прикладники меня радует. Хоть знать буду «коллег по цеху».
Впрочем, не думаю что хоть кто-то смог бы написать сильно лучше. Все же каждая компания, занимающаяся встраиваемыми системами уникальна и неповторима. У каждой своя методология разработки. Да что компания — по сути каждый проект уникален.
Про сертификацию Yandex, возможно, и не услышит. Их оборудование, как я понимаю, не включается в критические цепи автомобиля. Т.е. как видеорегистратор — формально сертификации не требует. Разве что на ЭМС. Да и не так уж страшен черт, как нам его малюют. Первые разы тяжело — потом привыкаешь. А аутсорсинг прототипов (как, собственно и всей разработки) — ну что Вы хотите. Хорошо что хоть до кого-то дошла сама глупость такой постановки вопроса.
Так почему бы и не похвалить авторов? Ну а на некоторые недостатки в комментариях уже указали. И Вы, lingvo, и kababok, и lelik363 и многие другие. А вот то, что на хабре есть не только прикладники меня радует. Хоть знать буду «коллег по цеху».
Впрочем, не думаю что хоть кто-то смог бы написать сильно лучше. Все же каждая компания, занимающаяся встраиваемыми системами уникальна и неповторима. У каждой своя методология разработки. Да что компания — по сути каждый проект уникален.
Ну я честно поставил плюс к статье, так что не надо на меня наседать. :-)
А насчет погремушек хотел ответить внизу, но отвечу тут — есть такие штуки, как "Design Practices" — документы для внутреннего пользования, которым стоит следовать при проектировании. В железе их очень ценят, так как это накопительный опыт предыдущих разработок, позволяющий избежать множество ошибок новичков и позволяющий получать A-Muster сразу и с первой итерации в серийном качестве. В Яндексе, похоже, эти Design Practices только пишут, так что удачи им с этим.
есть такие штуки, как «Design Practices» — документы для внутреннего пользования, которым стоит следовать при проектировании.
Увы. Боюсь не у каждой из Российских контор есть такой документ. И, конечно, эту практику у немцев стоит перенимать. Им отчасти повезло. Все же крылатая фраза из фильма (дай бог памяти) «нет такой работы, которую не смог бы делать солдат кайзеровской армии при наличии инструкции» достойна восхищения. Создание, поддерживание актуальности и следование данным рекомендациям действительно сильно сокращает затраты.
В наших же условиях этими самыми рекомендациями каждый разработчик обзаводится в курилке. Перенимая и творчески переосмысливая опыт старших товарищей и набивая собственные шишки. Тоже путь. Местами приводящий к революционным прорывам. Но чаще — к крайне нестабильному качеству выпускаемой продукции.
Кстати, а не поделитесь секретом — как поддерживается актуальность «Design Practices»?
Эх, вот много горького и справедливого в словах lingvo в комментарии выше.
В реальности автомобильные проекты не делают "водопадом" — заранее проектируются как минимум 3 фазы железа: A-Sample / B-Sample / C-Sample (или A-Muster и т.д. на немецком)
Где C-Sample — это уже серийный образец железа с удалёнными всеми отладочными интерфейсами.
А бывает даже A...F-Sample
Что, по сути, те же самые итерации, просто более жёстко запланированные.
А ещё от ведущих поставщиков железных компонентов можно заказать evaluation board.
Или, например, если говорить о модных робомобилях — у тех же Интела / nVidia / Bosch / Continental / TI и пр. можно прямо-таки взять напрокат те или иные сборки ECU/GPU и обвесок и покататься со своим софтом на них.
(здесь можно подергать saul со стороны Интела и, например, Boomburum как представителя БМВ :)))
Что, по сути, те же самые итерации, просто более жёстко запланированные.
Причем эти итерации для железа имеют еще и вполне определенные названия, и прототипы для них тоже. Proof of Concept, Design Prototype, Validation Prototype, Redesign-to-cost и прочие. И весь смысл, в том, что количество повторений каждой итерации желательно уменьшить до одного раза. А не то и время и деньги закончатся очень быстро.
На C++ выстрелить себе в ногу чуть-чуть проще
То, что С++ раздувает бинарь я согласен (особенно стандартный iostream и иже с ними), но вот то, что в крестах легче выстрелить в ногу? В Си нет std::unique_ptr, нет RAII, нет многих восхитительных вещей, что есть в крестах.
Если совсем упростить, то С работает примерно везде, если есть компилятор, ваш код скорее всего заработает.
Если писать на С++, есть очень высокая вероятность, что на какой-то конкретной железке компилятор и тулчейн устарели, не обновляются, а вы уже написали код с использованием каких-то модных вещей.
Можно ли этого избежать? Да, но проще писать на С :)
Если писать на С++, есть очень высокая вероятность, что на какой-то конкретной железке компилятор и тулчейн устарели, не обновляются, а вы уже написали код с использованием каких-то модных вещей.
Можно ли этого избежать? Да, но проще писать на С :)
В тексте документа были в основном всякие линуксожелезки, в них в 99.999% случаев есть gcc, и можно собрать свежий из исходников. А значит автоматом есть и свежайший С++.
Просто нужно не давиться тем, что дал вендор платы, а сразу брать buildroot/yocto project и жить с новым компилятором
Я про то, что когда понадобится переходить на узкоспециализированное железо, где уже не будет нормального линукса или будет, но очень древний, вариантов найти нормальный тулчейн и компилятор может не быть.
Поэтому вместо того, чтобы написать ПО за N дней, будем давиться голым ANSI C89, чтобы написать то же самое за N*3 дней?
Инструментарий выбирается "на берегу", когда еще ни одной строчки кода не написано
Ну, если экономия на железе покроет N*3 дней (а при массовом производстве — покроет), то да, давиться.
Не очень понятно про какой этап выговорите, возможно поэтому непонимание.
Если про первый, где прототип — то можно действительно на ноде в распбери писать, но если это следующий шаг, где прототип более приближен к конечному железу — то есть смысл переходить на конечные инструменты.
За то в C нет невиртуальных диструкторов, переопределения операций…
В Си нет std::unique_ptr, нет RAII, нет многих восхитительных вещей, что есть в крестах.
В C++ нет борроу чекера, нормальной системы владения, нет многих восхитительных вещей, что есть в расте. И выстрелить в ногу сложнее. Почему ты не рассматриваешь этот вариант?
В плане языка разработки — почему не Rust? Как и в питоне не надо будет мучительно отлаживать работу с памятью, но при этом доступно реальное время, как на C/C++.
Сыровато пока, и разработчиков нет толком. Я стараюсь для себя больше на С и С++ не писать (за исключением поддержки уже написанных проектов), но на работе альтернативы С пока нет.
А что именно сыровато?
Вся инфраструктура сыроватая, стандарта у языка нет, компилятор единственный и не сертифицированный.
Если прошивку прямо с нуля на нем разрабатывать — можно уже сейчас, если вот эти проблемы выше не блокируют, а вот если внедрять какие-то куски на Расте в уже существующую большую кодовую базу на С, то начинаются проблемы вроде невозможности использования заголовочных файлов с typedef, и неполной совместимости моделей памяти и владения (отчего половина glue-кода получается внутри unsafe-блоков), различия в подходах и т.п.
Короче — работы по внедрению много, а то, что результат в итоге получится сильно лучше, чем без такого внедрения — на воде вилами писано, поэтому бизнес пока что вставать в стройные ряды Rust Evangelism Task Force не спешит.
Если прошивку прямо с нуля на нем разрабатывать — можно уже сейчас, если вот эти проблемы выше не блокируют, а вот если внедрять какие-то куски на Расте в уже существующую большую кодовую базу на С, то начинаются проблемы вроде невозможности использования заголовочных файлов с typedef, и неполной совместимости моделей памяти и владения (отчего половина glue-кода получается внутри unsafe-блоков), различия в подходах и т.п.
Короче — работы по внедрению много, а то, что результат в итоге получится сильно лучше, чем без такого внедрения — на воде вилами писано, поэтому бизнес пока что вставать в стройные ряды Rust Evangelism Task Force не спешит.
поэтому бизнес пока что вставать в стройные ряды 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) в расте в принципе отсутствуют?
Какие такие заголовочные файлы с typedef, которые (.h) в расте в принципе отсутствуют?
Такие, которые вендорами железок обычно поставляются. Естественно, они отсутствуют в расте, как и вообще поддержка раста вендорами железа, и это одна из его многочисленных проблем.
Ваше мнение очень интересно, но мне бы хотелось услышать CodeRush
Это как бы не мнение, а факт. Я понимаю, что евангелисты раста неудобные для себя факты предпочитают игнорировать, ну или в крайнем случае заминусовывать, но факты — упрямая весчь.
KanuTaH дело говорит, пока на вендоры железа не начнут писать на Расте свои BSP, потребителей этих BSP, всяких OEM, ODM и IBV пересадить на него будет очень сложно, потому что сразу вылезут все проблемы с интеграцией (и реинтеграцией постоянной, потому что вендор обновляет свой код регулярно), о которых я тут и пишу.
Я не соглашусь с тем, что это проблема Раста, нет, это проблема косности и нежелания вендоров переходить на более качественный язык, но пока их все устраивает на С (а их все устаивает, они с ассемблера кое-как перелезли совсем недавно, меньше 15 лет назад), ничего со своей стороны они менять не станут — это дорого, а софтом они не торгуют (т.е. софт может быть любого качества, лишь бы работал хоть как-то).
Я не соглашусь с тем, что это проблема Раста, нет, это проблема косности и нежелания вендоров переходить на более качественный язык, но пока их все устраивает на С (а их все устаивает, они с ассемблера кое-как перелезли совсем недавно, меньше 15 лет назад), ничего со своей стороны они менять не станут — это дорого, а софтом они не торгуют (т.е. софт может быть любого качества, лишь бы работал хоть как-то).
Вендоров тоже можно понять, ресурсов на перелезание на раст нужно много, а будет ли из этого какой-то толк — вовсе не очевидно. Я бы не назвал это "косностью", это обычная прагматичность.
Толк будет в любом случае, я думаю, потому что затраты на поддержку низкого уровня ошибок теперь переложены на компилятор (который не устает), и в долгую эта стратегия все-таки окупается так или иначе. Безопасники давят со своей стороны, хоть и несильно, но стабильно, плюс можно оказаться в авангарде прогресса и получить бесплатную рекламу, плюс те подходы к дизайну, которые вынуждает применять Раст (иммутабельность по умолчанию, RAII, pattern matching, data race safety) — они сами по себе часто приводят к ускорению и упрощению кода, и получается тут на 5% быстрее стало, тут на 10% меньше ошибок, с миру по нитке — вот новый телевизор.
Рано или поздно на Раст (или другой более безопасный, но все еще достаточно низкоуровневый ЯП) все равно перейдут (т.к. С для потоковой коммерческой разработки — это все-таки очень плохой инструмент, скальпель в руках коновала), потому что их додавят таки безопасники, но не думаю, что это получится сделать скоро.
NVIDIA, кстати, недавно перешла на ADA/SPARK для своих automotive-проектов.
Рано или поздно на Раст (или другой более безопасный, но все еще достаточно низкоуровневый ЯП) все равно перейдут (т.к. С для потоковой коммерческой разработки — это все-таки очень плохой инструмент, скальпель в руках коновала), потому что их додавят таки безопасники, но не думаю, что это получится сделать скоро.
NVIDIA, кстати, недавно перешла на ADA/SPARK для своих automotive-проектов.
У меня несколько более скептическое к этому отношение, коновал — он коновал и есть, что ему ни дай, все будет плохим. Дадут раст — будет злоупотребление unsafe во имя срезания углов и т.п. Сейчас вон для C тоже и практик и инструментов хватает: и анализаторы всякие статические, и TDD, и MISRA, но сроки горят, и все такое, и с растом все будет то же самое.
Согласен с тем, что свидетелям святого дедлайна и поборникам стиля куяк-куяк-и-в-прод замена С на Раст поможет мало, и они в своем новом коде тоже начнут срезать углы направо и налево. При этом даже в таком говно-расте срезанные углы можно искать поиском по unsafe, плюс компилятор не даст собрать совсем уже невообразимую херню вроде замены "&" на "&&" или "&&" на ",".
В приличных местах (где за качество результата все таки готовы сколько-нибудь отвечать) говнокодеров рано или поздно либо перевоспитывают, либо изгоняют, и остаются люди, которые хотели бы писать на С хороший, добротный код, решающий их задачи и не отнимающий на написание слишком много времени, но они не могут, даже если хотят, потому что это выше человеческих сил.
На Расте, все же, намного проще писать, потому что нужно меньше вещей держать в голове (управление ресурсами в коде, переполнение буферов отслеживается компилятором, инициализация автоматическая, молчаливых приведений типов нет, молчаливых знаковых расширений нет, за арифметику с указателями бьют по рукам, за накидывание структур на память бьют по рукам, и т.п.), т.е. по итогу писать нормально, стабильно выдавая подходящий результат за разумное время, на нем может большее количество людей, и ошибок в коде получается в среднем меньше, по крайней мере мне так показалось. На С же нужна предельная концентрация внимания, постоянные проверки и перепроверки, вагон всякого тулинга и анализаторов, а в результате все равно имеем вот такое:
В приличных местах (где за качество результата все таки готовы сколько-нибудь отвечать) говнокодеров рано или поздно либо перевоспитывают, либо изгоняют, и остаются люди, которые хотели бы писать на С хороший, добротный код, решающий их задачи и не отнимающий на написание слишком много времени, но они не могут, даже если хотят, потому что это выше человеческих сил.
На Расте, все же, намного проще писать, потому что нужно меньше вещей держать в голове (управление ресурсами в коде, переполнение буферов отслеживается компилятором, инициализация автоматическая, молчаливых приведений типов нет, молчаливых знаковых расширений нет, за арифметику с указателями бьют по рукам, за накидывание структур на память бьют по рукам, и т.п.), т.е. по итогу писать нормально, стабильно выдавая подходящий результат за разумное время, на нем может большее количество людей, и ошибок в коде получается в среднем меньше, по крайней мере мне так показалось. На С же нужна предельная концентрация внимания, постоянные проверки и перепроверки, вагон всякого тулинга и анализаторов, а в результате все равно имеем вот такое:
В растовских крейтах такого добра тоже хватает, причём, казалось бы, никакие дедлайны на авторов не давят. Ну, поживём-увидим.
Интересная ветка. И интересные выводы. Я бы, правда, сказал что они довольно спорные.
Я думаю, что C умрет ровно в тот момент, когда исчезнет необходимость ради производительности расшивать сложные места на уровне ассемблера. На ПК это счастливое событие давно произошло. И спровоцировало рост непонятного по качеству и постоянно растущего в размере кода. Встраиваемые системы пока держатся, но Cortex-M на несколько сотен мегагерц да с мегабайтами памяти — это очень хороший шаг в этом направлении. Видимо первым языком, который в этот момент потеснит С, станет как раз Rust. Правда не уверен, что его быстренько не сменить какой-то интерпретатор байт-кода. Но это пока не увидишь — не узнаешь.
А вопрос сертификации, сроков и прочего… Я думаю, что это скорее вопрос грамотного планирования и управления разработкой. Ну, и конечно, квалификации разработчика. Тут действительно от языка мало что зависит.
Я думаю, что C умрет ровно в тот момент, когда исчезнет необходимость ради производительности расшивать сложные места на уровне ассемблера. На ПК это счастливое событие давно произошло. И спровоцировало рост непонятного по качеству и постоянно растущего в размере кода. Встраиваемые системы пока держатся, но Cortex-M на несколько сотен мегагерц да с мегабайтами памяти — это очень хороший шаг в этом направлении. Видимо первым языком, который в этот момент потеснит С, станет как раз Rust. Правда не уверен, что его быстренько не сменить какой-то интерпретатор байт-кода. Но это пока не увидишь — не узнаешь.
А вопрос сертификации, сроков и прочего… Я думаю, что это скорее вопрос грамотного планирования и управления разработкой. Ну, и конечно, квалификации разработчика. Тут действительно от языка мало что зависит.
Даже на ПК производительность уже не удваивается каждые 2 года.
Запрос на замену С на низком уровне идет сейчас с нескольких сторон, и производительность — не самая популярная из них, на мой взгляд. Код на и на Расте, и на С — достаточно быстрый, а критические части все равно придется писать на чем-то, напрямую ложащемся на архитектуру, будь это ассемблер или что-то еще похожее.
Я безопасник, и потому мне замена С нужна для того, чтобы среднестатистический код, написанный среднестатистическим обычным разработчиком-мидлом (который мало что понимает во всей этой безопасности ненужной, он по своей предметной области специалист) перестал быть невыносимо отвратительным с точки зрения сопротивления внешним воздействиям. Если такой достаточно-безопасный код при этом еще и нормально переживет нахождение в большом репозитории на несколько десятков проектов, в который каждый день коммитят несколько десятков человек, и его безопасность не деградирует со временем до состояния «след простыл» — моя жизнь станет значительно лучше, и CVE станет значительно меньше.
Опыт при этом показывает, что С в данном случае не помогает ничего, ни тулинг, ни грамотное управление, ни внедрение SDL, ни обучение всех разработчиков основам security mindset, потому что инструмент никогда под безопасность не затачивался, и требует соблюдение железной дисциплины не просто от программиста, а вообще от всех программистов, когда либо трогавших код на нем.
Писать безопасный код на С нечеловечески сложно, медленно, и потому дорого, от этого дырявое нынче абсолютно все, и очень много усилий направлено в итоге на то, чтобы заставить всю эту гору кода на С и его производных, которую мы все уже написали и вынуждены использовать и поддерживать, вести себя хоть в каких то рамках приличия. В железо пришлось затащить и теневой стек (чтобы хоть как-то бороться с ROP), и шифрованную и\или тегированную память, и компартментализацию (многоуровневую), и даже контракты (CHERI), и занесут еще вагон всего, только бы ПО не чинить.
В общем, Раст — это шаг в очень правильном направлении, и я его приветствую всеми фибрами души.
Я безопасник, и потому мне замена С нужна для того, чтобы среднестатистический код, написанный среднестатистическим обычным разработчиком-мидлом (который мало что понимает во всей этой безопасности ненужной, он по своей предметной области специалист) перестал быть невыносимо отвратительным с точки зрения сопротивления внешним воздействиям. Если такой достаточно-безопасный код при этом еще и нормально переживет нахождение в большом репозитории на несколько десятков проектов, в который каждый день коммитят несколько десятков человек, и его безопасность не деградирует со временем до состояния «след простыл» — моя жизнь станет значительно лучше, и CVE станет значительно меньше.
Опыт при этом показывает, что С в данном случае не помогает ничего, ни тулинг, ни грамотное управление, ни внедрение SDL, ни обучение всех разработчиков основам security mindset, потому что инструмент никогда под безопасность не затачивался, и требует соблюдение железной дисциплины не просто от программиста, а вообще от всех программистов, когда либо трогавших код на нем.
Писать безопасный код на С нечеловечески сложно, медленно, и потому дорого, от этого дырявое нынче абсолютно все, и очень много усилий направлено в итоге на то, чтобы заставить всю эту гору кода на С и его производных, которую мы все уже написали и вынуждены использовать и поддерживать, вести себя хоть в каких то рамках приличия. В железо пришлось затащить и теневой стек (чтобы хоть как-то бороться с ROP), и шифрованную и\или тегированную память, и компартментализацию (многоуровневую), и даже контракты (CHERI), и занесут еще вагон всего, только бы ПО не чинить.
В общем, Раст — это шаг в очень правильном направлении, и я его приветствую всеми фибрами души.
Ну, может, Яндекс, Гугл и Майкрософт, когда серьезно залезут в embedded, и заставят всех перейти на Раст, но пока там правят бал другие вендоры и тулчейны, критическая масса не достигнута.
Сложно что-то возразить. Грамотная и абсолютно правильная постановка вопроса. Впрочем, сложно — не значит невозможно.
На меня в свое время произвела большое впечатление замечательная публикация Шенона «Надежные схемы из ненадежных реле». Я тогда впервые задумался над тем насколько реально писать надежный код на любой из современных архитектур. Ведь по сути чем ниже язык, тем больше он подвержен специфическим особенностям каждой конкретной архитектуры. И язык C, как один из самых низкоуровневых языков просто вынужден наследовать все косяки, которые только реализованы непосредственно в архитектуре вычислительной системы. А любой подъем выше порождает не менее известную проблему «кто контролирует контролеров». А если добавить сюда все возможные аппаратные сбои, на которые тоже надо адекватно реагировать, то все становится совсем грустно.
И по сути хотим мы того или нет, а у нас не остается выбора кроме как крутиться внутри этой ненадежной системы впадая в ту или другую крайность при этом постоянно исправляя те или иные косяки в тех или иных частях кода. Потому, думаю, даже в среднесрочной перспективе спрос на «безопасников» и «системщиков» никуда не денется. Как и спрос на прикладников.
На меня в свое время произвела большое впечатление замечательная публикация Шенона «Надежные схемы из ненадежных реле». Я тогда впервые задумался над тем насколько реально писать надежный код на любой из современных архитектур. Ведь по сути чем ниже язык, тем больше он подвержен специфическим особенностям каждой конкретной архитектуры. И язык C, как один из самых низкоуровневых языков просто вынужден наследовать все косяки, которые только реализованы непосредственно в архитектуре вычислительной системы. А любой подъем выше порождает не менее известную проблему «кто контролирует контролеров». А если добавить сюда все возможные аппаратные сбои, на которые тоже надо адекватно реагировать, то все становится совсем грустно.
И по сути хотим мы того или нет, а у нас не остается выбора кроме как крутиться внутри этой ненадежной системы впадая в ту или другую крайность при этом постоянно исправляя те или иные косяки в тех или иных частях кода. Потому, думаю, даже в среднесрочной перспективе спрос на «безопасников» и «системщиков» никуда не денется. Как и спрос на прикладников.
Ну, в принципе во многих сферах эти проблемы все-таки успешно решили. Да, дорого, да, возможно не так эффективно, как хотелось бы. Да, порог вхождения достаточно высокий. Но лучше ничего нет.
Ну и поэтому немного смешно и одновременно грустно, что кто-то вдруг может решить, что эти проблемы можно решить вот так с наскока, просто перейдя на другой ЯП. А грустно от того, что все эти заморочки с Boeing 737 MAX или авариями автопилотов Теслы, покажутся нам детским лепетом, когда начнет падать такой "безопаснонадежно" написанный софт.
Я ничего не скажу про Tesla. Во-первых даже близко не владею вопросом, во вторых для меня до сих пор вопрос больше или меньше единицы соотношение хайпа к технике в этом проекте.
А вот по 737 MAX… Это действительно грустно. Уж казалось бы есть крайне немного сфер, где надежность и безопасность поставлена во главу угла. И авиация одна из них. И такой вот результат. Впрочем, наглядная демонстрация того самого философского вопроса про контроллеров контроллеров.
Впрочем, я не настолько пессимистичен как Вы. Мне кажется просто будет более жесткий водораздел между уровнями. Простейшая аналогия есть в области медицины. Там тоже времена универсальных специалистов прошли и наступила довольно жесткая специализация при обязательном владении базовыми принципами. Думаю, что IT рано или поздно постигнет та же участь. Оно уже есть. Я свою карму уронил до предела в спорах с прикладниками. Наивен был — думал удастся убедить. Ну да ладно, не о том сейчас. Сейчас о том, что прикладникам так или иначе нужны языки без «указателя на указатель по указателю», а системщикам не останется выбора кроме как использовать такую конструкцию. Конечно, системщиков нужно будет сильно меньше, чем прикладников. Но водораздел думаю будет, и будет довольно четкий. Это сейчас условный PHP-разработчик может довольно легко реализовать свой драйвер под тот же Linux. И даже довести его до mainline при должном желании. Думаю, в недалеком будущем нынешние программисты на C будут такими же странным товарищами, как сегодняшние Cobol'щики в финансовых сферах. Но спрос на них все равно останется.
И, конечно, у будущих системщиков не останется другого выбора кроме как осваивать безопасное написание своего кода. Хорошо, если к тому моменту появятся инструменты облегчающие данную задачу. Тот же Rust вполне годится как такой инструмент.
А вот по 737 MAX… Это действительно грустно. Уж казалось бы есть крайне немного сфер, где надежность и безопасность поставлена во главу угла. И авиация одна из них. И такой вот результат. Впрочем, наглядная демонстрация того самого философского вопроса про контроллеров контроллеров.
Впрочем, я не настолько пессимистичен как Вы. Мне кажется просто будет более жесткий водораздел между уровнями. Простейшая аналогия есть в области медицины. Там тоже времена универсальных специалистов прошли и наступила довольно жесткая специализация при обязательном владении базовыми принципами. Думаю, что IT рано или поздно постигнет та же участь. Оно уже есть. Я свою карму уронил до предела в спорах с прикладниками. Наивен был — думал удастся убедить. Ну да ладно, не о том сейчас. Сейчас о том, что прикладникам так или иначе нужны языки без «указателя на указатель по указателю», а системщикам не останется выбора кроме как использовать такую конструкцию. Конечно, системщиков нужно будет сильно меньше, чем прикладников. Но водораздел думаю будет, и будет довольно четкий. Это сейчас условный PHP-разработчик может довольно легко реализовать свой драйвер под тот же Linux. И даже довести его до mainline при должном желании. Думаю, в недалеком будущем нынешние программисты на C будут такими же странным товарищами, как сегодняшние Cobol'щики в финансовых сферах. Но спрос на них все равно останется.
И, конечно, у будущих системщиков не останется другого выбора кроме как осваивать безопасное написание своего кода. Хорошо, если к тому моменту появятся инструменты облегчающие данную задачу. Тот же Rust вполне годится как такой инструмент.
Мы тут, мне кажется, говорим про разную безопасность, я — про «security», а вы — про «safety». Более того, одним только переходом на другой ЯП дело точно не ограничится, и это вовсе не серебряная пуля, но без этого перехода ограничения становятся слишком сильные, разработка слишком медленной и дорогой, и потому security продолжают заметать под ковер в погоне за сроками.
Safety — это отдельная тема, которой я касался не очень сильно, и довольно давно, поэтому разговор предметный по ней не поддержу, прошу пардону.
Safety — это отдельная тема, которой я касался не очень сильно, и довольно давно, поэтому разговор предметный по ней не поддержу, прошу пардону.
Мне кажется мы просто обсуждаем два варианта отказа кода.
один — это когда правильно написанный и проверенный код вследствие ошибки компилятора или другой архитектуры процессора вдруг поведет себя неверно. Тут программист практически бессилен, кроме принудительного введения дополнительных ограничений, которые не позволят ему использовать некоторые свойства языка, которые потенциально могут привести к данной проблеме.
второй — это когда в силу явных или неявных особенностей языка закрадываются программные ошибки в сам исходный код, и которые возникают именно из-за программистов и их косяков, а компилятор или архитектура ни причем. То есть компилятор и железо ведут себя абсолютно правильно.
При этом что safety, что security страдают от обоих этих косяков.
Да, Вы абсолютно правы. Говоря о безопасности и надежности я имею в виду в первую очередь «Safety first». Пожалуй в пору признавать что это уже профессиональная деформация и меня так или иначе а будет клонить именно в эту сторону.
С другой стороны, а скажите — то, что реализовано в части того же SecureBoot не кажется Вам некоторой чужеродной надстройкой. По мне так тут как раз стык безопасности и секретности. Секретность как в первую очередь следствие потенциальной небезопасности написанного кода, а во вторую защиты коммерческих интересов. Впрочем, что первично что вторично — вопрос открытый.
Да и вообще. До поры человек с программатором или паяльником мог творить что угодно. И извечное простивостояние меча и щита никогда не закончится. Это ж один из ключевых двигателей прогресса.
Исходя из таких соображений крайне сложно отделить секретность (гарантированную неприкосновенность ключей в чипе) от безопасности (защиты программного продукта от недокументированного воздействия извне и адекватной реакции на него).
Вообще удивительно — но большинство тем уходит именно в эту область. А если уж до конца честно, то вопрос «security» я бы оставил исключительно для специальных применений. Сильно больше уделяя внимание именно «safety». Да, первое жизнь миллионов в руках политиков, но ведь второе жизнь каждого отдельно взятого индивидума. При чем практически всегда. Тут и боровые компьютеры в транспорте, и системы контроля утечек газа и много чего еще.
С другой стороны, а скажите — то, что реализовано в части того же SecureBoot не кажется Вам некоторой чужеродной надстройкой. По мне так тут как раз стык безопасности и секретности. Секретность как в первую очередь следствие потенциальной небезопасности написанного кода, а во вторую защиты коммерческих интересов. Впрочем, что первично что вторично — вопрос открытый.
Да и вообще. До поры человек с программатором или паяльником мог творить что угодно. И извечное простивостояние меча и щита никогда не закончится. Это ж один из ключевых двигателей прогресса.
Исходя из таких соображений крайне сложно отделить секретность (гарантированную неприкосновенность ключей в чипе) от безопасности (защиты программного продукта от недокументированного воздействия извне и адекватной реакции на него).
Вообще удивительно — но большинство тем уходит именно в эту область. А если уж до конца честно, то вопрос «security» я бы оставил исключительно для специальных применений. Сильно больше уделяя внимание именно «safety». Да, первое жизнь миллионов в руках политиков, но ведь второе жизнь каждого отдельно взятого индивидума. При чем практически всегда. Тут и боровые компьютеры в транспорте, и системы контроля утечек газа и много чего еще.
С для потоковой коммерческой разработки — это все-таки очень плохой инструмент, скальпель в руках коновалаСкальпель, который должен быть в руках хирурга. Но все хотят сэкономить и нанимают коновалов…
вы описываете проблемы, которые возникнут при смешивании двух разных языковДействительно, потому что уже писал, что если начинать писать с нуля — Раст нормальный уже сейчас, но с нуля прошивки сейчас мало кто пишет, начинают с существующей кодовой базы из BSP, EDK2 и набора собственного уже написанного кода, который весь переписывать никому не интересно — он работает уже сейчас.
Какие такие заголовочные файлы с typedef, которые (.h) в расте в принципе отсутствуют?Почти все интерфейсы между модулями в EFI описаны в виде т.н. протоколов, которые по факту — С-структуры с указателями на функции. Выглядят они примерно вот так. Таких файлов в проекте — море разливаное, и нужен инструмент, который автоматически генерировал бы из них определения, понятные коду на Расте (потому что держать два источника этих определений — преступление, они тут же разойдутся). Смотрел полгода назад — утилиты такой не нашел, все конвертеры c2rust не могут прожевать typedef'ы, union'ы и битовые поля, а в коде прошивки их очень много.
Инфраструктура Rust одна из самых проработанных. У C/C++ инфраструктуры в принципе нет.
Стандарт то есть, но точно почти ни где не реализован. Да и неопределенного поведения в нем полно.
Вы правда пользуетесь сертифицированным компилятором C?
Стандарт то есть, но точно почти ни где не реализован. Да и неопределенного поведения в нем полно.
Вы правда пользуетесь сертифицированным компилятором C?
От того, что инфраструктуры у С в принципе нет, ее каждый крупный проект и каждая крупная компания пишет самостоятельно и под свои задачи. В итоге, когда требуется интеграция Раста как еще одного ЯП в добавок к ассемблеру, С, ASL и VFR, начинаются сложности, потому что либо придется лишаться преимуществ cargo, либо придется как-то женить cargo и существующую инфраструктуру, чтобы не разломать обе. Это вот — целый проект на несколько месяцев само по себе, а всем некогда — задач полно, сроки подходят. Апдейты EDK2 — целое приключение, а тут нужно добавить целый новый ЯП…
Про стандарт: дело не в том, что он нигде не реализован весь (весь он и не нужен), а в том, что в компиляторе можно быть уверенным сколько-нибудь, особенно если у вас архитектура какая-нибудь непопулярная. Мне от этой уверенности не жарко и не холодно (потому что EFI использует последние версии clang, а не сертифицированный компилятор, отлитый в бронзе), но я знаю людей, которым нужен и стандарт, и сертифицированный компилятор, и которые без них никуда не перейдут.
Про стандарт: дело не в том, что он нигде не реализован весь (весь он и не нужен), а в том, что в компиляторе можно быть уверенным сколько-нибудь, особенно если у вас архитектура какая-нибудь непопулярная. Мне от этой уверенности не жарко и не холодно (потому что EFI использует последние версии clang, а не сертифицированный компилятор, отлитый в бронзе), но я знаю людей, которым нужен и стандарт, и сертифицированный компилятор, и которые без них никуда не перейдут.
К обсуждаемому в статье типу проектов эти аргументы не очень подходят. Особенно еслм вспомнить, что один из вариантов рассматривается питон.
Да и доверие к коду компилятора, написанного на Rust у меня больше, чем к коду компилятора, написанного на C/C++.
Ну и работы по формальной семантике языка Rust идут довально активно.
Да и доверие к коду компилятора, написанного на Rust у меня больше, чем к коду компилятора, написанного на C/C++.
Ну и работы по формальной семантике языка Rust идут довально активно.
Инфраструктура Rust одна из самых проработанных.
Извиняюсь, что вы подразумеваете под инфраструктурой?
Хорошая статья, для совсем начинающих.
Вопрос в тему выбора железа: а есть ли уже на рынке устройства на базе Android с аккумулятором, но без дисплея? Типа недотелефон.
Т.е. как HDMI-stick\dongle для телевизора, но с батареей (и может с камерой; конечно же, слот nanoSIM-карты (4G), WiFi (2.4 & 5 GHz) и BT4+ должны быть как обычно; OTG тоже явно полезный бонус; MicroHDMI для разработок и локального контроля, конечно нужен обязательно).
Суть в малогабаритности и небольшой автономности для работы в качестве контроллеров различной тематики.
Вопрос в тему выбора железа: а есть ли уже на рынке устройства на базе Android с аккумулятором, но без дисплея? Типа недотелефон.
Т.е. как HDMI-stick\dongle для телевизора, но с батареей (и может с камерой; конечно же, слот nanoSIM-карты (4G), WiFi (2.4 & 5 GHz) и BT4+ должны быть как обычно; OTG тоже явно полезный бонус; MicroHDMI для разработок и локального контроля, конечно нужен обязательно).
Суть в малогабаритности и небольшой автономности для работы в качестве контроллеров различной тематики.
Но зачем там Android?
Нааадо. IMHO, писать и обновлять софт для большинства из перечисленных интерфейсов одновременно — удобнее именно под Android. Но это хотя кто-что умеет.
p.s. я утверждаю не голословно, а потому, что сейчас эксплуатирую один образец подобного контроллера (уже 3ий месяц без выключения, когда-нибудь статью запилю по результатам) именно на базе стандартного андроидфона. Вот нужна бОльшая миниатюризация и удешевление бы, но не массовая.
p.s. я утверждаю не голословно, а потому, что сейчас эксплуатирую один образец подобного контроллера (уже 3ий месяц без выключения, когда-нибудь статью запилю по результатам) именно на базе стандартного андроидфона. Вот нужна бОльшая миниатюризация и удешевление бы, но не массовая.
Меня терзают смутные сомнения, что Андроид им нужен потому, что на нём легко запустить нейросеть, например, Tensor Flow Lite. Потом сделают срезы с видео про уставшего водителя, злого него же и т.д. Обучат сеть, и проект готов.
Тут я цветы распознавал: youtu.be/5EN-wQU7bxs, а они будут водителей.
Тут я цветы распознавал: youtu.be/5EN-wQU7bxs, а они будут водителей.
zorins, ты со своим огурцом в тему.
ИМХО, при сравнении одноплатников большинство аргументов притянуты за уши. Реальная ситуация совсем другая. Местами с точностью до наоборот.
Выглядит так, как будто автору очень хотелось оправдать свой отказ от Малины.
Выглядит так, как будто автору очень хотелось оправдать свой отказ от Малины.
Тогда интересно было бы взглянуть на Ваш собственный список плюсов и минусов. Напишете?
Много писать, к сожалению, некогда. Вот вам честный обзор: www.youtube.com/watch?v=XfM7hhwr6to
Отмечу следующие моменты:
— Нано Пи под нагрузкой потребляет (и рассеивает) больше четвёртой Малины (не говоря уже о третьей),
— в целом производительность прямо пропорциональна потребляемой мощности (также зависит от техпроцесса и оптимизации чипа, но не кардинально у сравнимых чипов),
— самое главное, использовать китайский процессор в разработке Яндекса — это, как минимум, нестандартно и смело (ни документации нормальной, ни поддержки, ни инструментов). Из перечисленных в статье, Малина, по крайней мере, вдоль и поперёк изучена. А вообще есть отладочные платы и на процессорах TI, NXP и на том же Qualcomm (DragonBoard).
Ну и да, Raspberry Pi 3 compute module 32Gb eMMC — ИМХО, неплохой вариант.
Отмечу следующие моменты:
— Нано Пи под нагрузкой потребляет (и рассеивает) больше четвёртой Малины (не говоря уже о третьей),
— в целом производительность прямо пропорциональна потребляемой мощности (также зависит от техпроцесса и оптимизации чипа, но не кардинально у сравнимых чипов),
— самое главное, использовать китайский процессор в разработке Яндекса — это, как минимум, нестандартно и смело (ни документации нормальной, ни поддержки, ни инструментов). Из перечисленных в статье, Малина, по крайней мере, вдоль и поперёк изучена. А вообще есть отладочные платы и на процессорах TI, NXP и на том же Qualcomm (DragonBoard).
Ну и да, Raspberry Pi 3 compute module 32Gb eMMC — ИМХО, неплохой вариант.
Полагаю, Яндекс как раз таки может без проблем договориться с Allwinner'ом, чтобы получить всё вами перечисленное.
Договориться то можно, но как получить то, чего нет?
Из китайских процессоров по перечисленным вопросам в лучшую сторону отличается только Медиатек. Но он, насколько я знаю, в цивилизованных странах не продаётся (в том числе в виде изделий), так как имеет проблемы с патентами той же Квалкомм.
Из китайских процессоров по перечисленным вопросам в лучшую сторону отличается только Медиатек. Но он, насколько я знаю, в цивилизованных странах не продаётся (в том числе в виде изделий), так как имеет проблемы с патентами той же Квалкомм.
но как получить то, чего нет
Вы так в этом уверены?
Нормальная документация выглядит как-то вот так.
Приведите китайские примеры, пожалуйста. Пусть даже на китайском языке. Хотя бы один подобный документ.
Приведите китайские примеры, пожалуйста. Пусть даже на китайском языке. Хотя бы один подобный документ.
Не поймите меня неправильно, я не против китайских микросхем. У нас в последней разработке все 5 микросхем — китайские, причём на две из них даже английских даташитов нет. Мы сознательно заменили все TI по разным актуальным причинам.
ИМХО, стоит разделять, что и для чего делается. А затем выбирать, из чего его делать.
ИМХО, стоит разделять, что и для чего делается. А затем выбирать, из чего его делать.
НЛО прилетело и опубликовало эту надпись здесь
Думаю, да. В партиях от 50 или от 200 тысяч штук. Лучше уточнить в Броадкоме. Загрузчик только придётся написать свой ибо копирайт Малины.
Согласен с Вами.
Например, для 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 на чипе и с интерфейсом камеры, как раз, чтобы усталость определять чью-нибудь…
Например, для 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 на чипе и с интерфейсом камеры, как раз, чтобы усталость определять чью-нибудь…
Ну одноплатных ПК много и ASUS мы тоже пробовали.
Главный недостаток Raspberry — отсутствие нормального накопителя для системы, всё остальное как-то решается (кроме минусовых температур). Да, 3 модель греется не так сильно, как 4-я, но и производительность там весьма средняя.
Всё, что мы использовали от FriendlyARM вполне открытое, понятное и есть все исходники, поэтому мне не вполне понятно, что именно там не очень открытое.
Главный недостаток Raspberry — отсутствие нормального накопителя для системы, всё остальное как-то решается (кроме минусовых температур). Да, 3 модель греется не так сильно, как 4-я, но и производительность там весьма средняя.
Всё, что мы использовали от FriendlyARM вполне открытое, понятное и есть все исходники, поэтому мне не вполне понятно, что именно там не очень открытое.
Вычислительный модуль подразумевался, с 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. Тогда бы получилась серьезная система распознавания, нейроморфная. Но — это дело будущего.
С 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. Тогда бы получилась серьезная система распознавания, нейроморфная. Но — это дело будущего.
Уважаемые, подскажите, есть ли модуль, который представляется, как usb клавиатура и который можно программировать, чтобы он выдавал последовательности символов?
Вообще есть модуль gadgetfs, который позволяет настраивать USB-контроллер на различные функции. В зависимости от конфига это будет Mass Storage Device, CDC-ACM, RNDIS, HID, или все вместе.
Arduino Leonardo, или другие (есть в микроисполнении), на базе ATmega32u4.
При попадании в недобрые руки, такое устройство может принести немало проблем владельцу компьютера, в который он будет вставлен.
При попадании в недобрые руки, такое устройство может принести немало проблем владельцу компьютера, в который он будет вставлен.
На платке blue pill и фреймворке stm32cube такая штука делается недорого и довольно быстро (есть положительный опыт с имитацией hid-устройства и режимом usb passthrough на stm32f407)
Спасибо за текст.
Удалось ли решить проблему с надежностью записи, насколько eMMC в этом плане лучше обычных SD-карт? Не раз слышал что стандартные карты помирают через год эксплуатации.
Удалось ли решить проблему с надежностью записи, насколько eMMC в этом плане лучше обычных SD-карт? Не раз слышал что стандартные карты помирают через год эксплуатации.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как быстро делать прототипы устройств и почему это важно. Доклад Яндекс.Такси