Как стать автором
Обновить

Разработчики встраиваемых систем не умеют программировать

Время на прочтение 9 мин
Количество просмотров 57K
Всего голосов 130: ↑111 и ↓19 +92
Комментарии 239

Комментарии 239

CLion проект ПО для одной встраиваемой системы; проект собирается из чуть более чем ста тысяч строк кода.


Я так понял, это без учёта библиотек? Нехило так… Quake II содержит 136000 строк.

Это довольно большой проект для встраиваемой системы, да, но суть не в этом. Этим примером я иллюстрирую типичное соотношение сложности бизнес-логики и низкоуровневой части в сложных проектах.

Очень интересно, что это за проект с такой сложностью?
Весь код на одном микроконтроллере выполняется?

Есть местная специфика.

Да ладно! У меня есть проект с 80000 строк (мой собственный) для QNX (тоже, кстати, встраиваемый почти), так там очень сильно дофига всего сделано вплоть до встроенного языка программирования. И то до 100 k я за 6 лет так и не дотянул. А классов вместе с интерфейсами там около 400 (если анализатор не врёт). А размер исполняемого файла больше 3 МБ.

¯\_(ツ)_/¯

Как юмор: знаете, когда-то я проходил собеседование в одну из дочек Газпрома и упомянул как самый большой мой проект эти самые 80000 строк, так мне там пренебрежительно фыркая сообщили о двух с половиной миллионах строк кода в проекте, написанным собеседующим (я так понял, лично). То ли они считают как-то не так, то ли сочли все-все библиотеки, но
Чтобы вы получили какое-то представление: Dyad содержит 193k строк кода, все на С++. Doom 3 — 601k, Quake III — 229k и Quake II — 136k. Это большие проекты.

И я честно не представляю, что можно сделать чистыми 2.5 миллионами строк кода в относительно рядовом проекте на Qt.

Я, если честно, утратил нить дискуссии к этому моменту. Вы хотите, чтобы я код выложил, или подробно рассказал о его устройстве? Это проприетарный продукт. Однако, с моим опенсорсным кодом вы можете ознакомиться на том же гитхабе. Я не ожидал, что упоминание сложных эмбедов привлечёт столько внимания.

Нет, я просто недоумеваю, как по объёму встраиваемый код оказался равен очень сложной программе типа Quake-II.
А кстати, этот 100k+ для какого микроконтроллера и в какой по размеру бинарник компилируется?
Если число строк — это метрика, за которую платят, то всегда есть к чему стремиться.
Да вроде бы давно уже за них не платят. :)
НЛО прилетело и опубликовало эту надпись здесь
Это вряд ли. Вон сколько тут народу, но что-то уровня Quake-II ни один не написал.

В конце концов, в том же SQLite 150к строк кода, и 92 миллиона (!) строк кода в тестах.


Тестов, конечно, у Quake-II нет, но основная программа того же порядка.
Я вроде качал тесты на SQLite и мне помнится, что их было на 2 порядка меньше.
92 миллиона строк — это с дампами баз для нагрузочного тестирования?
НЛО прилетело и опубликовало эту надпись здесь

Почему вы думаете, что Quake iI это очень сложная программа? Это узкоспециализированное пользовательское приложение, да еще и не имеющее никакого отношения к встраиваевым системам.


Я, честно говоря, никогда не работал в компаниях, где в репозиториях было бы меньше 50-100 строк кода. В иных бывали и миллионы.

Потому что эта программа есть звено цепочки революционных свершений в плане видеоигр. И повторюсь, ни один из присутствующих на этом сайте не способен создать ничего подобного (даже если получит всю остальную команду Кармака).

В иных бывали и миллионы.


Во, вот тут подробнее. Что делает программа в миллионы строк кода? Я знаю несколько таких программ и там объём вызван, например, большим количеством поддерживаемого оборудования (сиречь, драйвера для всего), кодеков и прочих подобным.

Ага. Вместе с тем, Кармаку далеко до достижений Кнута. Только какое отношение ваш кумир к разработке встраиваемых систем? Не умаляю его заслуг, но надо быть реалистичным: коробочные игры, тем более 90-х, не могли быть большими — тогда не было ни современных бюджетов, ни времени, ни размеров команд. Это как бывший игродел я вам говорю.


Что делает программа в миллионы строк кода?

Миллион это бывает, когда:


  1. Реализуется многослойная бизнес-логика, скажем, документооборота в больших организациях.
  2. Логика интеграции подсистем.
  3. Долгоживущие системы часто тянут с собой код для поддержки обратной совместимости.
  4. Сложные интерфейсы с кучей хитрой логики быстро раздувают код.
  5. И да, бывает надо поддерживать много разнородного железа.

Ничего этого, замечу, не было в играх 90-х: ни обратной совместимости, ни сложных интерфейсов, ни сотен-тысяч поддерживаемых железок, ни развитой логики.


То есть это ни Linux (10+ млн), ни Емакс (2+ млн), ни GCC (10+ млн). Любая из популярных открытых реляционных БД будет за миллион. Вот я посмотрел один из наших корпоративных репозов и увидел 10+ млн строк кода. Работал когда-то давно над онлайн-игрой, там в монорепозитории было сильно больше миллиона.


Я не во всем согласен с автором статьи выше, но ключевая идея у него очень даже понятная: он указывает на то, что многие разработки для малых систем перестали быть малыми, но так и не усвоили правила разработки крупных систем, с их обязательными каскадами тестов и оформлению самого кода.

Только какое отношение ваш кумир к разработке встраиваемых систем?


А вы точно читали оригинальный тезис? Вопрос стоял о том, откуда во встраиваемой системе 100k+ строк, если даже в сложной игре типа Quake-II их 136k. Автор, кстати, так и не ответил, для какого микроконтроллера (!) этот код и какого объёма бинарник получается. А вот вы дальше с чего-то решили, что Quake-II не показатель сложности, на что я вам указал, что таки показатель. Теперь вы опять сослались на встраиваемые системы и роль в них Кармака.

Миллион это бывает, когда:


Итак, что именно делает такая программа?

Любая из популярных открытых реляционных БД будет за миллион.


А давайте-ка тесты считать не будем. Тесты можно раздуть хоть до миллиарда. Полезный функционал сколько занимает?

он указывает на то, что многие разработки для малых систем перестали быть малыми,


Вот как только он объяснит, как он умудрился в 100k+ сделать управление двигателями (со всеми протоколами и прочим) и запихнуть всё это в микроконтроллер, вот тогда и поверю. А пока нам рассказывают о задаче явно не соответствующей количеству строк.
НЛО прилетело и опубликовало эту надпись здесь
Каким образом SQLite отменяет сложность Quake-II и обосновывает 100k+ строк во встраиваемой системе автора? У него там тоже SQLite реализована на микроконтроллере?

Я не понимаю, откуда мнение что 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 раз, а качество только поднялось бы.


Или все же абстракции и библиотеки берутся не на ровном месте? Особенно радует противопоставление им — выходит, писать велосипеды направо и налево правильный выбор?

Линукс это получается «абстракции на абстракциях»?
Я не линукс ругаю, а современный энтерпрайз-бекэнд.

Его можно сделать проще, да. Избавившись от конструкций в виде «метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, вызывающий метод, в котором пять строчек полезного кода». (я утрирую, но, надеюсь, смысл понятен)
Кстати, а у какого-нибудь языка есть компилятор, который для такой макаронины всё заинлайнит при условии, что не создаётся объектов или метод(ы) не использует члены объекта?

Haskell =)

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Если любить абстракции и сторонние библиотеки, то и без куте можно стотыщ набрать легко и быстро. Впрочем, это лирика.

Ключевой момент любой работы — целеполагание. Начав руководить проектами, я настолько иначе стал смотреть на это, что упомянутый ниже пример про ракету, многократные прогоны, простую логику, некачественный код и транспарант «ОТКАЗ» на любой чих — не вызывает никакого удивления. Это хорошо и нормально, если соответствует целеполаганию. Мне трудно без смеха говорить о том, какому именно целеполаганию соответствуют отсылки на количество строк кода (и чем их больше — тем круче), но я точно знаю, что бизнес об этом не просил.

Особенно важно это понимание для системного архитектора. Лучшая программа — та, которую не написали. Программист обычно рассуждает иначе, даже если он синиор, у него просто другая работа.
Если любить абстракции и сторонние библиотеки, то и без куте можно стотыщ набрать легко и быстро.


Абсолютно верно. При этом на решаемую задачу это никак не влияет.
>Ключевой момент любой работы — целеполагание.
>Особенно важно это понимание для системного архитектора. Лучшая программа — та, которую не написали.

я бы сказал иначе, в большом числе случаев наиболее сложная часть проектирования — это грамотное переиспользование кода, не всегда было так, конечно, но сейчас пожалуй именно это самое трудное, мне тоже требовалось подолгу выдавать в день порядка 2k lines of code, особым достижением это не считаю, зависит от знания функциональной области, в конкретном случае это были протоколы, типа берешь соответствующую rfc, строишь state machine и поехали, пишется с нуля, и ни от чего кроме спецификации не зависит, но на порядок сложнее использование всевозможных asic specific sdk, их стыковка с другими пакетами функционального sw, это требует более высокой квалификации в том числе от архитектора, причем никакой абстрацией этого не заменишь, необходимо детальное знание продуктов, либо оно есть — тогда вы полезны, либо его нет, время на изучение это накладные расходы, и его как правило нет, примерно так работают программисты, по крайней мере то что приходились видеть там где работал на востоке us, что бы все сделать четко и быстро на работу и берут опытного архитектора

«Измерение производительности программного обеспечения по строкам кода похоже на измерение прогресса на самолете по его весу», - Билл Гейтс.

Я далек от эмбеда, но здравый смысл мне в Вашу (Spym) поддержку подсказывает: «А разве вообще количество строк исходного кода что-то значат?» Исходный код — он для программиста. Для микроконтроллера — бинарный файл. И если исходный код удобно читать и обрабатывать, а его количество не вытекает в архитектурные побочные эффекты, котрорые бы вели к снижению производительности бинарника, то вообще количество строк абсолютно пофиг. Мне представляется что, в теории, компилятор может и «развесиcтый» исходник и «уплотненный до нечитаемости», собрать в идентичный бинарник. И что нам тогда количество строк?

Количеством строк менеджерам легко оценивать абстрактное количество вложенного труда в проект. Отличать крупный проект от мелкого. И то ведь, это, опять же, очень относительно. А в техническом плане от этой метрики какой толк?

Лично мое мнение — чем меньше строк, тем лучше реализация. Ту же банальную сортировку можно сделать и в 100 строк и в две… Я думаю, показатель — краткость и элегантность кода. Возможно, в современном мире не так, но хочется верить в светлое

чем меньше строк, тем лучше реализация.
не стану отрицать, что тут возможна корреляция. И если есть причинно-следственная связь, то скорее такого толка, что люди пишущие короткий код, имеют очень острый ум. Поэтому и код лучше. Т.е. сильные программисты пишут хорошие реализации. И сильным программистам свойственно писать коротко. Такая вот взаимосвязь вполне может быть.
Проблема только в том, что читают этот код потом люди с заурядными способностями.

Я думаю, показатель — краткость и элегантность кода.
Вообще странно, что программисты говорят об элегантности, но при этом элегантости на их взгляд, хотя она определяется только третьим лицом.
Красиво не когда нравится тебе, а когда нравится многим.

Кутюрье выставляют свои платья на показ. Художники выставляют картины. Музыканты выступают с концертами. Публика определяет, что классно, а что так-себе. Конечно, у создателя может быть свое мнение. Лишь бы оно не ограничивалось самомнением.

P.S.: Надо, по аналогии с кинематографом, выпускать публичную версию кода и «режиссерскую» :D
Ту же банальную сортировку можно сделать и в 100 строк и в две

Если результат по скорости и памяти будет одинаковый — конечно лучше в две. Но это фантастика. Иначе бы все вместо quick/mergesort-ов сортировали пузырьком...


И часто бывает что более длинный код более читаем. Я насмотрелся в своё время скриптов на Перле где всё делалось через контекстную переменную… понять что там происходит нереально, даже если ты сам это написал :)

… конечно лучше в две.

Ну, строки могут быть разной длины )

Не могут, строки обязаны быть отформатированны по какому-нибудь стандартному гайдлайну (потенциально с разумными кастомизациями под проект), иначе это не код а хрень.

Зато в 2 строчки можно заимпортировать уже готовый крутейший алгоритм сортировки. Какой-нибудь тимсорт правильно реализовывать заманаешься, а тут все готовое. Можно конечно схалявить и написать медленный квиксорт, но не факт что так правильнее.

Конечно, в 99% лучше использовать встроенную в стандартную либу сортировку, если таковая имеется. Скорее всего она good enough.


И под капотом там, вероятно, будет несколько алгоритмов, выбираемых динамически либо в compile-time либо в run-time в зависимости от размера массива, архитектуры и т.п.


Есть исключения, но если у тебя именно тот случай — то ты скорее всего уже об этом знаешь :) Особенно это касается сортировки очень больших массивов данных.


Но тут речь то именно про реальный код в <10 адекватных строк или в >100 допустим. И вполне возможно как раз в более длинном коде можно учесть всякие особые случаи, например в случае той же сортировки, для массива <20 элементов юзать insertion sort.

Почему то «элегантность» и «читаемость» не всегда идут рука об руку. А уж с рекомендацией «писать 'self documenting' код» эта самая «элегантность» (как ее некоторые понимают) дружит еще реже. ;) Не буду спорить, что код достаточно редко получается полностью 'self documenting', но любые «подподвыверты» могут сделать его головоломкой для всех, кроме автора.
Если код писать так же, как тот автор свои статьи, то конечно, для простого векторного управления двигателем понадобится 100 тысяч строк. 1000 строк на преобразования и регуляторы, и 99000 на «специфику».
НЛО прилетело и опубликовало эту надпись здесь

А как же. Для комментариев с хабра там ещё отдельный файл тоже.

НЛО прилетело и опубликовало эту надпись здесь
Spym
Код для векторного управления полностью помещается на экране монитора — примерно 30 строчек. Сам алгоритм простой как тапок, и он должен работать в реальном времени. Всё что для него требуется — занимает в флеше 60к, в памяти примерно 4к.
Умеет вращать от нуля до номинала, работать как серводвигатель.
100к сток кода там нафиг не требуется, двигатель на воде работать не будет.

Я очень рад, что вы знакомы в общих чертах с алгоритмом векторного управления, честно. Однако, запись формулы отличается от законченного продукта примерно как теория отличается от практики. Ваш ответ заставляет меня заподозрить, что с практическими внедрениями с корректной обработкой граничных случаев, вспомогательными режимами, коммуникационными протоколами, тестами, и т.п. вы никогда не сталкивались, иначе не писали бы здесь про один экран. Зачем вы это написали вообще? Что хотели сказать?

Я писал прошивку для бездатчикового векторного управления PMSM. Даже с кодом для настроек объём очень далёк от 100 тысяч строк, так что заканчивай писюном махать. Всегда найдутся те, у кого длиннее.

Вы либо дилетант, либо космически толстый тролль. Как можно пытаться оценить сложность реализации системы, не зная о ней абсолютно ничего кроме того, что она как-то связана с векторным управлением?


Я смотрю на ваши комментарии в профиле и недоумеваю, вы с двача сюда пришли что ли? Здесь собираются более-менее адекватные люди в основном, обратите внимание.

Как можно пытаться оценить сложность реализации системы, не зная о ней абсолютно ничего

Всего лишь опустился на твой уровень, где ты заявляешь об отсутствии компетенции собеседника, ничего не зная о нём, чтобы принизить его мнение.

кроме того, что она как-то связана с векторным управлением?

В контроллере управления двигателем не будет крутиться СУБД или рендериться изображение. Тебе несколько раз намекнули, что объём кода великоват для контроллера двигателя, а в ответ только «вы дилетанты и не шарите».

Здесь собираются более-менее адекватные люди в основном, обратите внимание.

Тогда что ты тут делаешь, рекламщик?

image

Однако, запись формулы отличается от законченного продукта

Академические формулы которые описывают работу двигателя — не определяют его состояния в нужный вам момент, они общие, вообще для всего диапазона состояний. Они настолько далеки от практического применения — что не имеет смысла на них тратить время.
Мотор вообще очень простая штука, полностью аналоговая модель прекрасно его замещает. По этой причине нет смысла усложнять алгоритм, достаточно добиться приближения к аналоговой модели замещения.
Насчёт протоколов тоже мудрить нет смысла. Чем проще -тем надёжнее работа.
Насчёт тестов порадовали…
Ну невозможно как-либо производить отладку реально работающего двигателя. Даже если вас не убьёт потенциалом нуля горячего шасси — это сделает сам двигатель, когда вы остановите программу.
Я уже написал про модель замещения, вот на её эмуляции и выполняется отладка — там можно останавливаться и курить.
Если бы квака была написана так, как предлагается в статье, думаю там было бы гораздо больше 136KLOC.

Это верно, я даже больше скажу: если бы она была написана как предлагается в статье, 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 строк кода там и в помине нет, а работа программы, обычно, весьма линейна (а вот математика может быть весьма сложна, но это только математика) и в случае чего просто сообщается «отказ» и на этом всё.

Мне кажется, что Вам стоит почистить ваш комментарий, особенно если он про РФ, вероятно он немного нарушает некоторые законы, причём не административные.

А то слишком много печальных историй было последнее время в этом ключе... :/

Даже я со своей паранойей не вижу нарушение режима секретности. Докопаться, конечно, можно, но тут уже как до столба.

Ну... Если бы я проектировал документы про государственную тайну, вероятно, я бы отнёс заявление о том, что ты имеешь к ней отношение под гриф государственной тайны, в случае если это не публичная информация.

Возможно, мой внутренний параноик, слишком параноик. :)

Всё-таки признание участия или получения информации о разработке оружия и средств доставки, о которых известно, что они разрабатываются, без указания названия, уровня готовности и ТТХ изделия или его частей, без имен, фамилий и названий прочих участников и указания точного названия и местоположения организации-разработчика — ну такое себе. Не, в принципе можно подтянуть da-nie или человека, от которого он получил информацию, под 1.2-1.4 ст.5 ФЗ «О гостайне», но это тот самый столб. Фактически анонимус в Интернете нам без подтверждений сказал, что в ракетостроении сохранились артиллерийские традиции, из этого даже highly likely не сделать.

Вот если бы он признался в участии в разработках напалма или иного запрещенного вооружения, даже без подробностей, тогда точно нарушение.
Да и предпосылок для того, чтобы софт для ракеты был как-то принципиально по-другому написан, по сравнению с движком кваки, особых нет.

habr.com/ru/post/307394
Да и предпосылок для того, чтобы софт для ракеты был как-то принципиально по-другому написан, по сравнению с движком кваки, особых нет.
ракета с распрыжкой — звучит странно, но круто…

Термин rocket jump тоже начинает играть новыми красками

Достаточно посмотреть на качество компонентов UI у драйверов AMD и NVIDIA. Та же беда. Там баг на баге и UX отвратительный, как будто голодные студенты на переменах это пишут.

А драйверы для микроконтроллерной периферии от чипвендоров вы видели? Мысль о том, что они работают в реальных продуктах не даёт мне спать по ночам.

Охотно вам верю.
НЛО прилетело и опубликовало эту надпись здесь

Конечно, ведь иногда есть драйверы от вендора ОС, либо свои доморощенные.

НЛО прилетело и опубликовало эту надпись здесь
Не видел, если честно…

Обратите внимание на RTEMS, NuttX, ChibiOS. Ещё, вероятно, драйверы поставляются с Zephyr, но я лично дела с ней не имел.


Не ну можно конечно, но зачем, если есть от чипвендора...

См. дискуссию выше. Драйверы, например, от Microchip, для их Automotive микроконтроллеров не подвергаются никакому контролю качества. То же самое можно сказать о популярном здесь ST Microelectronics. Если вы делаете сертифицируемый продукт, использовать эти драйверы вы всё равно, скорее всего, не сможете. Если вы делаете обычный продукт, то даже в этом случае использование кода с крайне высокой плотностью ошибок не оправдает экономии, если только продукт не совсем простой (об этом оговорка в начале статьи).

То же самое можно сказать о популярном здесь ST Microelectronics.
А это тогда что?
Вы не путайте аппарантые фишечки (ECC, вотчдоги, обработка отказов,..) и софт который с этим типа должен работать.
Вы там ниже почитайте, про софтваре-паки.

Я не вижу связи между программными пакетами для автомониторинга (self-test), на которые вы ссылаетесь, и драйверами периферии, которые мы обсуждаем в этой ветке.

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Ошибки ядра и периферии выявляются довольно быстро и описаны в еррате. У микроконтроллеров ядро и система команд очень скромные (по сравнению с процессорами), там в существующие ошибки врезаешься практически сразу, поэтому шансы найти незадокументированную ошибку ничтожны. Я за 15 лет не нашёл ни одной.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
в кейле для стм была библиотека спл, да еще и с ошибками.
НЛО прилетело и опубликовало эту надпись здесь

Я, конечно, не настоящий сварщик, но весь софт, который я видел от чипвендоров (в моём случае это всякие штуки, связанные с сетями) — это между "ужас, на ночь не читать" и "этим пытать можно". Такое впечатление, что отбор туда проходит по признаку "не умеет программировать — айда к нам".

Разработчики встраиваемых систем давно программируют в симулинке решение задачи. А вы до сих пор описываете «как оно там было в святые 90-е» V-model писание кода руками. вот это вот все…

V-модель это методология разработки и управления проектом. Симулинк это инструмент реализации. Эти вещи никак не связаны. Даже если ваш код генерирует симулинк, это не отменяет потребности в формировании проектных требований с последующей валидацией и верификацией. Не следует думать, что V-модель куда-то ушла, она по-прежнему применяется при разработке ответственных систем. Например, обратите внимание на процесс сертификации DO-178.

НЛО прилетело и опубликовало эту надпись здесь

Интересно много ли эмбедеров разрабатывают архитектуру и детальную архитектуру? Хотя надо сказать, что без архитектуры на функциональную безопасность сертификат не получишь, поэтому там V-модель обязательна.
И да, полностью согласен с рекомендациями.

НЛО прилетело и опубликовало эту надпись здесь

Возможно, хотя бы часть этих проблем можно решить банальным изменением отношения к вопросу. Просто сейчас точка зрения, которой делится 0FFH в комментарии ниже — что софт дело десятое, нам бы железку собрать — достаточно распространена, к сожалению. Именно здесь видится целесообразным применение упомянутых мною там же просветительских методов.


Технический долг (в отношении кодовой базы) не является вымыслом прикладников, это вполне реальная вещь, игнорирование которой порождает пресловутые "драйверы от чипвендоров", что не выдерживают никакой критики.

НЛО прилетело и опубликовало эту надпись здесь
Есть одна российская компания, которая производит платы для MIL-STD-1553 c драйверами под Linux,


Элкус? :)
НЛО прилетело и опубликовало эту надпись здесь
Да я как бы знаю (так как использую их плату). :)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Это всегда вопрос ресурсов, приоритетов и процессов разработки. И на мой взгляд последнее для встраиваемых систем не так уж и сильно отличается от всего остального мира. SOLID, CI/CD, парное программирование, тестирование кода и т.д. — ничего нового здесь нет.
Я был во многих крупных проектах в эмбеддинге и там, где был грамотно выстроен процесс разработки и ресурсы позволяли, везде была вполне сносная архитектура кода, которая позволяла параллельно работать десяткам и сотням людей над проектом.
Ну а если ресурсов хватает лишь на одного человека на полставки, то немудрено, что код будет тяп-ляп и готово.
Сперва размазал пространных рассуждений, а потом вкинул рекламу своего велосипеда, ведь существующие обладают фатальным недостатком.

Вы прекрасно читаете между строк. Есть класс новых проблем, с которыми наш велосипед справляется лучше других, о чём я подробно писал в предыдущем посте.

Разработчики встраиваемых систем не умеют программировать

а что вы подразумеваете под программированием?
разработчик встроенных систем в первую очередь — электронщик электрик механик — и уж затем вишенка на тортике — программист
причем если берем сферу микроконтроллеров — то там царит язык Си.
я много писал на Си для микроконтроллеров — там вообще не было работы с файлами.
это кардинально отличается от общего программирования — где работа с файлами — это главное.
и я еще помню времена в 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. Потому что где-то в транзитивных зависимостях используется одна версия, а в других — другая. Пакетник тут за меня проблему решил, подсунув каждой зависимости ту версию, которую она ожидает. В ридми это тоже описывается или каждый раз приходится выдумывать свое решение? Или "Такого не должно быть никогда"?

Я так понимаю, это не С++, а совсем даже Rust ;)
В проекте на C++, если в зависимостях образовалось разные версии одной либы, это ПЦ. Когда и как оно взорвется — одному линковщику известно.

Читать доки чтобы подключить зависимость? Извините, это и есть «с либами туго».


Это и есть заголовок статьи ;) Зачем читать какие-то скучные доки, если можно поставить крыжиков в конфигураторе — и в production :D
Я так понимаю, это не С++, а совсем даже Rust ;)
В проекте на C++, если в зависимостях образовалось разные версии одной либы, это ПЦ. Когда и как оно взорвется — одному линковщику известно.

Ну вот это плохо (если мы про статическую линковку офк).


Это и есть заголовок статьи ;) Зачем читать какие-то скучные доки, если можно поставить крыжиков в конфигураторе — и в production :D

Полностью поддерживаю — вкалывать должны роботы, а быть счастлив — человек )

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
нет ничего такого

Так, ведь вы сами написали, что именно так пишите.


а гомнокодерство — это там где используют шаблоны

Говнокодерство — это там, где вы через месяц не понимаете того, что сами написали.


я не слыхал о универсальной библиотеке

При чём здесь универсальная библиотека, если речь шла об алгоритмах?


самый простой пример шаговый мотор

Прекрасный пример эффекта Даннинга-Крюгера.

но почему-то чем круче эмбедер тем меньше языков он знает )))

в целом в эмбедерстве — паяльником и напильником интереснее работать — чем тока клаву топтать.
это конечно мое имхо.
а в целом Си на все хватает.
на си в духе паскаля

А в чём принципиальная разница?

читаемость кода
НЛО прилетело и опубликовало эту надпись здесь
А от си у меня уже полгода вялотекущий баттхерт оттого, что семантика static внутри функции немного отличается от плюсовой

А существование обратного баттхерта допускаете?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Непонятно, что за общее программирование.

unix way
НЛО прилетело и опубликовало эту надпись здесь
разработчик встроенных систем в первую очередь — электронщик электрик механик — и уж затем вишенка на тортике — программист
если для железки, разработка которой сопоставима по трудозатратам с написанием для неё кода, нанять таких вот «вишенок», пропорция из 50/50 сместится в 20/80, где большая часть этих 80 торжественно спихнется на клиентский код с формулировкой «у меня мой минимальный пример работает».
Это только кажется, что в проце «немеряно дури, можно не экономить». А потом, через пару лет развития проекта, программисты попросят заменить ф4 на ф7, потом им не хватит ф7 — а сейчас им уже не хватает Н7 — а дальше некуда, поэтому сидят и лопатят свои десятки тысяч строк кода, оптимизируя быстродействие…
НЛО прилетело и опубликовало эту надпись здесь

Ну если взять мантру юникса что "всё файл" то это верно — большинство аппов по сети любят ходить. Те которые сидят и че-то там считают (и никуда результат особо не пишут, только изредка отвечают на запросы или в те же файлики) исчезающе мало

НЛО прилетело и опубликовало эту надпись здесь
Хорошего программиста низкоуровневым не назовут :)

Хех, огромное спасибо, добрый человек за профессиональное дёрганье болевых точек!


И да пребудет с тобой подробный ARXML!

Такое ощущение, что прочитал промо-статью из Я-Дзена, где большая часть придумана для иллюстрации концепции.

Заголовок, что все хххххх (отрицательная характеристика).

Пара примеров:

— И где такого работника Илью взять, чтобы всё делал правильно, вдумчиво и без какого либо описания/архитектуры/распила на слои/модули? А если всё вышеперечисленное наличествует, тогда какие проблемы с архитектурой? Скорее с архитектором.

— Начальника, который присмотрел новомодный язык, озадачиваешь вопросом стыковки и поддержки фичи/протокола, специфичного для данного проекта. Во всяком случает, последний раз такие предложения слышал лет 15 назад.

И вишенка на торте: реклама своей статьи и приглашение в сообщество, где Вас из хххххх превратят в жжж (положительная характеристика).

Вот точно — Я-Дзен.

А, Да, предлагаю написать статью по результатам рекрутинга волонтёров: сколько пришло после прочтения статьи.

Хуже примера для подрожания наверное придумать и нельзя было

Посмотрел uavcan. По сути, очередной встраиваемый rpc. Эмбедеры используют rpc, архитектуру на основе событий, гетерогенный компьютинг и пр., а не только лампочками моргают:-) Алгориитмы эмбедерам не нужны? Так они часто на одних только хитрых алгоритмах и структурах данных и сидят. Не надо всех под одну гребёнку, пожалуйста.

Конечно, не все такие, но вы согласны с тем, что проблема имеет место?

Недостаточно исследований

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Вот вам взгляд из соседней амбразуры.
Не всегда и не везде возможно запихнуть в контроллер чисто физически все ваши 100к правильных и красивых строк кода. Хорошо, когда вы пилите электронику для БелАЗа (там есть, куда всё запихнуть). А если это маленький дрон с очень ограниченным энергообеспечением, которое хорошо бы потратить на полетное время, а не на сотни мегагерц, чтобы ваш убер-сервер по супер-пупер шине подписался на датчик и опросил бы его? Или некое носимое устройство (от которого иногда жизнь зависит), которое должно гарантированно отработать не менее скольких-то часов от какого-то, извините, говна, которое пользователь туда засунет в качестве источника питания. А приходит вот такой правильный программист, не считающий байты и говорит — не, чувак, я ногодрыгалку на двух мегагерцах не напишу. Мне тут нужна ртос, оперативы побольше и вообще линупс хочу, там всё по щелчку пальцев делается готовыми библиотеками. А есть ведь еще ограничения на бюджет всей затеи. И хорошо бы прибыль после разработки начать получать.

Так что зря вы так всех сразу в реактор. Каждому гвоздю свой микроскоп.

Ардупайлот живет на очень дохлых платформах, и тем не менее там порублено на модули все почти как надо. Соблюдение принципов приводит к тому, что все работает быстрее и устойчвее.

С этим утверждением сложно поспорить. К сожалению, вот этот абзац автора
«Очевидные вещи говоришь» — скажет матёрый архитектор информационных систем — «Тут сервис, тут зависимость, соединили и полетели». Но в кругу встраиваемых систем эти очевидные вещи, судя по моему удручающему опыту, являются откровением, потому что опытный эмбедер подходит к решению той же проблемы совершенно иным образом: не от целей, стоящих перед системой, а от средств их достижения. Или, короче говоря: первым вопросом является не что мы делаем, а как мы это делаем.
рассказывает всё о его знакомстве со встраиваемыми системами, когда зачастую вопрос «как мы это делаем», всё же главенствует над что мы делаем, или просто является неотъемлемой частью. Глупо спорить, что грамотное разбиение проекта и покрытие тестами не нужно в эмбеде. Не стоит просто столь категорично утверждать, что все проекты без таких громких слов, как «архитектура», «сервисы», «подписки» и прочих умных слов из книжек сделаны плохо. Иногда вся архитектура вырождается из-за решаемой задачи в одну функцию.
Складывается впечатление, что автор слабо представляет, что такое программирование для embedded и откуда берутся подсчеты байтов и клоков. Я посоветовал бы автору, перед тем как писать такую длинную и сумбурную статься, взять ПЛИС средней сложности, создать вней своё вычислительное ядро, организовать 64К статической памяти и попытаться впихнуть туда свои 100к строк кода «с соседнего стола». А потом еще и заставить их работать «как задумано». После этого руки чесаться перестанут, будет одно желание — лечь и поспать с недельку, другую.

Если должно работать гарантированно и качественно — нужны тесты. Нужно считать байтики и потребление памяти. Но это можно делать грамотно не слепив все в один спагетти-модуль с большим количеством глобальных переменных. Чтобы делать абстракции бесплатными можно пользоваться статик инлайнами, макросами. И разбивка на модули потратит от силы 1% от флешки, если это сделать правильно. А то и уменьшит дублирование спагетти кода и наоборот памяти сэкономится.

НЛО прилетело и опубликовало эту надпись здесь
Бесполезно. Подсчёт байтов требует не только знание, но и понимание, а это уже другая лига.

Не подскажете, где взять готовые ноды для UAVCAN, типа UC4H General node ?

Берите любую ноду для v0, они аппаратно совместимы с v1. Ещё есть демоплаты для UAVCAN от NXP, но их пока нельзя купить за пределами США из-за экспортных ограничений, установленных администрацией Трампа.

(глядя на процитированную V-диаграмму) Очень, очень вредная картинка. Потому что на самом деле она должна выглядеть как символ квадратного корня с длинным-предлинным хвостиком "эксплуатация". Казалось бы разработчикам встраиваемых систем это должно быть понятнее, чем обычно. Потому что результат их работы годами может стоять там, где поставили. И никаких апдейтов не будет.

Автор, конечно, набросил на вентилятор желтым заголовком, но если переформировать мысль по другому:

Сколько программистов могут писать функционал в течении года, и не сделать больше 3-х багов

Получится весьма и весьма небольшой процент.

Конечно, не во всех сферах так критичны баги, но там где критичны — даже не знаю, как бизнес ищет программистов. Потому что тотальное «тяп-ляп и в продакшен» повсюду.
Потому что тотальное «тяп-ляп и в продакшен» повсюду.

Так это и не от программистов зависит.
«Тяп-ляп» от программистов только и зависит. Больше ни от кого. Пришёл манагер и сказал «вот проект, на него у нас неделя», а проект требует две недели? Вспоминаем «я угадаю с трёх нот» + «угадывайте». Кто в какой роли в данном диалоге, полагаю, понятно.
Чаще вижу вариант, когда манагеру предлагают несколько вариантов. Какой из вариантов он обычно выбирает, полагаю, понятно.

Ну или поставили задачу сделать за неделю — сделали так, как можно сделать за неделю. Отказаться выполнять за неделю? Найдут другого.

В любом случае, единственное системное решение — формализация критериев качества, которая даже если и выполняется исполнителем (что уже странно) всё равно без запроса от менеджмента никогда не произойдет.
Чаще вижу вариант, когда манагеру предлагают несколько вариантов. Какой из вариантов он обычно выбирает, полагаю, понятно.

Непонятно. Потому что когда я говорю "быстрый вариант будет иметь такие-то недостатки и так-то нам встрянет буквально через год" в достаточно большом количестве случаев одобряют медленный и правильный :shrug:

Это только подтверждает мой первоначальный посыл о том, что качество зависит в первую очередь от менеджмента.

Ну с этим никто не спорит :) В качестве хрестоматийного примера можно посмотреть на то что на наших глазах происходит с DLC от PDX на EU4 — 7% положительных отзывов на стиме, массовые рефанды, Cyberpunk 1444 мем на всех бордах и т.п.

НЛО прилетело и опубликовало эту надпись здесь

Очень жизненно! Особенно некоторые вместе с классом — боссом лепят 100 глобальных переменных. Сам эмбеддед разраб и навидался жести.
Еще некоторые терпеть не могут обёртки. Говорят, что уровни абстракции сжирают много памяти. Однако, если их правильно писать и разбить на модули, то никак больше не получается. Тупой пример: статик инлайн обёртки. Памяти едят ноль, зато можно обернуть простые конструкции в более человекочитаемые функции.
У Nordic -овских чипов довольно крутое sdk. Там хорошо разбито на модули и много трюков для дешевых абстракций используется.
Еще пример бесплатной абстракции — кастомная секция в линковщике для регистрации эвент хендлеров. И прикрыть макросами регистратор. Доп памяти требует зеро, зато можно использовать event driven парадигму и нормально разбить на модули.
Также копипаста всяких типичных вещей вымораживает. В чем проблема вынести в отдельный модуль эвентлуп, fsm, модуль очереди написать? Копипируют туда-сюда и с кучей ошибок...


На счет malloc-free, если в MCU памяти катастрофически мало, проще стат буферами гарантировать работоспособность. Да, иногда нужны какие-то аллокаторы, тут безопаснее memory pool разделённый использовать. Можно конкретному модулю так разграничить объем памяти. Допустим, сетевому модулю под буферы пакетов. Чтобы на высокой нагрузке весь хип не сожрал — выделенный мемори пул даст чёткий лимит по памяти на сетевые пакеты.


Все же поражает дробление на модули. Ну слепили все в босс-модуль, сэкономили 0.5% флешки, зато потом требуются недели чтобы понять как это работает. Вместо минут 15-ти. И тестировать нереально. А как показала моя практика — тесты позволяют ловить регрессии и меньше времени тратить на отладку. А некоторое вообще без тестов не поймать с санитайзерами.

А вы можете посоветовать что-то путное по архитектуре встраиваемых приложений, особенно для плюсов? Чтобы прям такой high-level был.
НЛО прилетело и опубликовало эту надпись здесь
Греннинг хорош, одна из самых полезных книг по С, которую я читал, но динамические объекты убивают :(
C++ призывают воздержаться от [...] использования динамической памяти [...] malloc() и free()
Одно дело malloc() и free(), а совсем другое неявные new() и delete().
В общем случае, в критически важном участке кода лучше вообще отказаться от всего лишнего, включая malloc() и free(), выделив всю необходимую память заранее.

Мы получаем законченный сетевой сервис, который предоставляет данные системы воздушных сигналов
А это другая крайность. С точки зрения надежности системы лучше получать в том числе и сырую информацию с датчика. Хотя бы потому, что таких сервисов может быть несколько дублирующих. И тогда, обладая всей полнотой информации, намного проще будет разобраться, какой из них вышел из строя, если вдруг они стали выдавать различающиеся данные.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Падажити, ну нет, что значит неявное? Все же нет таких людей, которые бы думали, что контейнерам не требуется куча.

Но в целом, да, для среднего эмбедера лучше живется в мире явных ограничений. Не выделил сам — не работает.
Судя по количеству комментариев, у всех наболело. О чём говорить, мы живём в век некачественного софта! С тех пор как микроконтроллеры «перешагнули» 8-мь бит, туда стали пихать всё подряд (C++, FreeRTOS, ...). А почему нет если я могу и это ни чего не стоит!
Я согласен с AVI-crak, 100 тысяч строк для привода!? Это какой то Франкенштейн. С другой стороны мне понятен разговор Spym про «специфику». Я тоже писал программу для прибора, так там сначала «а давай добавим ещё один экран,… ещё один интерфейс,… и что бы по WiFi в интернет отчёты отправлял,… и что бы на балалайке играл ...». Итого 13 тысяч строк на СИ для 8-ми битного контроллера. 13-ть тысяч !!?

А почитайте вакансии, чего там только нет. Что разделение труда осталось в каменном веке?! Или у нас Цезарей полно, способных знать на отлично 5-ть областей знаний.
Остается дописать в вакансию «умение играть на баяне будет плюсом».
Вот не удивлюсь про баян. Недавно искал вакансии про IoT/микроконтроллеры, схемотехника везде в обязаловке стоит.
Разработчик ПО для микроконтроллеров должен быть, в первую очередь, инженером, а не программистом. Хотя микроконтроллеры уже не все микро. А то что кадровики сваливаю в кучу все умные слова, которые знают, так это да.
НЛО прилетело и опубликовало эту надпись здесь
Инженер может стать программистом, а вот программист инженером, к сожалению, нет. А по поводу ФОТ, я с вами совершенно согласен.
Не обольщайтесь, кадровики ничего не решают, они пишут ровно то, что им выдало техническое руководство вертикали или проектов (где как). А оно выдает такие требования не потому, что дураки, а потому, что экономика проектов такова.
А как вы еще будете писать программу, если не понимаете, что внутри вашего черного ящика и как он взаимодействует с периферией? Хотя бы базовые знания схемотехники у эмбед-программиста обязаны быть. Иначе можно много чего пожечь, даже не понимая, что произошло.
Базовые-то есть, но вот разводить, а тем более дебажить плату я не возьмусь, поэтому и не считаю себя схемотехником.
Делал я одну железку — условно регулятор, но немного нетривиальный. Так программист который логику реализовывал так и не смог убрать шум из производной входного сигнала т.к. не смог (вернее даже не пытался) точно синхронизировать АЦП. Сколько тысяч строк фильтров там было всяких разных перепробовано — я не считал. Хотя проблема решалось в пару десятков строк. В итоге была переделана железка и первые две производные были реализованы вообще в аналоге и заведены на отдельные каналы АЦП.

По этой причине желательно чтобы архитектурой занимался тот, кто и в железе понимает и в софте.

Потом как писать софт для какого-нибудь инвертора силового киловатт на -дцать или -тьсот, не понимая физики происходящего я вообще не представляю. Имеется в виду не тупо кодить описанные кем-то другим алгоритмы, а сами эти алгоритмы и разрабатывать.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
В чём проблема с пиханием C++? Я его пихал давно в attiny, полёт нормальный был.
Конкретно C++ ничего, если не начинают в конструкторах делать new и оверинженирить. В устройствах с микроконтроллерами обычно переферия фиксированная и не нужно на лету подключать N экранов и клавиатур. А простые RAII с написанием «универсальной» библиотеки одного RGB светодиода не дадут впихнуть в все в прошивку.

Конечно ты не платишь за то что не используешь. Но часто приходится брать С++ библиотеку и выкидывать от туда 90%. И тогда, да, в ATtiny все помещается.

Что плохого в том, чтобы умные люди уже написали сверхкрутую-производительную-гибкую библиотеку по управлением RGB светодиодом, а нам нужно только 10% а остальное мы выкинули? Кто проиграл и в чем?

В конкретно этом случае я дорабатывал недоделанную прошивку, и одной из проблем был большой объем.

Так какой объем, мы же все выкниули? LTO=true и порядок


Т.е. если создается исключительно один объект с new в конструкторе в начале программы, то в прошивку не пойдет система управления динамической памятью?

На том же расте можно сделать no_std и тогда все библиотеки которые аллоцируют нельзя будет использовать. Но у большинства популярных библиотек самих есть свитч no_std, который позволяет использовать их подмножество в случае, если аллокатор недоступен. Но аллокатор в итоге тащить не надо.


ну так, как пример

А простые RAII с написанием «универсальной» библиотеки одного RGB светодиода не дадут впихнуть в все в прошивку.
линкеры умеют выкидывать не используемые символы…
Т.е. если создается исключительно один объект с new в конструкторе в начале программы, то в прошивку не пойдет система управления динамической памятью?

На самом деле не знаю что там как раз линкер выкинул, пример уже далеко в истории, но простое удаление конструктора и деструктора, (наверное с заменой на статические переменные) существенно уменьшили объем прошивки. Позволив добавить новые фичи.
Т.е. если создается исключительно один объект с new в конструкторе в начале программы, то в прошивку не пойдет система управления динамической памятью?
если оптимизатор выкинет пару new/delete, то может и не пойдет. А вообще говорил я несколько про другое — если библиотека тянет 100 методов, а вы используете (в т.ч. рекурсивно) только 10 из них, то остальные 90 линкер должен выкинуть, если ему правильные флаги скормить.
На самом деле не знаю что там как раз линкер выкинул, пример уже далеко в истории, но простое удаление конструктора и деструктора, (наверное с заменой на статические переменные) существенно уменьшили объем прошивки
охотно верю, что удаление конструктора и деструктора могли уменьшить объем прошивки. Однако кажется странным, что впоследствии программа продолжила работать корректно.
Спасибо за статью.

Сами сталкиваемся с разрывом между большими (универсальными) системами и embedded. Но мне кажется Вы сгущаете краски. Да согласен программисты на MCU смотрят со стороны железа. Мы в статьях уже не один раз показывали, что есть и другие подходы для разработки в том числе и для микроконтроллеров. Но все таки большинство встроенных систем сейчас используют Linux, а следовательно и разрабатывают ПО исходя из функциональности. Например марсолет ingenuity.

С другой стороны, согласитесь, если нужно просто собрать показания от датчиков, то приведенные вами mbed и другие подобные проекты, весьма хороши. Ведь они решают поставленную бизнесом задачу, причем действиетльно быстро.

В вашем примере с Ильей и его руководителем, я бы предположил, что разработчик не достаточно точно показал где у него основная работа. Я имею в виду, что разрабатывал он прямо на железе, и мне бы как менеджеру отвественному за деньги, показалось бы что это и есть основная трудность. Другое дело если бы он разрабатывал на хосте, Вы же сами сказали, что основная сложность в бизнес логике. Тогда понятно, что предлагать mbed, как решение проблем связанных с железкой, бессмысленно.

Ваш пример с СLion, тоже стоило бы разделить на составные части, выделить HAL, хотя я конечно не знаю какая там задача. И исхожу из соображений, что если есть бизнес логика, то ее можно запустить отдельно. Если эту логику проще запустить (разработать отладить протести) прямо на железке, то наверное и разделение отпадает.
Я думаю, дело зачастую вот в чем. «Высокоуровневое» ПО пишет «чистый» программист в составе команды таких же программистов и это его основная работа на протяжении всей карьеры. Именно поэтому (особенно при командной работе над одним продуктом) большое внимание уделяется архитектуре программы, модульности, уровням абстракции, грамотному именованию переменных и форматированию кода в конце концов. Все эти подходы регламентируются, изучаются, обсуждаются с коллегами, потому что весь коллектив, скажем так, «варится» в этом. Встраиваемое же ПО (особенно для микроконтроллеров) часто пишет электронщик — разработчик всей системы, имеющий кое-какие навыки программирования. Для него это только небольшая часть работы и помимо архитектуры есть куча других проблем. Ему не до чтения Мартинов и Макконнелов, сама архитектура обычно проще, красота и читаемость кода тоже не так важна, потому что код пишется как правило одним человеком от начала и до конца (не считая библиотек). Отсюда и берутся те самые десятки глобальных переменных, магические числа, вся логика в одной-двух функциях в одном файле и тому подобное.
Согласен, ушел из программирования embedded потому что даже если нахожу работу где нужно только программировать, то оказывается что электронщик там так себе и оставил кучу проблем на плате которые если сам не решишь то работу выполнить не получится. Сначала занимаешься исправлением простых логических проблем, потом рано или поздно придется столкнуться с помехами и силовыми линиями. Позже будешь сам собирать макеты чтобы делать быстрее и не зависеть от электронщиков. Ну и конечно ты сам себе аналитик, и тестировщик, и автотестировщик. Сам пытаешься понять что хотят заказчики, и сам даже делаешь устройства которые тестируют другие устройства. А когда речь уже пошла о производстве прототипов вместо макетов, я слился и ушел в backend.
НЛО прилетело и опубликовало эту надпись здесь
Сложный вопрос — что называть простым кодом. Например, что проще: когда побочные эффекты явно выражены присваиваниями глобальным переменным, или же когда они спрятаны в монаду? Монадический код выглядит сложнее, но в нем программист ограничен интерфейсом монады и компилятор не позволит от него отступить, а если код параметризован типом-монадой, то его удобно тестировать, подменяя этот тип.

Странный вопрос: конечно монадический код проще. По крайней мере читать.


Писать наверное сложнее. Но тоже зависит от практики, с определенного порога может быть даже проще ибо либы и пачка домашних заготовок, позволяющих абстрагироваться от флоу, чего нет в языках где эффекты прозрачны и с ними никак не провзаимодействовать.

Например, что проще: когда побочные эффекты явно выражены присваиваниями глобальным переменным, или же когда они спрятаны в монаду?


Конечно же первое. Про второе не слышала половина респондентов, а из другой половины 80% не смогут в это. А проблема глобальных состояний сильно преувеличена, там типично пара-тройка логгеров, какой-нить настроечный файл/ПЗУ. Просто трудно остановиться с борьбой против двух вещей — расизма и глобальных состояний.
НЛО прилетело и опубликовало эту надпись здесь
Понятно, что бывает всякое. Я говорю «в среднем по больнице».

Ну и, кстати, да, если «им так удобно», и если конечная цель разработки достигается, то… И это ведь не только эмбеда касается. Знаете сколько я видел проектов, отнюдь не для эмбеда, где все было прелестно с точки зрения качества кода, но в целом работало примерно никак, и главное сделано было тогда, когда уже не нужно?
НЛО прилетело и опубликовало эту надпись здесь
«Удобно» в их случае означает лишь отсутствие необходимости изучать какие-либо новые подходы и парадигмы


Во-первых не «новые», а «другие». Во-вторых вы так говорите, будто это что-то плохое, будто должно быть так — что ни день, то парадигма.

И как показывает практика, «нет ничего более постоянного, чем временное», и случаев, когда какая-то ad-hoc write-only поделка превращается в большой долгоживущий проект, на самом деле не мало


Это, как и блок текста выше — про извечную дилемму «быстро, дешево и хорошо — выберите любые два один». Делать всегда все хорошо — это ФГУП, развал и торговля деревянными дилдо в Химках. Делать всегда коекакерски — на самом деле более благодатно с точки зрения бизнеса, особенно если не идешь на экспорт, но вообще тоже путь в никуда есесна. Поиск баланса, вот что важно. И это как про опыт всех участников, так и про целеполагание. И последнее особенно важно, критически важно. Не бывает такого, чтобы при корректном целеполагании потом оказалось, что врайт-онли превратилось в корневой проект. Когда есть внятное продуктовое управление, то в какой-то момент говорится — ок, теперь убиваем MVP и делаем рабочий дизайн. Если же оно в компании не внедрено в явном виде, то вообще невозможно всерьез обсуждать качество кода (плат, деталей и так далее). Все же «качество кода» и как на него влияет количество глобальных переменных — глубоко подлежащий вопрос.
Уважаемый автор, проясните мое сомнение. Статья очевидно не про технические аспекты, а про рекламу. Но тогда я не могу понять целевую аудиторию, и почему этим занимается в России галантерейщик, а не кардинал (простите мне эту аллюзию, она безличностная). Логичнее было бы видеть рекламу от FAE того же NXP через площадку условного Компэла, нет?

Одно другого не исключает. Заходите на стенд NXP какой-нибудь робототехнической выставки, они вам, наверное, с удовольствием расскажут про UAVCAN (за корректность не ручаюсь). Идею насчёт рекламы через Компэл всенепременно им подкину, нельзя без Компэл.

Для меня как студента-инженера (ака недоэмбеддера) было любопытно прочитать и заметку, и разделившиеся мнения о ней в комментариях. Тем не менее меня до сих пор мучает следующий вопрос: что-же все-таки делать (хотя бы будущим) разработчикам встраиваемого софта, чтобы не производить архитектурное спагетти? Как подходить к разработке низкоуровневых приложений, не оставляя после себя тысячи строк непонятного и неподдерживаемого кода?
Ваш пример с 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 я должен с ногами залезть в доку для какого-то раздутого фрейморка и пару месяцев курить доки, что бы в конце концов понять, что он не решает моих задач, не лезет в память и т.д.? Ну круто, чё ...

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории