Comments 243
CLion проект ПО для одной встраиваемой системы; проект собирается из чуть более чем ста тысяч строк кода.
Я так понял, это без учёта библиотек? Нехило так… Quake II содержит 136000 строк.
Это довольно большой проект для встраиваемой системы, да, но суть не в этом. Этим примером я иллюстрирую типичное соотношение сложности бизнес-логики и низкоуровневой части в сложных проектах.
Весь код на одном микроконтроллере выполняется?
Примерно вот это: https://habr.com/ru/company/npf_vektor/blog/367653/. Да, на одном микроконтроллере.
Есть местная специфика.
¯\_(ツ)_/¯
Чтобы вы получили какое-то представление: Dyad содержит 193k строк кода, все на С++. Doom 3 — 601k, Quake III — 229k и Quake II — 136k. Это большие проекты.
И я честно не представляю, что можно сделать чистыми 2.5 миллионами строк кода в относительно рядовом проекте на Qt.
Я, если честно, утратил нить дискуссии к этому моменту. Вы хотите, чтобы я код выложил, или подробно рассказал о его устройстве? Это проприетарный продукт. Однако, с моим опенсорсным кодом вы можете ознакомиться на том же гитхабе. Я не ожидал, что упоминание сложных эмбедов привлечёт столько внимания.
А кстати, этот 100k+ для какого микроконтроллера и в какой по размеру бинарник компилируется?
В конце концов, в том же SQLite 150к строк кода, и 92 миллиона (!) строк кода в тестах.
Тестов, конечно, у Quake-II нет, но основная программа того же порядка.
92 миллиона строк — это с дампами баз для нагрузочного тестирования?
Почему вы думаете, что Quake iI это очень сложная программа? Это узкоспециализированное пользовательское приложение, да еще и не имеющее никакого отношения к встраиваевым системам.
Я, честно говоря, никогда не работал в компаниях, где в репозиториях было бы меньше 50-100 строк кода. В иных бывали и миллионы.
В иных бывали и миллионы.
Во, вот тут подробнее. Что делает программа в миллионы строк кода? Я знаю несколько таких программ и там объём вызван, например, большим количеством поддерживаемого оборудования (сиречь, драйвера для всего), кодеков и прочих подобным.
Ага. Вместе с тем, Кармаку далеко до достижений Кнута. Только какое отношение ваш кумир к разработке встраиваемых систем? Не умаляю его заслуг, но надо быть реалистичным: коробочные игры, тем более 90-х, не могли быть большими — тогда не было ни современных бюджетов, ни времени, ни размеров команд. Это как бывший игродел я вам говорю.
Что делает программа в миллионы строк кода?
Миллион это бывает, когда:
- Реализуется многослойная бизнес-логика, скажем, документооборота в больших организациях.
- Логика интеграции подсистем.
- Долгоживущие системы часто тянут с собой код для поддержки обратной совместимости.
- Сложные интерфейсы с кучей хитрой логики быстро раздувают код.
- И да, бывает надо поддерживать много разнородного железа.
Ничего этого, замечу, не было в играх 90-х: ни обратной совместимости, ни сложных интерфейсов, ни сотен-тысяч поддерживаемых железок, ни развитой логики.
То есть это ни Linux (10+ млн), ни Емакс (2+ млн), ни GCC (10+ млн). Любая из популярных открытых реляционных БД будет за миллион. Вот я посмотрел один из наших корпоративных репозов и увидел 10+ млн строк кода. Работал когда-то давно над онлайн-игрой, там в монорепозитории было сильно больше миллиона.
Я не во всем согласен с автором статьи выше, но ключевая идея у него очень даже понятная: он указывает на то, что многие разработки для малых систем перестали быть малыми, но так и не усвоили правила разработки крупных систем, с их обязательными каскадами тестов и оформлению самого кода.
Только какое отношение ваш кумир к разработке встраиваемых систем?
А вы точно читали оригинальный тезис? Вопрос стоял о том, откуда во встраиваемой системе 100k+ строк, если даже в сложной игре типа Quake-II их 136k. Автор, кстати, так и не ответил, для какого микроконтроллера (!) этот код и какого объёма бинарник получается. А вот вы дальше с чего-то решили, что Quake-II не показатель сложности, на что я вам указал, что таки показатель. Теперь вы опять сослались на встраиваемые системы и роль в них Кармака.
Миллион это бывает, когда:
Итак, что именно делает такая программа?
Любая из популярных открытых реляционных БД будет за миллион.
А давайте-ка тесты считать не будем. Тесты можно раздуть хоть до миллиарда. Полезный функционал сколько занимает?
он указывает на то, что многие разработки для малых систем перестали быть малыми,
Вот как только он объяснит, как он умудрился в 100k+ сделать управление двигателями (со всеми протоколами и прочим) и запихнуть всё это в микроконтроллер, вот тогда и поверю. А пока нам рассказывают о задаче явно не соответствующей количеству строк.
Я не понимаю, откуда мнение что Quake II сложная программа. Она очень даже простенькая. Ну да, там есть всякие трюки, но приложене прям "сложным" от этого не становится. Не умаляя заслуг Кармака конечно.
Quake II написана за год 3 людьми. Сравните с приложенеим которое пишут 30 людей и не год а пять. А если брать не встраиваемые системы, а тот "бекенд" которы автор выше упоминает, то там пропорции бывают 300 разработчиков на 10+ лет
то там пропорции бывают 300 разработчиков на 10+ лет
Я тоже не понимаю, чего в науке сложного? Миллионы учёных, а нобелевку единицы получают.
Ну так в чём дело? Напишите. Просто напишите.
Спервадобейся? Я уже сказал, что сложные приложения пишутся группой разработчиков. Каждого отдельно выдерни — кваку он наверное не напишет. Только что это доказывает?
Я тоже не понимаю, чего в науке сложного? Миллионы учёных, а нобелевку единицы получают.
То есть квейк у вас сложнее постгреса какого-нибудь я правильно понимаю? :) Или что это за аналогия такая?
Спервадобейся? Я уже сказал, что сложные приложения пишутся группой разработчиков.
Странно, а оценку вы всё-таки сделали. ;)
Не ваши ли слова выше «Она очень даже простенькая.» и «Quake II написана за год 3 людьми»? Ну так там и писать-то нечего. ;) Осилите? Я вот некое подобие DooM написал с нуля 19 лет назад, но у меня была книжка, где всё-всё было расписано. А без книжки хрен бы я чего сделал.
То есть квейк у вас сложнее постгреса какого-нибудь я правильно понимаю? :) Или что это за аналогия такая?
Это аналогия такая, что миллион обезьян не заменит одного высококвалифицированного специалиста.
Не ваши ли слова выше «Она очень даже простенькая.» и «Quake II написана за год 3 людьми»? Ну так там и писать-то нечего. ;)
А в чем проблема? Это просто 3 человекогода. Это очень небольшой объем работ по нынешним меркам, о чем тут ещё спорить?
Это аналогия такая, что миллион обезьян не заменит одного высококвалифицированного специалиста.
Надо полагать все крупные продукты написаны обезъянами, и нормальных квалифицированных специалистов там отродясь не было.
А в чем проблема? Это просто 3 человекогода. Это очень небольшой объем работ по нынешним меркам, о чем тут ещё спорить?
А при чём тут объем работ? Речь шла о сложности. Так возьмите ту же электродинамику — объём работ там небольшой, но вы формул не выведете. То отдельные гении выводили.
Надо полагать все крупные продукты написаны обезъянами, и нормальных квалифицированных специалистов там отродясь не было.
То-то я смотрю уже 20 лет читаешь, что функционал тот же по сути, а ПО раздулось до невозможности. ;)
Только какое отношение ваш кумир к разработке встраиваемых систем?Прямое. Он делал софт для ракет. См. Armadillo Aerospace.
Это узкоспециализированное пользовательское приложение
Встраиваемые приложения как правило все узкоспециализированные. В нынешние времена, конечно, можно не удивляться встретив веб браузер в утюге, но его для этого конкретного утюга никто писать не будет по простой банальной причине — покупатель утюга столько работы программиста оплачивать не будет.
никогда не работал в компаниях, где в репозиториях было бы меньше 50-100 строк кода
50-100к имеется в виду?
встраиваемых приложений?
Когда начинаете реализовывать требования — оно все и вылезает.
У нас вот например 70 микросервисов, размер каждого не очень большой — в среднем 10 kloc. Но суммарно дают почти миллион строк кода, да.
И там логики-то не так уж много: почитали что-то откуда-то, что-то сделали. в очередь сообщение кинули. Но с миру по нитке — и куча кода готово.
"Особой" логики там нет, да. Но нюансов всегда дофига. Можно почитать у брукса, разница между программой и программным продуктом примерно такая же.
Сделать MVP "крутая игра которая идет с такими-то ограничениями" это одно. Сделать так, чтобы можно было годами (десятилетиями?) её дорабатывать, чтобы запускалось на всем нужном железе, чтобы всякие метрики можно было снимать, чтобы падения были по возможности мягкими....
Ну вот просто посмотрине на Linux, сколько там миллионов строк кода? И логики там тоже не сверх много: MVP операционок на хакатоне за день пишут. Но линукс у них за день почему-то не выходит никак.
«Особой» логики там нет, да. Но нюансов всегда дофига.Ну а в кваке есть и особая логика, и дофига нюансов, и куча взаимодействующих подсистем.
Чего там нет — так это абстракций на абстракциях, развесистых деревьев зависимостей, сотен-тысяч сторонних библиотек, принятых в современном бэкэнде. Об этом собственно и речь.
Может быть и в эмбеде вышеописанное не надо?
Чего там нет — так это абстракций на абстракциях, развесистых деревьев зависимостей, сотен-тысяч сторонних библиотек, принятых в современном бэкэнде. Об этом собственно и речь.
очень абстрактно все, давайте конкретно. Линукс это получается "абстракции на абстракциях"? И можно сделать на порядок проще? Надо бы линусу наверное пару десятков эмбедщиков нанять, срезали бы количество кода в 10 раз, а качество только поднялось бы.
Или все же абстракции и библиотеки берутся не на ровном месте? Особенно радует противопоставление им — выходит, писать велосипеды направо и налево правильный выбор?
Линукс это получается «абстракции на абстракциях»?Я не линукс ругаю, а современный энтерпрайз-бекэнд.
Его можно сделать проще, да. Избавившись от конструкций в виде «метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, в котором пять строчек полезного кода». (я утрирую, но, надеюсь, смысл понятен)
Ключевой момент любой работы — целеполагание. Начав руководить проектами, я настолько иначе стал смотреть на это, что упомянутый ниже пример про ракету, многократные прогоны, простую логику, некачественный код и транспарант «ОТКАЗ» на любой чих — не вызывает никакого удивления. Это хорошо и нормально, если соответствует целеполаганию. Мне трудно без смеха говорить о том, какому именно целеполаганию соответствуют отсылки на количество строк кода (и чем их больше — тем круче), но я точно знаю, что бизнес об этом не просил.
Особенно важно это понимание для системного архитектора. Лучшая программа — та, которую не написали. Программист обычно рассуждает иначе, даже если он синиор, у него просто другая работа.
Если любить абстракции и сторонние библиотеки, то и без куте можно стотыщ набрать легко и быстро.
Абсолютно верно. При этом на решаемую задачу это никак не влияет.
>Особенно важно это понимание для системного архитектора. Лучшая программа — та, которую не написали.
я бы сказал иначе, в большом числе случаев наиболее сложная часть проектирования — это грамотное переиспользование кода, не всегда было так, конечно, но сейчас пожалуй именно это самое трудное, мне тоже требовалось подолгу выдавать в день порядка 2k lines of code, особым достижением это не считаю, зависит от знания функциональной области, в конкретном случае это были протоколы, типа берешь соответствующую rfc, строишь state machine и поехали, пишется с нуля, и ни от чего кроме спецификации не зависит, но на порядок сложнее использование всевозможных asic specific sdk, их стыковка с другими пакетами функционального sw, это требует более высокой квалификации в том числе от архитектора, причем никакой абстрацией этого не заменишь, необходимо детальное знание продуктов, либо оно есть — тогда вы полезны, либо его нет, время на изучение это накладные расходы, и его как правило нет, примерно так работают программисты, по крайней мере то что приходились видеть там где работал на востоке us, что бы все сделать четко и быстро на работу и берут опытного архитектора
«Измерение производительности программного обеспечения по строкам кода похоже на измерение прогресса на самолете по его весу», - Билл Гейтс.
Количеством строк менеджерам легко оценивать абстрактное количество вложенного труда в проект. Отличать крупный проект от мелкого. И то ведь, это, опять же, очень относительно. А в техническом плане от этой метрики какой толк?
Лично мое мнение — чем меньше строк, тем лучше реализация. Ту же банальную сортировку можно сделать и в 100 строк и в две… Я думаю, показатель — краткость и элегантность кода. Возможно, в современном мире не так, но хочется верить в светлое
чем меньше строк, тем лучше реализация.не стану отрицать, что тут возможна корреляция. И если есть причинно-следственная связь, то скорее такого толка, что люди пишущие короткий код, имеют очень острый ум. Поэтому и код лучше. Т.е. сильные программисты пишут хорошие реализации. И сильным программистам свойственно писать коротко. Такая вот взаимосвязь вполне может быть.
Проблема только в том, что читают этот код потом люди с заурядными способностями.
Я думаю, показатель — краткость и элегантность кода.Вообще странно, что программисты говорят об элегантности, но при этом элегантости на их взгляд, хотя она определяется только третьим лицом.
Красиво не когда нравится тебе, а когда нравится многим.
Кутюрье выставляют свои платья на показ. Художники выставляют картины. Музыканты выступают с концертами. Публика определяет, что классно, а что так-себе. Конечно, у создателя может быть свое мнение. Лишь бы оно не ограничивалось самомнением.
P.S.: Надо, по аналогии с кинематографом, выпускать публичную версию кода и «режиссерскую» :D
Ту же банальную сортировку можно сделать и в 100 строк и в две
Если результат по скорости и памяти будет одинаковый — конечно лучше в две. Но это фантастика. Иначе бы все вместо quick/mergesort-ов сортировали пузырьком...
И часто бывает что более длинный код более читаем. Я насмотрелся в своё время скриптов на Перле где всё делалось через контекстную переменную… понять что там происходит нереально, даже если ты сам это написал :)
… конечно лучше в две.
Ну, строки могут быть разной длины )
Зато в 2 строчки можно заимпортировать уже готовый крутейший алгоритм сортировки. Какой-нибудь тимсорт правильно реализовывать заманаешься, а тут все готовое. Можно конечно схалявить и написать медленный квиксорт, но не факт что так правильнее.
Конечно, в 99% лучше использовать встроенную в стандартную либу сортировку, если таковая имеется. Скорее всего она good enough.
И под капотом там, вероятно, будет несколько алгоритмов, выбираемых динамически либо в compile-time либо в run-time в зависимости от размера массива, архитектуры и т.п.
Есть исключения, но если у тебя именно тот случай — то ты скорее всего уже об этом знаешь :) Особенно это касается сортировки очень больших массивов данных.
Но тут речь то именно про реальный код в <10 адекватных строк или в >100 допустим. И вполне возможно как раз в более длинном коде можно учесть всякие особые случаи, например в случае той же сортировки, для массива <20 элементов юзать insertion sort.
Код для векторного управления полностью помещается на экране монитора — примерно 30 строчек. Сам алгоритм простой как тапок, и он должен работать в реальном времени. Всё что для него требуется — занимает в флеше 60к, в памяти примерно 4к.
Умеет вращать от нуля до номинала, работать как серводвигатель.
100к сток кода там нафиг не требуется, двигатель на воде работать не будет.
Я очень рад, что вы знакомы в общих чертах с алгоритмом векторного управления, честно. Однако, запись формулы отличается от законченного продукта примерно как теория отличается от практики. Ваш ответ заставляет меня заподозрить, что с практическими внедрениями с корректной обработкой граничных случаев, вспомогательными режимами, коммуникационными протоколами, тестами, и т.п. вы никогда не сталкивались, иначе не писали бы здесь про один экран. Зачем вы это написали вообще? Что хотели сказать?
Вы либо дилетант, либо космически толстый тролль. Как можно пытаться оценить сложность реализации системы, не зная о ней абсолютно ничего кроме того, что она как-то связана с векторным управлением?
Я смотрю на ваши комментарии в профиле и недоумеваю, вы с двача сюда пришли что ли? Здесь собираются более-менее адекватные люди в основном, обратите внимание.
Как можно пытаться оценить сложность реализации системы, не зная о ней абсолютно ничего
Всего лишь опустился на твой уровень, где ты заявляешь об отсутствии компетенции собеседника, ничего не зная о нём, чтобы принизить его мнение.
кроме того, что она как-то связана с векторным управлением?
В контроллере управления двигателем не будет крутиться СУБД или рендериться изображение. Тебе несколько раз намекнули, что объём кода великоват для контроллера двигателя, а в ответ только «вы дилетанты и не шарите».
Здесь собираются более-менее адекватные люди в основном, обратите внимание.
Тогда что ты тут делаешь, рекламщик?
Однако, запись формулы отличается от законченного продукта
Академические формулы которые описывают работу двигателя — не определяют его состояния в нужный вам момент, они общие, вообще для всего диапазона состояний. Они настолько далеки от практического применения — что не имеет смысла на них тратить время.
Мотор вообще очень простая штука, полностью аналоговая модель прекрасно его замещает. По этой причине нет смысла усложнять алгоритм, достаточно добиться приближения к аналоговой модели замещения.
Насчёт протоколов тоже мудрить нет смысла. Чем проще -тем надёжнее работа.
Насчёт тестов порадовали…
Ну невозможно как-либо производить отладку реально работающего двигателя. Даже если вас не убьёт потенциалом нуля горячего шасси — это сделает сам двигатель, когда вы остановите программу.
Я уже написал про модель замещения, вот на её эмуляции и выполняется отладка — там можно останавливаться и курить.
Это верно, я даже больше скажу: если бы она была написана как предлагается в статье, idSoftware обанкротились бы ещё до выхода продукта. Инструменты и методы подбираются сообразно задаче.
number-none.com/blow/john_carmack_on_inlined_code.html
The flight control code for the Armadillo rockets is only a few thousand lines of code
Кармак молодец вообще, серьёзно. Только к дискуссии это какое отношение имеет? Когда Кармак пишет Quake, он использует одну методологию, предпочитая скорость разработки качеству продукта. Когда Кармак пишет софт для ракеты, он использует другую методологию, инвестируя в качество в ущерб скорости, потому что он понимает, что баланс риска совершенно иной.
Что вы хотите сказать вашим комментарием?
Когда Кармак пишет Quake, он использует одну методологию, предпочитая скорость разработки качеству продукта.Я немного читал код движков id-шных игр, и он на голову выше практически вообще всего, что я видел, по качеству. Да и предпосылок для того, чтобы софт для ракеты был как-то принципиально по-другому написан, по сравнению с движком кваки, особых нет.
предпосылок для того, чтобы софт для ракеты был как-то принципиально по-другому написан, по сравнению с движком кваки, особых нет
Вы согласны с тем, что разные вводные могут повлечь разные подходы к реализации? В плане интересов бизнеса, единичный отказ движка Quake обойдётся компании в несколько порядков меньшую сумму, чем единичный отказ ракеты. Усилия по снижению вероятности отказа стоят времени инженерного персонала. Следовательно, разумное управление рисками предписывает, что на контроль качества Quake необходимо затратить меньше ресурсов, чем на аналогичные процессы в разработке ракеты, иначе будет иметь место неоптимальное распределение ресурсов. Вы согласны с этим?
Где-то ,возможно здесь, прочитал принцип современной разаботки -" зачем разрабатывать это одному 2 месяца , если это можно разработать командой из 12 человек за год?" это бизнес - ничего личного ...думаю хороший пм может обосновать для заказчика необходимость абстракции на случай нападения фиолетовых инопланетян... И протестировать надо, что если мы положили в правый карман джинсов телефон, то не достанем оттуда дохлого кота)
Следовательно, разумное управление рисками предписывает, что на контроль качества Quake необходимо затратить меньше ресурсов, чем на аналогичные процессы в разработке ракеты,
Так получилось, что я знаком с разработкой очередной ракеты (которая оружие судного дня). Так вот, могу вам со всей уверенностью сообщить, что квалификация персонала в части архитектуры там ну очень низкая, а от кода и продуманности взаимодействия компонентов между собой у вас выпадут все волосы. Кстати, нужный результат достигается очень многократными проверками и прогонами одной и той же цепочки команд с ручным отслеживанием отказов. При этом 100 k строк кода там и в помине нет, а работа программы, обычно, весьма линейна (а вот математика может быть весьма сложна, но это только математика) и в случае чего просто сообщается «отказ» и на этом всё.
Мне кажется, что Вам стоит почистить ваш комментарий, особенно если он про РФ, вероятно он немного нарушает некоторые законы, причём не административные.
А то слишком много печальных историй было последнее время в этом ключе... :/
Ну... Если бы я проектировал документы про государственную тайну, вероятно, я бы отнёс заявление о том, что ты имеешь к ней отношение под гриф государственной тайны, в случае если это не публичная информация.
Возможно, мой внутренний параноик, слишком параноик. :)
Вот если бы он признался в участии в разработках напалма или иного запрещенного вооружения, даже без подробностей, тогда точно нарушение.
Да и предпосылок для того, чтобы софт для ракеты был как-то принципиально по-другому написан, по сравнению с движком кваки, особых нет.
habr.com/ru/post/307394
Да и предпосылок для того, чтобы софт для ракеты был как-то принципиально по-другому написан, по сравнению с движком кваки, особых нет.ракета с распрыжкой — звучит странно, но круто…
Вот у меня на соседнем рабочем столе открыт в CLion проект ПО для одной встраиваемой системы; проект собирается из чуть более чем ста тысяч строк кода.
Господи. Какой мизер. У нас последние 5 лет, что не проект прошивки, то полтора... два миллиона строк кода.
А драйверы для микроконтроллерной периферии от чипвендоров вы видели? Мысль о том, что они работают в реальных продуктах не даёт мне спать по ночам.
Конечно, ведь иногда есть драйверы от вендора ОС, либо свои доморощенные.
Не видел, если честно…
Обратите внимание на RTEMS, NuttX, ChibiOS. Ещё, вероятно, драйверы поставляются с Zephyr, но я лично дела с ней не имел.
Не ну можно конечно, но зачем, если есть от чипвендора...
См. дискуссию выше. Драйверы, например, от Microchip, для их Automotive микроконтроллеров не подвергаются никакому контролю качества. То же самое можно сказать о популярном здесь ST Microelectronics. Если вы делаете сертифицируемый продукт, использовать эти драйверы вы всё равно, скорее всего, не сможете. Если вы делаете обычный продукт, то даже в этом случае использование кода с крайне высокой плотностью ошибок не оправдает экономии, если только продукт не совсем простой (об этом оговорка в начале статьи).
То же самое можно сказать о популярном здесь ST Microelectronics.А это тогда что?
Я, конечно, не настоящий сварщик, но весь софт, который я видел от чипвендоров (в моём случае это всякие штуки, связанные с сетями) — это между "ужас, на ночь не читать" и "этим пытать можно". Такое впечатление, что отбор туда проходит по признаку "не умеет программировать — айда к нам".
V-модель это методология разработки и управления проектом. Симулинк это инструмент реализации. Эти вещи никак не связаны. Даже если ваш код генерирует симулинк, это не отменяет потребности в формировании проектных требований с последующей валидацией и верификацией. Не следует думать, что V-модель куда-то ушла, она по-прежнему применяется при разработке ответственных систем. Например, обратите внимание на процесс сертификации DO-178.
Интересно много ли эмбедеров разрабатывают архитектуру и детальную архитектуру? Хотя надо сказать, что без архитектуры на функциональную безопасность сертификат не получишь, поэтому там V-модель обязательна.
И да, полностью согласен с рекомендациями.
Возможно, хотя бы часть этих проблем можно решить банальным изменением отношения к вопросу. Просто сейчас точка зрения, которой делится 0FFH в комментарии ниже — что софт дело десятое, нам бы железку собрать — достаточно распространена, к сожалению. Именно здесь видится целесообразным применение упомянутых мною там же просветительских методов.
Технический долг (в отношении кодовой базы) не является вымыслом прикладников, это вполне реальная вещь, игнорирование которой порождает пресловутые "драйверы от чипвендоров", что не выдерживают никакой критики.
Я был во многих крупных проектах в эмбеддинге и там, где был грамотно выстроен процесс разработки и ресурсы позволяли, везде была вполне сносная архитектура кода, которая позволяла параллельно работать десяткам и сотням людей над проектом.
Ну а если ресурсов хватает лишь на одного человека на полставки, то немудрено, что код будет тяп-ляп и готово.
Разработчики встраиваемых систем не умеют программировать
а что вы подразумеваете под программированием?
разработчик встроенных систем в первую очередь — электронщик электрик механик — и уж затем вишенка на тортике — программист
причем если берем сферу микроконтроллеров — то там царит язык Си.
я много писал на Си для микроконтроллеров — там вообще не было работы с файлами.
это кардинально отличается от общего программирования — где работа с файлами — это главное.
и я еще помню времена в 90ых когда спорили что лучше Си или ассемблер
потому что процесоры работали на единицах мегагерц а с учетом количества тактов на операцию их реальное быстродействие было меньше 100 000 операций в секунду.
что как бы и хватает для механики ( станков и промоборудования ) — но маловато для работы с электронными сигналами. поэтому в то время та сфера полностью обходилась минималистическими средствами программирования.
во втором десятилетии 21 века микроконтроллеры перешагнули 100 мгц тактовой да еще с учетом что теперь часто операция выполняется за 1-2 такта — уже стали иметь место физические ограничения по вводу выводу. как известно сигналы больше 10-15 мгц уже требуют не тривиальной разводки и борьбы с помехами. с одной стороны чудовищно расширился круг возможностей микроконтроллеров — с другой стороны стремление упрощения программирования и туда пришло. скажем здравствуй языку питон — который пришел в микроконтроллеры — очень медленный язык но кому то очень удобный.
или — если можно забивать гвозди микроскопом — то почему бы этого не делать?
молотков мало ( медленных микроконтроллеров) а микроскопов много — (stm32).
и стоят микроскопы stm32 уже дешевле молотков 8051 произведенных микрочипом.
как человек много лет программировавший встроенную электронику — скажу — я заново учусь программированию когда пишу для вэб.
программирование встройки и вэба имеют столько же общего как профессия штурмана в авиации и мореплавании.
и там и там одинаковое штурманское дело — но с разными концепциями применения
разработчик встроенных систем в первую очередь — электронщик электрик механик — и уж затем вишенка на тортике — программист
Это могло быть так до тех пор, пока ПО не стало в достаточной мере, если можно так выразиться, "системоопределяющим" (как инверсия термина "программно-определяемая система"). Учитывая роль ПО в современных продуктах, нельзя рассматривать эту дисциплину как придаток прочих процессов проектирования — баланс сместился. Впрочем, я не умаляю важности работы электронщиков и механиков.
программирование встройки и вэба имеют столько же общего как профессия штурмана в авиации и мореплавании.
Это может быть правдой, но это не означает, что разумное заимствование уместных практик из одного в другое не должно иметь места. Проблема в том, что рядовой эмбедер (основываясь исключительно на личном опыте) не видит разницы между интерфейсом и полиморфным классом, и не понимает, зачем нужно метапрограммирование, если есть void*. С этим следует бороться просветительскими методами.
Это могло быть так до тех пор, пока ПО не стало в достаточной мере, если можно так выразиться, «системоопределяющим»
людей пишущих софт для радаров или самолетов или аэс- мизер.
а людей пишущих софт для тнп и промышленного оборудования — весь остальной мир.
то есть все те премудрости стандартов MIL-XXXX — в промке и тнп — не нужны.
я вот сам занимаюсь попыткой все в жизни делать в вэб после смерти windows XP — но и там слишком много телодвижений чтоб сделать простые вещи.
современное программирование слишком увлеклось инкапсуляцией реальности
Есть очень простой тест на умение программировать. Он конечно шуточный, но тем не менее. Если программист умеет читать и разбираться в чужом коде, то да, умеет.
К сожалению чаще всего эмбедеры не могут читать чужой код ну и свой пишут так что никто кроме них его не понимает.
а соревнования по запутанному коду — проходят на си.
поэтому я например когда разбирался с чужим кодом на си по обработке сигналов — очень про себя матюгался — люди писали в стиле — один раз написано — а там пофиг.
Запутанный код это перл, но почему-то чем круче эмбедер тем меньше языков он знает )))
А вот то, что пишут один раз на отвяжись это как раз не умеют писать и чаще всего это эмбедеры.
это когда микроконтроллер выступает просто многофункциональной схемой — такое часто бывает.
там просто составляешь диаграмму работы устройства — и через паузы дергаешь ножки.
такой код — даже я спустя время свой не понимаю. потому что без описания всего устройства — его не вкурить.
еще раз говорю эмбедеры не изучают класические алгоритмы — они им не нужны.
они не манипулируют данными — они манипулируют сигналом и временем.
а на это библиотек алгоритмов нет
эмбедеры не изучают класические алгоритмы — они им не нужны.
они не манипулируют данными
Моя заметка не про этих. Я вот в начале оставил оговорку, что мои соображения применимы лишь к проектам высокой сложности. Вы напрасно вычёркиваете людей, которые занимаются реализацией сложных поведений из числа эмбедеров.
Вы напрасно вычёркиваете людей, которые занимаются реализацией сложных поведений из числа эмбедеров
я не вычеркиваю — я сразу оговорился в коментах — что рлс самолеты и аэс програмирует мало кто
всем остальным — знание сортировки пузырьком и прочего — как правило не нужно
говорю как человек поработавший и там и там
еще раз говорю эмбедеры не изучают класические алгоритмы — они им не нужны.
Это настолько прекрасный пример, как благодаря глупости и воинствующему невежеству эмбедеры плодят тонны говнокода от которого сами же страдают, что тут и добавить нечего.
они манипулируют сигналом и временем.
а на это библиотек алгоритмов нет
Конечно, же есть. Но вы ведь впм "не нужны" алгоритмы, поэтому вы об этом не знаете. Странно только, что глупость и невежество вы считаете достоинствами и даже хвастаете ими. Ну, это ваш выбор — вместо того, чтобы хоть немного хоть что-то изучить, вы живёте в вечной боли, которую сами себе создаёте ("такой код — даже я спустя время свой не понимаю").
там просто составляешь диаграмму работы устройства — и через паузы дергаешь ножки.
И если бы вы "изучали стандартные алгоритмы", то приделали бы сюда совершенно стандартную fsm, например.
Это настолько прекрасный пример, как благодаря глупости и воинствующему невежеству эмбедеры плодят тонны говнокода от которого сами же страдают, что тут и добавить нечего.
нет ничего такого
эмбеддеры как раз одержимы сделать все по минимуму
тонн говнокода у них не бывает
всегда эмбеддерам ставят в вину что они делают самолет
за это да — ругают
потому как время тоже — деньги
а гомнокодерство — это там где используют шаблоны
И если бы вы «изучали стандартные алгоритмы», то приделали бы сюда совершенно стандартную fsm, например.
самый простой пример
шаговый мотор можно подключить множеством способов.
да и шаговые моторы бывают разные
я не слыхал о универсальной библиотеке управления моторами — аналогичной STL Степанова
я не слыхал о универсальной библиотеке управления моторами — аналогичной STL Степанова
Ну вот простенькая либа для FSM https://github.com/digint/tinyfsm
(да, я знаю что сипипи, но у си в целом с либами туго).
В достаточно продвинутых системах типов у вас даже попытка перейти из состояния 1 в состояние 5 может давать ошибку компиляции (при условии что это запрещенный переход офк).
На си подключить библиотеки сложно, больно, но писать все самостоятельно по-моему ужасная альтернатива.
у си в целом с либами туго
O_o
github.com/topics/state-machine?l=c
Here are 48 public repositories
На си подключить библиотеки сложно, больно
O_o
#include "header.h"И не забыть добавить файлы с исходниками в сборку.
А в С++ не так?
А этот header.h откуда взять?
А в С++ не так?
Нет, там через vcpkg можно ставить пакеты в +- 1 строчку.
А этот header.h откуда взять?
В README.md обычно написано.
Нет, там через vcpkg можно ставить пакеты в +- 1 строчку.
#include «header.h» и добавление исходников в сборку (правка CMakeLists.txt) всё равно делается руками. И если разработчиков >1 — всегда есть вероятность, что один на свою машину установит одну версию исходников библиотеки, другой — другую, и результаты работы у них будут немного отличаться.
В README.md обычно написано.
Читать доки чтобы подключить зависимость? Извините, это и есть "с либами туго".
И если разработчиков >1 — всегда есть вероятность, что один на свою машину установит одну версию исходников библиотеки, другой — другую, и результаты работы у них будут немного отличаться.
Ну вот а с пакетниками обычно генерируется локфайл который является снапшотом всех используемых версий (ну вот например) — и ни у одного другого разработчика результат сборки отличаться не будет.
А подключение зависимостей должно выглядеть вот так:
[dependencies]
iced = {version = "0.3.0", features=["canvas"] }
rand = "0.8.3"Без readme.
Кстати, обратите внимание что в случае cfg_if по ссылке выше зарезолвились две разных версии 0.1.10 и 1.0.0. Потому что где-то в транзитивных зависимостях используется одна версия, а в других — другая. Пакетник тут за меня проблему решил, подсунув каждой зависимости ту версию, которую она ожидает. В ридми это тоже описывается или каждый раз приходится выдумывать свое решение? Или "Такого не должно быть никогда"?
В проекте на C++, если в зависимостях образовалось разные версии одной либы, это ПЦ. Когда и как оно взорвется — одному линковщику известно.
Читать доки чтобы подключить зависимость? Извините, это и есть «с либами туго».
Это и есть заголовок статьи ;) Зачем читать какие-то скучные доки, если можно поставить крыжиков в конфигураторе — и в production :D
Я так понимаю, это не С++, а совсем даже Rust ;)
В проекте на C++, если в зависимостях образовалось разные версии одной либы, это ПЦ. Когда и как оно взорвется — одному линковщику известно.
Ну вот это плохо (если мы про статическую линковку офк).
Это и есть заголовок статьи ;) Зачем читать какие-то скучные доки, если можно поставить крыжиков в конфигураторе — и в production :D
Полностью поддерживаю — вкалывать должны роботы, а быть счастлив — человек )
нет ничего такого
Так, ведь вы сами написали, что именно так пишите.
а гомнокодерство — это там где используют шаблоны
Говнокодерство — это там, где вы через месяц не понимаете того, что сами написали.
я не слыхал о универсальной библиотеке
При чём здесь универсальная библиотека, если речь шла об алгоритмах?
самый простой пример шаговый мотор
Прекрасный пример эффекта Даннинга-Крюгера.
но почему-то чем круче эмбедер тем меньше языков он знает )))
в целом в эмбедерстве — паяльником и напильником интереснее работать — чем тока клаву топтать.
это конечно мое имхо.
а в целом Си на все хватает.
на си в духе паскаля
А в чём принципиальная разница?
разработчик встроенных систем в первую очередь — электронщик электрик механик — и уж затем вишенка на тортике — программистесли для железки, разработка которой сопоставима по трудозатратам с написанием для неё кода, нанять таких вот «вишенок», пропорция из 50/50 сместится в 20/80, где большая часть этих 80 торжественно спихнется на клиентский код с формулировкой «у меня мой минимальный пример работает».
Хех, огромное спасибо, добрый человек за профессиональное дёрганье болевых точек!
И да пребудет с тобой подробный ARXML!
Заголовок, что все хххххх (отрицательная характеристика).
Пара примеров:
— И где такого работника Илью взять, чтобы всё делал правильно, вдумчиво и без какого либо описания/архитектуры/распила на слои/модули? А если всё вышеперечисленное наличествует, тогда какие проблемы с архитектурой? Скорее с архитектором.
— Начальника, который присмотрел новомодный язык, озадачиваешь вопросом стыковки и поддержки фичи/протокола, специфичного для данного проекта. Во всяком случает, последний раз такие предложения слышал лет 15 назад.
И вишенка на торте: реклама своей статьи и приглашение в сообщество, где Вас из хххххх превратят в жжж (положительная характеристика).
Вот точно — Я-Дзен.
А, Да, предлагаю написать статью по результатам рекрутинга волонтёров: сколько пришло после прочтения статьи.
Я, если начистоту, учусь у fillpackart. Но, видимо, без особого успеха.
Посмотрел uavcan. По сути, очередной встраиваемый rpc. Эмбедеры используют rpc, архитектуру на основе событий, гетерогенный компьютинг и пр., а не только лампочками моргают:-) Алгориитмы эмбедерам не нужны? Так они часто на одних только хитрых алгоритмах и структурах данных и сидят. Не надо всех под одну гребёнку, пожалуйста.
Не всегда и не везде возможно запихнуть в контроллер чисто физически все ваши 100к правильных и красивых строк кода. Хорошо, когда вы пилите электронику для БелАЗа (там есть, куда всё запихнуть). А если это маленький дрон с очень ограниченным энергообеспечением, которое хорошо бы потратить на полетное время, а не на сотни мегагерц, чтобы ваш убер-сервер по супер-пупер шине подписался на датчик и опросил бы его? Или некое носимое устройство (от которого иногда жизнь зависит), которое должно гарантированно отработать не менее скольких-то часов от какого-то, извините, говна, которое пользователь туда засунет в качестве источника питания. А приходит вот такой правильный программист, не считающий байты и говорит — не, чувак, я ногодрыгалку на двух мегагерцах не напишу. Мне тут нужна ртос, оперативы побольше и вообще линупс хочу, там всё по щелчку пальцев делается готовыми библиотеками. А есть ведь еще ограничения на бюджет всей затеи. И хорошо бы прибыль после разработки начать получать.
Так что зря вы так всех сразу в реактор. Каждому гвоздю свой микроскоп.
Ардупайлот живет на очень дохлых платформах, и тем не менее там порублено на модули все почти как надо. Соблюдение принципов приводит к тому, что все работает быстрее и устойчвее.
«Очевидные вещи говоришь» — скажет матёрый архитектор информационных систем — «Тут сервис, тут зависимость, соединили и полетели». Но в кругу встраиваемых систем эти очевидные вещи, судя по моему удручающему опыту, являются откровением, потому что опытный эмбедер подходит к решению той же проблемы совершенно иным образом: не от целей, стоящих перед системой, а от средств их достижения. Или, короче говоря: первым вопросом является не что мы делаем, а как мы это делаем.рассказывает всё о его знакомстве со встраиваемыми системами, когда зачастую вопрос «как мы это делаем», всё же главенствует над что мы делаем, или просто является неотъемлемой частью. Глупо спорить, что грамотное разбиение проекта и покрытие тестами не нужно в эмбеде. Не стоит просто столь категорично утверждать, что все проекты без таких громких слов, как «архитектура», «сервисы», «подписки» и прочих умных слов из книжек сделаны плохо. Иногда вся архитектура вырождается из-за решаемой задачи в одну функцию.
Если должно работать гарантированно и качественно — нужны тесты. Нужно считать байтики и потребление памяти. Но это можно делать грамотно не слепив все в один спагетти-модуль с большим количеством глобальных переменных. Чтобы делать абстракции бесплатными можно пользоваться статик инлайнами, макросами. И разбивка на модули потратит от силы 1% от флешки, если это сделать правильно. А то и уменьшит дублирование спагетти кода и наоборот памяти сэкономится.
Не подскажете, где взять готовые ноды для UAVCAN, типа UC4H General node ?
Берите любую ноду для v0, они аппаратно совместимы с v1. Ещё есть демоплаты для UAVCAN от NXP, но их пока нельзя купить за пределами США из-за экспортных ограничений, установленных администрацией Трампа.
(глядя на процитированную V-диаграмму) Очень, очень вредная картинка. Потому что на самом деле она должна выглядеть как символ квадратного корня с длинным-предлинным хвостиком "эксплуатация". Казалось бы разработчикам встраиваемых систем это должно быть понятнее, чем обычно. Потому что результат их работы годами может стоять там, где поставили. И никаких апдейтов не будет.
Сколько программистов могут писать функционал в течении года, и не сделать больше 3-х багов
Получится весьма и весьма небольшой процент.
Конечно, не во всех сферах так критичны баги, но там где критичны — даже не знаю, как бизнес ищет программистов. Потому что тотальное «тяп-ляп и в продакшен» повсюду.
Потому что тотальное «тяп-ляп и в продакшен» повсюду.
Так это и не от программистов зависит.
Ну или поставили задачу сделать за неделю — сделали так, как можно сделать за неделю. Отказаться выполнять за неделю? Найдут другого.
В любом случае, единственное системное решение — формализация критериев качества, которая даже если и выполняется исполнителем (что уже странно) всё равно без запроса от менеджмента никогда не произойдет.
Чаще вижу вариант, когда манагеру предлагают несколько вариантов. Какой из вариантов он обычно выбирает, полагаю, понятно.
Непонятно. Потому что когда я говорю "быстрый вариант будет иметь такие-то недостатки и так-то нам встрянет буквально через год" в достаточно большом количестве случаев одобряют медленный и правильный :shrug:
Очень жизненно! Особенно некоторые вместе с классом — боссом лепят 100 глобальных переменных. Сам эмбеддед разраб и навидался жести.
Еще некоторые терпеть не могут обёртки. Говорят, что уровни абстракции сжирают много памяти. Однако, если их правильно писать и разбить на модули, то никак больше не получается. Тупой пример: статик инлайн обёртки. Памяти едят ноль, зато можно обернуть простые конструкции в более человекочитаемые функции.
У Nordic -овских чипов довольно крутое sdk. Там хорошо разбито на модули и много трюков для дешевых абстракций используется.
Еще пример бесплатной абстракции — кастомная секция в линковщике для регистрации эвент хендлеров. И прикрыть макросами регистратор. Доп памяти требует зеро, зато можно использовать event driven парадигму и нормально разбить на модули.
Также копипаста всяких типичных вещей вымораживает. В чем проблема вынести в отдельный модуль эвентлуп, fsm, модуль очереди написать? Копипируют туда-сюда и с кучей ошибок...
На счет malloc-free, если в MCU памяти катастрофически мало, проще стат буферами гарантировать работоспособность. Да, иногда нужны какие-то аллокаторы, тут безопаснее memory pool разделённый использовать. Можно конкретному модулю так разграничить объем памяти. Допустим, сетевому модулю под буферы пакетов. Чтобы на высокой нагрузке весь хип не сожрал — выделенный мемори пул даст чёткий лимит по памяти на сетевые пакеты.
Все же поражает дробление на модули. Ну слепили все в босс-модуль, сэкономили 0.5% флешки, зато потом требуются недели чтобы понять как это работает. Вместо минут 15-ти. И тестировать нереально. А как показала моя практика — тесты позволяют ловить регрессии и меньше времени тратить на отладку. А некоторое вообще без тестов не поймать с санитайзерами.
C++ призывают воздержаться от [...] использования динамической памяти [...] malloc() и free()Одно дело malloc() и free(), а совсем другое неявные new() и delete().
В общем случае, в критически важном участке кода лучше вообще отказаться от всего лишнего, включая malloc() и free(), выделив всю необходимую память заранее.
Мы получаем законченный сетевой сервис, который предоставляет данные системы воздушных сигналовА это другая крайность. С точки зрения надежности системы лучше получать в том числе и сырую информацию с датчика. Хотя бы потому, что таких сервисов может быть несколько дублирующих. И тогда, обладая всей полнотой информации, намного проще будет разобраться, какой из них вышел из строя, если вдруг они стали выдавать различающиеся данные.
Я согласен с AVI-crak, 100 тысяч строк для привода!? Это какой то Франкенштейн. С другой стороны мне понятен разговор Spym про «специфику». Я тоже писал программу для прибора, так там сначала «а давай добавим ещё один экран,… ещё один интерфейс,… и что бы по WiFi в интернет отчёты отправлял,… и что бы на балалайке играл ...». Итого 13 тысяч строк на СИ для 8-ми битного контроллера. 13-ть тысяч !!?
А почитайте вакансии, чего там только нет. Что разделение труда осталось в каменном веке?! Или у нас Цезарей полно, способных знать на отлично 5-ть областей знаний.
Остается дописать в вакансию «умение играть на баяне будет плюсом».
По этой причине желательно чтобы архитектурой занимался тот, кто и в железе понимает и в софте.
Потом как писать софт для какого-нибудь инвертора силового киловатт на -дцать или -тьсот, не понимая физики происходящего я вообще не представляю. Имеется в виду не тупо кодить описанные кем-то другим алгоритмы, а сами эти алгоритмы и разрабатывать.
В чём проблема с пиханием C++? Я его пихал давно в attiny, полёт нормальный был.Конкретно C++ ничего, если не начинают в конструкторах делать new и оверинженирить. В устройствах с микроконтроллерами обычно переферия фиксированная и не нужно на лету подключать N экранов и клавиатур. А простые RAII с написанием «универсальной» библиотеки одного RGB светодиода не дадут впихнуть в все в прошивку.
Конечно ты не платишь за то что не используешь. Но часто приходится брать С++ библиотеку и выкидывать от туда 90%. И тогда, да, в ATtiny все помещается.
Что плохого в том, чтобы умные люди уже написали сверхкрутую-производительную-гибкую библиотеку по управлением RGB светодиодом, а нам нужно только 10% а остальное мы выкинули? Кто проиграл и в чем?
Так какой объем, мы же все выкниули? LTO=true и порядок
Т.е. если создается исключительно один объект с new в конструкторе в начале программы, то в прошивку не пойдет система управления динамической памятью?
На том же расте можно сделать no_std и тогда все библиотеки которые аллоцируют нельзя будет использовать. Но у большинства популярных библиотек самих есть свитч no_std, который позволяет использовать их подмножество в случае, если аллокатор недоступен. Но аллокатор в итоге тащить не надо.
ну так, как пример
А простые RAII с написанием «универсальной» библиотеки одного RGB светодиода не дадут впихнуть в все в прошивку.линкеры умеют выкидывать не используемые символы…
На самом деле не знаю что там как раз линкер выкинул, пример уже далеко в истории, но простое удаление конструктора и деструктора, (наверное с заменой на статические переменные) существенно уменьшили объем прошивки. Позволив добавить новые фичи.
Т.е. если создается исключительно один объект с new в конструкторе в начале программы, то в прошивку не пойдет система управления динамической памятью?если оптимизатор выкинет пару new/delete, то может и не пойдет. А вообще говорил я несколько про другое — если библиотека тянет 100 методов, а вы используете (в т.ч. рекурсивно) только 10 из них, то остальные 90 линкер должен выкинуть, если ему правильные флаги скормить.
На самом деле не знаю что там как раз линкер выкинул, пример уже далеко в истории, но простое удаление конструктора и деструктора, (наверное с заменой на статические переменные) существенно уменьшили объем прошивкиохотно верю, что удаление конструктора и деструктора могли уменьшить объем прошивки. Однако кажется странным, что впоследствии программа продолжила работать корректно.
Сами сталкиваемся с разрывом между большими (универсальными) системами и embedded. Но мне кажется Вы сгущаете краски. Да согласен программисты на MCU смотрят со стороны железа. Мы в статьях уже не один раз показывали, что есть и другие подходы для разработки в том числе и для микроконтроллеров. Но все таки большинство встроенных систем сейчас используют Linux, а следовательно и разрабатывают ПО исходя из функциональности. Например марсолет ingenuity.
С другой стороны, согласитесь, если нужно просто собрать показания от датчиков, то приведенные вами mbed и другие подобные проекты, весьма хороши. Ведь они решают поставленную бизнесом задачу, причем действиетльно быстро.
В вашем примере с Ильей и его руководителем, я бы предположил, что разработчик не достаточно точно показал где у него основная работа. Я имею в виду, что разрабатывал он прямо на железе, и мне бы как менеджеру отвественному за деньги, показалось бы что это и есть основная трудность. Другое дело если бы он разрабатывал на хосте, Вы же сами сказали, что основная сложность в бизнес логике. Тогда понятно, что предлагать mbed, как решение проблем связанных с железкой, бессмысленно.
Ваш пример с СLion, тоже стоило бы разделить на составные части, выделить HAL, хотя я конечно не знаю какая там задача. И исхожу из соображений, что если есть бизнес логика, то ее можно запустить отдельно. Если эту логику проще запустить (разработать отладить протести) прямо на железке, то наверное и разделение отпадает.
Странный вопрос: конечно монадический код проще. По крайней мере читать.
Писать наверное сложнее. Но тоже зависит от практики, с определенного порога может быть даже проще ибо либы и пачка домашних заготовок, позволяющих абстрагироваться от флоу, чего нет в языках где эффекты прозрачны и с ними никак не провзаимодействовать.
Например, что проще: когда побочные эффекты явно выражены присваиваниями глобальным переменным, или же когда они спрятаны в монаду?
Конечно же первое. Про второе не слышала половина респондентов, а из другой половины 80% не смогут в это. А проблема глобальных состояний сильно преувеличена, там типично пара-тройка логгеров, какой-нить настроечный файл/ПЗУ. Просто трудно остановиться с борьбой против двух вещей — расизма и глобальных состояний.
Ну и, кстати, да, если «им так удобно», и если конечная цель разработки достигается, то… И это ведь не только эмбеда касается. Знаете сколько я видел проектов, отнюдь не для эмбеда, где все было прелестно с точки зрения качества кода, но в целом работало примерно никак, и главное сделано было тогда, когда уже не нужно?
«Удобно» в их случае означает лишь отсутствие необходимости изучать какие-либо новые подходы и парадигмы
Во-первых не «новые», а «другие». Во-вторых вы так говорите, будто это что-то плохое, будто должно быть так — что ни день, то парадигма.
И как показывает практика, «нет ничего более постоянного, чем временное», и случаев, когда какая-то ad-hoc write-only поделка превращается в большой долгоживущий проект, на самом деле не мало
Это, как и блок текста выше — про извечную дилемму «быстро, дешево и хорошо — выберите любые
Ваш пример с UAVCAN, как и его документация, отлично вписываются в общую концепцию CAN-шины и схожих систем, где протоколл основывается на содержании сообщения (топика), и фреймворк издатель-подписчик показывает себя во всей красе. Однако та же архитектура вряд ли подойдет для систем наподобие LIN-шины, где сообщения напрямую содержат информацию о подписчике и элегантно оформить подписку на топик уже не получится.
Суть этого вопроса заключается не в том чтобы показать что «в эмбеде все очень сложно». Я лишь хочу указать на то, что ваша статья хоть и несет в себе верную мысль — сначала продумай, а потом делай, но не является при этом исчерпывающим ответом на то, где и как учиться программированию эмбедерам не использующим UAVCAN и ему подобные системы. Рекомендуете ли вы глубже изучать паттерны архитектуры? Стремиться к «чистому коду»? Или же уйти на пару годиков в веб, поучиться у матерых сеньоров и вернуться с полученными знаниями во встройку?
Я, как вы и описали в комметарии выше, знаю разницу между абстрактным и полиморфным классом лишь в теории, потому что помимо программирования уделяю чуточку времени теоретической механике, электронике, ТАУ и прочим прелестям исключительно инженерного дела. Уверен что многие разработчики эмбеда также в большей степени инженеры, отсюда и мышление «от железа». Однако мы правда хотим совершенствоваться и однажды стать полноправной частью уютного коммьюнити разработчиков софта, да так чтобы не вызывать приступов облысения у женщин и детей при виде нашего кода.
Так поделитесь же своим богатым опытом и ценным житейским советом. Как нам, молодому поколению эмбедеров (да и опытным встройщикам тоже), не позориться, не заколачивать ржавые гвозди микроскопом и стремиться к архитектурной чистоте не в пределах одной успешной системы с открытым кодом, а вообще при решении проблем, связанных с низкоуровневой разработкой? Я прекрасно понимаю что универсального рецепта для решения всех проблем нет и никогда не будет, но я уверен что у вас явно имеются ценные советы для тех, кто только начинает карьеру в данной области.
Как подходить к разработке низкоуровневых приложений, не оставляя после себя тысячи строк непонятного и неподдерживаемого кода?
Рекомендуете ли вы глубже изучать паттерны архитектуры? Стремиться к «чистому коду»? Или же уйти на пару годиков в веб, поучиться у матерых сеньоров и вернуться с полученными знаниями во встройку?
Вы, главное, не переключайтесь, и до такого поста руки рано или поздно дойдут. А если серьёзно, выше уже совершенно корректно писали, что методы проектирования софта везде плюс-минус одни, эмбеды это или нет решающего значения не имеет, теория везде одна. Практику можно получить контрибьютингом в опенсорс, заодно получите и трезвую критику своих навыков, а может даже и ценный совет.
Ваш пример с UAVCAN, как и его документация, отлично вписываются в общую концепцию CAN-шины и схожих систем, где протоколл основывается на содержании сообщения (топика), и фреймворк издатель-подписчик показывает себя во всей красе. Однако та же архитектура вряд ли подойдет для систем наподобие LIN-шины, где сообщения напрямую содержат информацию о подписчике и элегантно оформить подписку на топик уже не получится.
Вообще UAVCAN работает поверх UDP тоже, например (через мультикаст группы). Это не только про CAN.
Рекомендуете ли вы глубже изучать паттерны архитектуры? Стремиться к «чистому коду»? Или же уйти на пару годиков в веб, поучиться у матерых сеньоров и вернуться с полученными знаниями во встройку?
многое зависит от поставленных личных целей — программирование embedded systems имеет невероятно большой диапазон, соответствующий диапазону систем реального времени, чтобы писать несложные программы для pi и arduino вероятно вполне хватит ресурсов сети, по крайней мере это займет вас на несколько месяцев, и это разумеется даст больше чем «уйти на пару годиков в веб», следующее что будет полезно — это изучение embedded linux и далее например все что связано с yocto, начиная с книг типа «Mastering Embedded Linux Programming» by Chris Simmonds, возможно не лучшая книга, но .pdf нетрудно найти в сети, это займет вас еще на несколько месяцев, если в результате например вы сможете активно участвовать в проекте yocto, это даст большое преимущество в поиске уже настоящей профессиональной работы, до сих пор было про подготовку, теперь о профессиональной карьере, самый короткий путь это для начала 3-5 лет работы в хорошей известной компании, что даст начало вашему резюме, позволит узнать людей, и вообще откалиброваться, при благоприятных результатах искать работу в жизни вам больше не придется, будут звонить сами, надо также заметить, что не смотря на обилие разработок embedded systems по всему миру, максимальная концентрация до сих пор находится в us, соответственно начинать профессиональную карьеру, и учиться программированию проще всего там, теперь про всякие программные технологии — их много, они зависят от размера разрабатываемых систем, назначения и пр, в хорошей компании всему этому вы сможете научиться так сказать на лету, и по мере необходимости совершентвоваться в дальнейшем
Кроме рекламы этого UAVCAN, чё автор сказать-то хотел? Что когда мне надо по-быстрому набросать управляющую прогу под какой-нибудь восьмирёночек типа AVR'а или тот же несчастный stm32, или убогий NIOS я должен с ногами залезть в доку для какого-то раздутого фрейморка и пару месяцев курить доки, что бы в конце концов понять, что он не решает моих задач, не лезет в память и т.д.? Ну круто, чё ...
Моя скромная практика показывает, что за исключением простых устройств сложность целевой бизнес-логики приложения несопоставима с той его частью, что непосредственно работает с железом.
Русский язык порой вообще не понять.
Я так и не понял.
В какую сторону знак больше (или меньше) повёрнут?
Получается бизнес логика проще, чем та часть кода, что непосредственно работает с железом.
Так?
1--бизнес логика << часть кода, что непосредственно работает с железом
или
2--часть кода, что непосредственно работает с железом << бизнес логика
У меня, по крайней, мере чаще всего именно случай №1 наблюдался.
HAL много-много больше, чем само приложение на MCU. Чтобы самим в компании написать HAL (GPIO UART SPI и т п) надо 2-4 человеко-лет.
Смотри, что я нашёл! Есть крутая новая система, Mbed называется, значит, для эмбедеров. Гляди, как можно быстро прототипы лепить! Клац, клац, и мигалка готова! Вот же, на видео. А ты, Илья, свой алгоритм оптимизации CAN фильтров пилишь уже неделю, не дело это, давай переходить на Mbed.
У меня был тот же диалог с менеджером только вместо Mbed слово Zephyr Project.
Слово в слово.
Результат - полный провал проекта из-за Vendor Locking особенностей Zephyr Project (а).
Zephyr при инициализации так жрал батарею, что плата перезагружалась ещё до пуска потока с приложением.
Разработчики встраиваемых систем не умеют программировать