Вы напрасно думаете, что я выступаю Вашим alter-ego. Это не совсем так, если не сказать совсем не так. Я всячески стараюсь избегать «политических» вопросов. Не дело инженера решать их и давать какие-то рекомендации заказчику. Его дело довести объективную картинку. Обрисовать все сложности. Даже если из-за этого будет потерян заказ. Да, возможно я и не прав. Но строго IMHO — лучше потерять заказ, чем репутацию специалиста.
А теперь давайте вернемся к исходным предпосылкам. Смотрите — вы, как автор, знаете возможности Вашего изделия. И дальше Ваше с заказчиком совместное решение — или Вы делаете его целиком сами (что неизбежно увеличит сроки) или бьете задачу на части. Задираете себе схемотехнику, системную и драйверную часть и отдаете прикладную на откуп спецам заказчика. Это позволит сократить сроки получения готового изделия. Особенно если Вы сможете выдать прикладникам эмуляторы изделия (тот самый эмулятор LoRaWAN или трек с реального GPS). И, конечно, обговорите метрики производительности. В первом приближении аналогом современных ARM'ов вполне могут стать старые нетбуки c N270 атомом. Это и только это позволит избежать описываемых Вами проблем.
И еще раз — конечно, прототип с железкой близкой к реальной — это лучший вариант. Я нигде и никогда другого и не писал. Я писал только то, что далеко не всех такой вариант устроит. Хотя бы потому, что грамотно настроить систему кросс-сборки это тоже время, а собирать нативно на не блещущем производительностью ARM'е с ограниченной по размеру RAM — то еще удовольствие.
Интересная ветка. И интересные выводы. Я бы, правда, сказал что они довольно спорные.
Я думаю, что C умрет ровно в тот момент, когда исчезнет необходимость ради производительности расшивать сложные места на уровне ассемблера. На ПК это счастливое событие давно произошло. И спровоцировало рост непонятного по качеству и постоянно растущего в размере кода. Встраиваемые системы пока держатся, но Cortex-M на несколько сотен мегагерц да с мегабайтами памяти — это очень хороший шаг в этом направлении. Видимо первым языком, который в этот момент потеснит С, станет как раз Rust. Правда не уверен, что его быстренько не сменить какой-то интерпретатор байт-кода. Но это пока не увидишь — не узнаешь.
А вопрос сертификации, сроков и прочего… Я думаю, что это скорее вопрос грамотного планирования и управления разработкой. Ну, и конечно, квалификации разработчика. Тут действительно от языка мало что зависит.
Но могли бы не отвечать :3
Не знаю. Смотрите, пусть скорость не большая. Этак 115200 на хвост. Будем грубо считать 10KiB в секунду на направление. Интерфейс дуплексный — значит 20KiB в секунду, да на 8 интерфейсов — это в пике 160KiB в секунду только на полезных данных. По сети. Если не резать MTU (а это 4KiB) то 4*8*2=64KiB только для сетевых буферов. А их еще по памяти и между памятью и периферией гонять надо. Вот и получается что ресурсов-то не много. Сильно не разгуляешься. Так что вполне очевидно, что без «ручной настройки» не обойдется.
Впрочем, не сказал бы что задача не решаемая. Вполне себе эпизод из жизни разработчиков подобной аппаратуры. Правда вот необходимость именно TCP меня как-то немного подгладывает. Впрочем, если это было в ТЗ, то с ТЗ, как известно, не спорят.
Можно я не буду задавать Вам вопрос почему реализация задачи обмена данными через кучу TCP-сокетов на 100BASE-T поручена микроконтроллеру с 64Кб ОЗУ и боюсь спросит какой тактовой частотой?
Боюсь, далеко не всем будет понятно НАСКОЛЬКО это много. Впрочем, оставлять неиспользованной встроенную SRAM… По мне за это отдельный котел приготовлен. Это ж какой нереализованный простор для оптимизации производительности.
Ну, в моем случае это была необходимость сменить платформу с x86 на ARM при этом сохранив и минимально модернизировав все наработки. Ибо проект делался чуть-ли не подпольно, преодолевая сопротивление всех структур каких только можно. В итоге мы сделали это. Просто показав, что это можно сделать. Увы, этот проект именно в таком виде ушел в продакшн. Ибо автономность (энергоэффективность) ARM в сравнении с тогдашними встраиваемыми 586/686'ми на наших задачах была просто космической. К счастью, сегодня он практически полностью выведен из эксплуатации. Хотя увы, местами еще работает.
И все же мы были одними из первых кто начал жить на ARM и Linux. Для понимания — это был период еще Intel PXA255, телефоны на котором едва работали на Windows Mobile и только некоторым гикам удалось запустить на Palm Tungsten T5 вполне себе живой Linux (и то без всяких U-Boot и прочего). Андроид если и был, то в зачаточном состоянии.
Но к чему я все это? Да все к тому же. Вечный спор с прикладниками. Их позиция «сегодня ресурсов мало — завтра поставят достаточно» вполне оправдана. Чего уж там. Прогресс на месте не стоит. Но к счастью и нашу позицию «какая бы не была производительная система подавляющее большинство времени она должна спать и экономит батарею» пусть и с трудом, но находит отклик. И это правильно. Именно этот конфликт и позволяет изделиям развиваться.
есть такие штуки, как «Design Practices» — документы для внутреннего пользования, которым стоит следовать при проектировании.
Увы. Боюсь не у каждой из Российских контор есть такой документ. И, конечно, эту практику у немцев стоит перенимать. Им отчасти повезло. Все же крылатая фраза из фильма (дай бог памяти) «нет такой работы, которую не смог бы делать солдат кайзеровской армии при наличии инструкции» достойна восхищения. Создание, поддерживание актуальности и следование данным рекомендациям действительно сильно сокращает затраты.
В наших же условиях этими самыми рекомендациями каждый разработчик обзаводится в курилке. Перенимая и творчески переосмысливая опыт старших товарищей и набивая собственные шишки. Тоже путь. Местами приводящий к революционным прорывам. Но чаще — к крайне нестабильному качеству выпускаемой продукции.
Кстати, а не поделитесь секретом — как поддерживается актуальность «Design Practices»?
Давайте я сразу обозначусь — все что ниже это мое персональное мнение. Жестко по MISRA у меня сертифицировалось всего пара проектов, и те по голому железу. Потому применительно к Linux у меня нет практического опыта, а есть только размышления.
И так — в принципе вполне. Если впадать в крайности и будет требоваться жесткое соответствие исходников MISRA, то это реализуемо. Другое дело, что разумнее конечно относиться к MISRA не как к ограничивающему стандарту, а как к «правилам хорошего тона».
В микроконтроллерной среде у этих рекомендаций, конечно, больше шансов, чем под операционной системой. Но даже там — если заказчик жестко не требует, то я для улучшения читаемости и сопровождаемости кода я в целом ряде случаев отступаю от требований. Они все же во главу угла ставят надежность. Для того и создавались. Временами разумнее плюнуть на надежность там, где и без MISRA уверен в результате, но написать понятный код. Это работает надежнее, чем комментарий на две страницы.
Но в целом рекомендации очень толковые. И как минимум один проект целиком и полностью по ним стоит сделать.
Если бы я мог себя клонировать раз хотя бы 30 — то весь системный код был бы написан на MISRA C, а GUI на QT. Но увы, у отдела прикладников свои взгляды на целесообразность тех или иных инструментов. К счастью, конкретно в моих изделиях +30MiB далеко не самое страшное.
Да ладно Вам. Во-первых это Yandex. В каждой избушке свои погремушки. А во вторых это все же интереснее очередной метеостанции на Arduino или Internet Radio на ESP32 или пивоварня на Raspberry. Меня, например, на ностальгию пробило. Вспомнились свои ощущения от первых проектов.
Про сертификацию Yandex, возможно, и не услышит. Их оборудование, как я понимаю, не включается в критические цепи автомобиля. Т.е. как видеорегистратор — формально сертификации не требует. Разве что на ЭМС. Да и не так уж страшен черт, как нам его малюют. Первые разы тяжело — потом привыкаешь. А аутсорсинг прототипов (как, собственно и всей разработки) — ну что Вы хотите. Хорошо что хоть до кого-то дошла сама глупость такой постановки вопроса.
Так почему бы и не похвалить авторов? Ну а на некоторые недостатки в комментариях уже указали. И Вы, lingvo, и kababok, и lelik363 и многие другие. А вот то, что на хабре есть не только прикладники меня радует. Хоть знать буду «коллег по цеху».
Впрочем, не думаю что хоть кто-то смог бы написать сильно лучше. Все же каждая компания, занимающаяся встраиваемыми системами уникальна и неповторима. У каждой своя методология разработки. Да что компания — по сути каждый проект уникален.
Боюсь что конкретного ответа Вы не дождетесь. Все же в мире встраиваемых систем это экзотика. Мое персональное мнение — не стоит. Если только задача не заточена четко под Go. Да и в этом случае я бы подумал.
Понимаете тут все довольно человеко-ориентировано. Допустим Ваша задача решена на Go и необходима строго ее мобильная версия. Тогда можно думать в таком ключе. Но если задачу еще только предстоит решить, то с учетом ограниченности ресурсов (а уж поверьте, их всегда и всем мало) лучше брать более низкоуровневые языки. Даже больше — если можно обойтись без плюсов, лучше обходиться. Выкидывать все новомодные штучки и вспоминать о такой замечательной вещи как Unix-way.
Впрочем, python прополз и в этот мир. Думаю, что рано или поздно прикладники и здесь начнут диктовать свои условия. Потенциально даже исключать системщиков как лишнее звено между собой и схемотехниками. Во всяком случае есть некоторые сигналы, говорящие о том что такой расклад совсем не выглядит «страшной сказкой на ночь».
Но это позже. А пока разве что Rust способен что-то противопоставить C и C++. Но, «поверьте, здесь не все так однозначно» (с) Впрочем, темой Rust я с подачи Habr'а сам только недавно озадачился. Пока считаю что нет смысла писать на Rust как на C, когда есть непосредственно С. Впрочем, когда-то я тоже самое говорил про ассемблер. Потому ограничусь тем, что "… но это не точно" (с)
Ну что тут скажешь, кроме очевидного — сроки сильно зависят от сложности. И есть единственный вариант их сокращать — как можно больше частей проекта выполнять параллельно. Пока схемотехники «колдуют» со схемой и платой системщики готовят загрузчики и системы на близкой к проекту отладке а прикладники пишут и отлаживают прикладное ПО на обычных ПК. Потом все собирается вместе. Впрочем, это вполне обычный путь любой разработки.
Но посыл Ваш абсолютно правильный. Не при каких обстоятельствах нельзя называть конкретные сроки для абстрактного проекта. Впрочем, думаю что автор статьи это тоже прекрасно понимает.
Если ресурсы позволяют — то что угодно. JAVA, C#, Go. Нет проблем. Кроме, ресурсов, конечно. Ну, пожалуй еще вопросы правильного питания и охлаждения всегда актуальны. А так даже OpenCL/OpenGL не самые редкие гости в современных встраиваемых системах.
компоненты на более или менее сложную плату поставляются 8-12 недель
Накинулись на Вас. По мне напрасно накинулись. Увы, реали таковы что часть комплектующих иногда приходится ждать и пол года. Такова она — доля разработчиков реальных железок. И конечно, этот прискорбный факт отодвигает момент получения прототипа.
С другой стороны, ведь Вы и Yandex под прототипом понимаете разные вещи. С позиции автора статьи — прототип это железка, позволяющая начать реализовывать и отлаживать ПО. При чем по большей части прикладное. Для Вас прототип — это первая (если хотите отладочная) плата. По сути и то и другое можно назвать прототипом.
Впрочем, согласен. Из статьи разница между EVT, DVT и PVT совершенна не очевидна. Или слишком сложно, или слишком просто — но в любом случае оставляет очень много простора для домыслов. И еще — никто ведь не говорит, что не может быть, допустим, DVT rev1, rev2, revN. Разработка (особенно связанная с железом) — это не производство по готовой документации. Мало что удается сделать с первой попытки.
С одной стороны — безусловно. Если конечное изделие будет крайне ограничено в ресурсах, то чем быстрее эти ограничения станут очевидными тем лучше.
С другой стороны есть вопрос удобства отладки как ПО, так и взаимодействия с окружающим миром. Все же внутрисхемная отладка — это скорее прерогатива системщиков. А подавляющее большинство кода так или иначе пишется прикладниками. Особенно это касается сложных решений. Там системная составляющая сильно меньше прикладной. Опять же — нельзя впадать в крайности. А то прецеденты запуска PostgreSQL сервера c NAND & UBIFS конечно были. И это даже работало, но… По вполне понятным причинам ни на одном собеседовании я не стану упоминать об этом решении.
Подводя некую черту могу заметить что прототип и конечное изделие не обязаны быть максимально похожими. Это разные стадии проектирования с разными задачами. Однако, если всех заинтересованных устраивает прототип близкий к финальному изделию — то это один из лучших вариантов.
Но не кажется Вам, что процесс разработки крайне сложно поддается алгоритмизации? Не все можно отмакетировать на коммерческих платах. Не всегда стоит думать о массовом производстве (уже не говоря о том, что массовое производство у каждой компании разное). Более того, в подавляющем большинстве случаев, если это можно отмакетировать на RaspberryPI или ее аналогах, то это можно и на обычном ПК. При этом на ПК удобнее и пользы будет сильно больше.
И, раз уж у Вас есть время писать статьи — можно просьбу. Доведите до широкой публики подводные камни разных накопителецй информации. Serial/Parallel Flash (NOR/NAND), QSPI Flash, (e)MMC/SecureDigital, (m)SATA. А то надоело каждый раз рассказывать одно и тоже. А сам не напишу.
Это все Вам не в упрек, а просто мысли от человека который всю жизнь занимался разработкой в разных компаниях. И, безусловно, основные мысли абсолютно правильны и справедливы.
Главная проблема-то в чем? Разве в качестве звука? Нееет. Главная проблема в том, что музыку перестали покупать. А зачем — раз купил и на века. То ли дело касеты. Пару сотен раз послушал — скрипит и пердит. А еще пленку и зажевать может. А винил еще лучше — после десятого прослушивания иглой дорожки разбиваются. Хочешь не хочешь а новую купишь.
Пора, давно пора возрождать источники бабла, которые так неудачно были профуканы. Потому в пору пускать статьи о «плохом» цифровом звуке с его погрешностью дискретизации, и про кодеки, которые и без того плохую цифру делают еще хуже. Так что молодцы. Все правильно.
Конечно. Я схватил первое что попалось в Google картинках (ну да, не хорошо). И в мыслях не было рекламировать какую-то технологию. Ваша больше к теме подходит. Хотя, по мне и она не идеальна. Что выше пик глупости и плато стабильности — тот еще вопрос. Я бы сказал, что пик глупости-то сильно повыше будет. И, в целом нет ничего страшного, что новички к нему приближающиеся кажутся более умными и продуктивными чем специалисты. Ему все кажется простым, на все есть готовый ответ, колкое замечание не по делу, гора специфических терминов мало понятных заказчику. Впрочем, повторюсь — вопрос дискуссионный. Возможно, картинка в таком виде тоже справедлива.
А при чем здесь донаты? Я говорил про вполне официальную зарплату. Любой проект, если он, конечно, не совсем «домашнее животное», где-то применяется. И будь он трижды некоммерческим, это не делает его никому не нужным. Наоборот — как раз некоммерческие проекты, будучи выпущены под такими спорными лицензиями как GPL, максимально быстро развиваются. И ведь развиваются они в первую очередь за счет тех, кто работает «за зарплату», но в работе использует эти проекты.
А что до второго утверждения, то… Знаете, по моему вам надо попробовать уехать из города. Совсем. И далеко. На месяц. Реально в тайгу, где из света фонарик (на крайний случай генератор). Я ведь Вас не убежу, что и современный мир вполне себе сможет обойтись без цифровых технологий. Вас убедит только увиденное своими глазами. Есть множество областей, где IT не нужен. Совсем и абсолютно. Поищите фильм «Байкал. 180 дней одиночества». Француз молодец. Без лишних ужасов и чернухи и весьма правдиво. Съездите в деревню. Летом помахайте косой, зимой топором или пешней. Да та же рыбалка только в городе, где рыба под прессом рыболовов, требует эхолотов или чего-то такого. А садоводство или плодо- овощеводство? А физкультура и спорт? А моделизм в конце-концов? Астрономия? Bird Watching? Аквариумистика и террариумистика? Литература? Театр? Танцы? Да мало ли где еще… Практически везде если и есть IT, то они играют даже не вторую, а десятую роль. Замыкаться строго на IT — значит всеми силами идти к выгоранию, а потенциально и к депрессии.
Впрочем, все это здесь это уже мохнатый оффтопик. В любом случае Ваша жизнь — это целиком и полностью Ваша зона ответственности. И только Вам решать где работать, и какие хобби иметь.
А в одном из соседних обсуждений меня за необходимость учиться решать задачи методом сверху вниз обсмеяли. Сказав что каждый IT'шник это умеет буквально с рождения и нет никакой разницы по этой части между зеленым юнцом и матерым мастером — ибо базовый навык.
По сути — мало этого. Чем больше овладеваешь навыком бить задачи и решать их по частям тем больше тебе их сваливается. И так продолжается до тех пор, пока поток задачь не превышает твои возможности. И вот тут, как только ты не справляешься, тебе дают послабление и возможность завершить начатое прежде чем подкинут нового. В итоге все равно всегда на пределе. Одна из причин проблем именно в этом. До 40 лет проблем не было. Организм справлялся. Теперь стало сильно хуже.
Подумаю на счет книги. Но что-то мне подсказывает, что для меня она будет достаточно бесполезной…
А теперь давайте вернемся к исходным предпосылкам. Смотрите — вы, как автор, знаете возможности Вашего изделия. И дальше Ваше с заказчиком совместное решение — или Вы делаете его целиком сами (что неизбежно увеличит сроки) или бьете задачу на части. Задираете себе схемотехнику, системную и драйверную часть и отдаете прикладную на откуп спецам заказчика. Это позволит сократить сроки получения готового изделия. Особенно если Вы сможете выдать прикладникам эмуляторы изделия (тот самый эмулятор LoRaWAN или трек с реального GPS). И, конечно, обговорите метрики производительности. В первом приближении аналогом современных ARM'ов вполне могут стать старые нетбуки c N270 атомом. Это и только это позволит избежать описываемых Вами проблем.
И еще раз — конечно, прототип с железкой близкой к реальной — это лучший вариант. Я нигде и никогда другого и не писал. Я писал только то, что далеко не всех такой вариант устроит. Хотя бы потому, что грамотно настроить систему кросс-сборки это тоже время, а собирать нативно на не блещущем производительностью ARM'е с ограниченной по размеру RAM — то еще удовольствие.
Я думаю, что C умрет ровно в тот момент, когда исчезнет необходимость ради производительности расшивать сложные места на уровне ассемблера. На ПК это счастливое событие давно произошло. И спровоцировало рост непонятного по качеству и постоянно растущего в размере кода. Встраиваемые системы пока держатся, но Cortex-M на несколько сотен мегагерц да с мегабайтами памяти — это очень хороший шаг в этом направлении. Видимо первым языком, который в этот момент потеснит С, станет как раз Rust. Правда не уверен, что его быстренько не сменить какой-то интерпретатор байт-кода. Но это пока не увидишь — не узнаешь.
А вопрос сертификации, сроков и прочего… Я думаю, что это скорее вопрос грамотного планирования и управления разработкой. Ну, и конечно, квалификации разработчика. Тут действительно от языка мало что зависит.
Не знаю. Смотрите, пусть скорость не большая. Этак 115200 на хвост. Будем грубо считать 10KiB в секунду на направление. Интерфейс дуплексный — значит 20KiB в секунду, да на 8 интерфейсов — это в пике 160KiB в секунду только на полезных данных. По сети. Если не резать MTU (а это 4KiB) то 4*8*2=64KiB только для сетевых буферов. А их еще по памяти и между памятью и периферией гонять надо. Вот и получается что ресурсов-то не много. Сильно не разгуляешься. Так что вполне очевидно, что без «ручной настройки» не обойдется.
Впрочем, не сказал бы что задача не решаемая. Вполне себе эпизод из жизни разработчиков подобной аппаратуры. Правда вот необходимость именно TCP меня как-то немного подгладывает. Впрочем, если это было в ТЗ, то с ТЗ, как известно, не спорят.
Боюсь, далеко не всем будет понятно НАСКОЛЬКО это много. Впрочем, оставлять неиспользованной встроенную SRAM… По мне за это отдельный котел приготовлен. Это ж какой нереализованный простор для оптимизации производительности.
И все же мы были одними из первых кто начал жить на ARM и Linux. Для понимания — это был период еще Intel PXA255, телефоны на котором едва работали на Windows Mobile и только некоторым гикам удалось запустить на Palm Tungsten T5 вполне себе живой Linux (и то без всяких U-Boot и прочего). Андроид если и был, то в зачаточном состоянии.
Но к чему я все это? Да все к тому же. Вечный спор с прикладниками. Их позиция «сегодня ресурсов мало — завтра поставят достаточно» вполне оправдана. Чего уж там. Прогресс на месте не стоит. Но к счастью и нашу позицию «какая бы не была производительная система подавляющее большинство времени она должна спать и экономит батарею» пусть и с трудом, но находит отклик. И это правильно. Именно этот конфликт и позволяет изделиям развиваться.
Увы. Боюсь не у каждой из Российских контор есть такой документ. И, конечно, эту практику у немцев стоит перенимать. Им отчасти повезло. Все же крылатая фраза из фильма (дай бог памяти) «нет такой работы, которую не смог бы делать солдат кайзеровской армии при наличии инструкции» достойна восхищения. Создание, поддерживание актуальности и следование данным рекомендациям действительно сильно сокращает затраты.
В наших же условиях этими самыми рекомендациями каждый разработчик обзаводится в курилке. Перенимая и творчески переосмысливая опыт старших товарищей и набивая собственные шишки. Тоже путь. Местами приводящий к революционным прорывам. Но чаще — к крайне нестабильному качеству выпускаемой продукции.
Кстати, а не поделитесь секретом — как поддерживается актуальность «Design Practices»?
И так — в принципе вполне. Если впадать в крайности и будет требоваться жесткое соответствие исходников MISRA, то это реализуемо. Другое дело, что разумнее конечно относиться к MISRA не как к ограничивающему стандарту, а как к «правилам хорошего тона».
В микроконтроллерной среде у этих рекомендаций, конечно, больше шансов, чем под операционной системой. Но даже там — если заказчик жестко не требует, то я для улучшения читаемости и сопровождаемости кода я в целом ряде случаев отступаю от требований. Они все же во главу угла ставят надежность. Для того и создавались. Временами разумнее плюнуть на надежность там, где и без MISRA уверен в результате, но написать понятный код. Это работает надежнее, чем комментарий на две страницы.
Но в целом рекомендации очень толковые. И как минимум один проект целиком и полностью по ним стоит сделать.
Про сертификацию Yandex, возможно, и не услышит. Их оборудование, как я понимаю, не включается в критические цепи автомобиля. Т.е. как видеорегистратор — формально сертификации не требует. Разве что на ЭМС. Да и не так уж страшен черт, как нам его малюют. Первые разы тяжело — потом привыкаешь. А аутсорсинг прототипов (как, собственно и всей разработки) — ну что Вы хотите. Хорошо что хоть до кого-то дошла сама глупость такой постановки вопроса.
Так почему бы и не похвалить авторов? Ну а на некоторые недостатки в комментариях уже указали. И Вы, lingvo, и kababok, и lelik363 и многие другие. А вот то, что на хабре есть не только прикладники меня радует. Хоть знать буду «коллег по цеху».
Впрочем, не думаю что хоть кто-то смог бы написать сильно лучше. Все же каждая компания, занимающаяся встраиваемыми системами уникальна и неповторима. У каждой своя методология разработки. Да что компания — по сути каждый проект уникален.
Понимаете тут все довольно человеко-ориентировано. Допустим Ваша задача решена на Go и необходима строго ее мобильная версия. Тогда можно думать в таком ключе. Но если задачу еще только предстоит решить, то с учетом ограниченности ресурсов (а уж поверьте, их всегда и всем мало) лучше брать более низкоуровневые языки. Даже больше — если можно обойтись без плюсов, лучше обходиться. Выкидывать все новомодные штучки и вспоминать о такой замечательной вещи как Unix-way.
Впрочем, python прополз и в этот мир. Думаю, что рано или поздно прикладники и здесь начнут диктовать свои условия. Потенциально даже исключать системщиков как лишнее звено между собой и схемотехниками. Во всяком случае есть некоторые сигналы, говорящие о том что такой расклад совсем не выглядит «страшной сказкой на ночь».
Но это позже. А пока разве что Rust способен что-то противопоставить C и C++. Но, «поверьте, здесь не все так однозначно» (с) Впрочем, темой Rust я с подачи Habr'а сам только недавно озадачился. Пока считаю что нет смысла писать на Rust как на C, когда есть непосредственно С. Впрочем, когда-то я тоже самое говорил про ассемблер. Потому ограничусь тем, что "… но это не точно" (с)
Но посыл Ваш абсолютно правильный. Не при каких обстоятельствах нельзя называть конкретные сроки для абстрактного проекта. Впрочем, думаю что автор статьи это тоже прекрасно понимает.
Накинулись на Вас. По мне напрасно накинулись. Увы, реали таковы что часть комплектующих иногда приходится ждать и пол года. Такова она — доля разработчиков реальных железок. И конечно, этот прискорбный факт отодвигает момент получения прототипа.
С другой стороны, ведь Вы и Yandex под прототипом понимаете разные вещи. С позиции автора статьи — прототип это железка, позволяющая начать реализовывать и отлаживать ПО. При чем по большей части прикладное. Для Вас прототип — это первая (если хотите отладочная) плата. По сути и то и другое можно назвать прототипом.
Впрочем, согласен. Из статьи разница между EVT, DVT и PVT совершенна не очевидна. Или слишком сложно, или слишком просто — но в любом случае оставляет очень много простора для домыслов. И еще — никто ведь не говорит, что не может быть, допустим, DVT rev1, rev2, revN. Разработка (особенно связанная с железом) — это не производство по готовой документации. Мало что удается сделать с первой попытки.
С одной стороны — безусловно. Если конечное изделие будет крайне ограничено в ресурсах, то чем быстрее эти ограничения станут очевидными тем лучше.
С другой стороны есть вопрос удобства отладки как ПО, так и взаимодействия с окружающим миром. Все же внутрисхемная отладка — это скорее прерогатива системщиков. А подавляющее большинство кода так или иначе пишется прикладниками. Особенно это касается сложных решений. Там системная составляющая сильно меньше прикладной. Опять же — нельзя впадать в крайности. А то прецеденты запуска PostgreSQL сервера c NAND & UBIFS конечно были. И это даже работало, но… По вполне понятным причинам ни на одном собеседовании я не стану упоминать об этом решении.
Подводя некую черту могу заметить что прототип и конечное изделие не обязаны быть максимально похожими. Это разные стадии проектирования с разными задачами. Однако, если всех заинтересованных устраивает прототип близкий к финальному изделию — то это один из лучших вариантов.
Но не кажется Вам, что процесс разработки крайне сложно поддается алгоритмизации? Не все можно отмакетировать на коммерческих платах. Не всегда стоит думать о массовом производстве (уже не говоря о том, что массовое производство у каждой компании разное). Более того, в подавляющем большинстве случаев, если это можно отмакетировать на RaspberryPI или ее аналогах, то это можно и на обычном ПК. При этом на ПК удобнее и пользы будет сильно больше.
И, раз уж у Вас есть время писать статьи — можно просьбу. Доведите до широкой публики подводные камни разных накопителецй информации. Serial/Parallel Flash (NOR/NAND), QSPI Flash, (e)MMC/SecureDigital, (m)SATA. А то надоело каждый раз рассказывать одно и тоже. А сам не напишу.
Это все Вам не в упрек, а просто мысли от человека который всю жизнь занимался разработкой в разных компаниях. И, безусловно, основные мысли абсолютно правильны и справедливы.
Молодцы производители. Во время одумались.
Главная проблема-то в чем? Разве в качестве звука? Нееет. Главная проблема в том, что музыку перестали покупать. А зачем — раз купил и на века. То ли дело касеты. Пару сотен раз послушал — скрипит и пердит. А еще пленку и зажевать может. А винил еще лучше — после десятого прослушивания иглой дорожки разбиваются. Хочешь не хочешь а новую купишь.
Пора, давно пора возрождать источники бабла, которые так неудачно были профуканы. Потому в пору пускать статьи о «плохом» цифровом звуке с его погрешностью дискретизации, и про кодеки, которые и без того плохую цифру делают еще хуже. Так что молодцы. Все правильно.
Тег «сарказм» здесь закрывается.
А что до второго утверждения, то… Знаете, по моему вам надо попробовать уехать из города. Совсем. И далеко. На месяц. Реально в тайгу, где из света фонарик (на крайний случай генератор). Я ведь Вас не убежу, что и современный мир вполне себе сможет обойтись без цифровых технологий. Вас убедит только увиденное своими глазами. Есть множество областей, где IT не нужен. Совсем и абсолютно. Поищите фильм «Байкал. 180 дней одиночества». Француз молодец. Без лишних ужасов и чернухи и весьма правдиво. Съездите в деревню. Летом помахайте косой, зимой топором или пешней. Да та же рыбалка только в городе, где рыба под прессом рыболовов, требует эхолотов или чего-то такого. А садоводство или плодо- овощеводство? А физкультура и спорт? А моделизм в конце-концов? Астрономия? Bird Watching? Аквариумистика и террариумистика? Литература? Театр? Танцы? Да мало ли где еще… Практически везде если и есть IT, то они играют даже не вторую, а десятую роль. Замыкаться строго на IT — значит всеми силами идти к выгоранию, а потенциально и к депрессии.
Впрочем, все это здесь это уже мохнатый оффтопик. В любом случае Ваша жизнь — это целиком и полностью Ваша зона ответственности. И только Вам решать где работать, и какие хобби иметь.
По сути — мало этого. Чем больше овладеваешь навыком бить задачи и решать их по частям тем больше тебе их сваливается. И так продолжается до тех пор, пока поток задачь не превышает твои возможности. И вот тут, как только ты не справляешься, тебе дают послабление и возможность завершить начатое прежде чем подкинут нового. В итоге все равно всегда на пределе. Одна из причин проблем именно в этом. До 40 лет проблем не было. Организм справлялся. Теперь стало сильно хуже.
Подумаю на счет книги. Но что-то мне подсказывает, что для меня она будет достаточно бесполезной…