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

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

    Редко когда речь заходит об обратной проблеме, имеющей место в куда более узких кругах разработчиков встраиваемых систем, включая системы повышенной отказоустойчивости. Есть основания полагать, что ранний опыт использования MCS51/AVR/PIC оказывается настолько психически травмирующим, что многие страдальцы затем продолжают считать байты на протяжении всей карьеры, даже когда объективных причин для этого не осталось. Это, конечно, не относится к случаям, где жёсткие ценовые ограничения задают потолок ресурсов вычислительной платформы (микроконтроллера). Но это справедливо в случаях, где цена вычислительной платформы в серии незначительна по сравнению со стоимостью изделия в целом и стоимостью разработки и верификации его нетривиального ПО, как это бывает на транспорте и сложной промышленной автоматизации. Именно о последней категории систем этот пост.

    Обычно здесь можно встретить упрёк: "Ты чё пёс А MISRA? А стандарты AUTOSAR? Ты, может, и руководства HIC++ не читал? У нас тут серьёзный бизнес, а не эти ваши побрякушки. Кран на голову упадёт, совсем мёртвый будешь." Тут нужно аккуратно осознать, что адекватное проектирование ПО и практики обеспечения функциональной корректности в ответственных системах не взаимоисключающи. Если весь ваш софт проектируется по V-модели, то вы, наверное, в этой заметке узнаете мало нового хотя бы уже потому, что ваша методология содержит пункт под многозначительным названием проектирование архитектуры. Остальных эмбедеров я призываю сесть и подумать над своим поведением.

    Не укради

    Что, в конечном итоге, говорят нам вышеупомянутые стандарты в кратком изложении? Примерно вот что:

    • Не своевольничай. Наличие каждой строчки кода должно быть однозначно обосновано низкоуровневыми техническими требованиями и проектной документацией.

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

    • Делай свои намерения явными и избегай неявных предположений. Это касается проверки инвариантов, исключения платформно-зависимых конструкций, исключения UB, unsafe и схожих граблей, заботливо разложенных языком программирования и средой исполнения.

    • Не забывай об асимптотической сложности. Ответственные системы обычно являются системами реального времени. Адептов C++ призывают воздержаться от злоупотреблений RTTI и использования динамической памяти (хотя последнее к реальному времени относят ошибочно, потому что подобающим образом реализованные malloc() и free() выполняются за постоянное время и даже с предсказуемой фрагментацией кучи).

    • Не игнорируй ошибки. Если что-то идёт не так, обрабатывай как следует, а не надейся на лучшее.

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

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

    Я имел несчастье ознакомиться с некоторым количеством встраиваемого ПО реального времени, к надёжности которого предъявляются повышенные требования, и в пугающем числе случаев я ощущал, как у меня шевелятся на голове волосы. Меня, например, сегодня уже не удивляет старая байка об ошибках в системе управления Тойоты Приус, или байка чуть поновее про Boeing 737MAX (тот самый самолёт, который проектировали клоуны под руководством обезьян). В нашем новом дивном мире скоро каждая первая система станет программно-определяемой, что (безо всякой иронии) здорово, потому что это открывает путь к решению сложных проблем затратой меньших ресурсов. Но с повальной проблемой качества системоопределяющего ПО нужно что-то делать.

    Если взять типичную встраиваемую систему достаточно высокой сложности, можно выделить примерно следующие сгустки логики:

    • Класс-бог, отвечающий за всё сущее.

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

    • Utils или helpers, без них никуда.

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

    Инфоцыгане

    Косвенным образом масла в огонь подливают некоторые поставщики программных инструментов для разработчиков встраиваемого ПО: Mbed, Arduino, и т.п. Их маркетинговые материалы вполне могут заставить начинающего специалиста поверить, что суть этой работы заключается в низкоуровневом управлении железом, потому что именно на этом аспекте диспропорционально фокусируются упомянутые поставщики ПО. Вот у меня на соседнем рабочем столе открыт в CLion проект ПО для одной встраиваемой системы; проект собирается из чуть более чем ста тысяч строк кода. Из этой сотни примерно три тысячи приходятся на драйверы периферии, остальное приходится на бизнес-логику и всякий матан. Моя скромная практика показывает, что за исключением простых устройств сложность целевой бизнес-логики приложения несопоставима с той его частью, что непосредственно работает с железом.

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

    Смотри, что я нашёл! Есть крутая новая система, Mbed называется, значит, для эмбедеров. Гляди, как можно быстро прототипы лепить! Клац, клац, и мигалка готова! Вот же, на видео. А ты, Илья, свой алгоритм оптимизации CAN фильтров пилишь уже неделю, не дело это, давай переходить на Mbed.

    Я, разумеется, не хочу сказать, что права на существование сии продукты не имеют. Конечно, имеют, и более того: они чрезвычайно полезны, когда бизнес-логика проста и сосредоточена вокруг интеграции нескольких компонентов. За примерами ходить не надо, просто откройте любой их рекламный проспект — это то, для чего они созданы. Но у меня подгорает, когда я слышу о менеджере, продвигающем эмбеддед-фреймворк для проекта, где работа с периферией и её отладка едва ли займёт 1% внимания программиста.

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

    Когда один бэкэндер лучше двух эмбедеров

    Ранее я публиковал большую обзорную статью о нашем открытом проекте UAVCAN (Uncomplicated Application-level Vehicular Computing And Networking), который позволяет строить распределённые вычислительные системы (жёсткого) реального времени в бортовых сетях поверх Ethernet, CAN FD или RS-4xx. Это фреймворк издатель-подписчик примерно как DDS или ROS, но с упором на предсказуемость, реальное время, верификацию, и с поддержкой baremetal сред.

    Для организации распределённого процесса UAVCAN предлагает предметно-ориентированный язык — DSDL — с помощью которого разработчик может указать типы данных в системе и базовые контракты, и вокруг этого затем соорудить бизнес-логику. Это работает примерно как REST эндпоинты в вебе, XMLRPC, вот это вот всё. Если взять одного обычного бэкендера — человека, измученного сервис-ориентированным проектированием и поддержкой сложных распределённых комплексов — и объяснить ему суть реального времени, то он в короткие сроки начнёт выдавать хорошие, годные интерфейсы на UAVCAN.

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

    Допустим, ответ подопытного является вариацией на тему "измерение воздушной скорости, барометрической высоты и статического давления". Тогда на свет появляются примерно следующие строки DSDL:

    # Calibrated airspeed
    uavcan.time.SynchronizedTimestamp.1.0 timestamp
    uavcan.si.unit.velocity.Scalar.1.0    calibrated_airspeed
    float16                               error_variance
    # Pressure altitude
    uavcan.time.SynchronizedTimestamp.1.0 timestamp
    uavcan.si.unit.length.Scalar.1.0      pressure_altitude
    float16                               error_variance
    # Static pressure & temperature
    uavcan.time.SynchronizedTimestamp.1.0 timestamp
    uavcan.si.unit.pressure.Scalar.1.0    static_pressure
    uavcan.si.unit.temperature.Scalar.1.0 outside_air_temperature
    float16[3] covariance_urt
    # The upper-right triangle of the covariance matrix:
    #   0 -- pascal^2
    #   1 -- pascal*kelvin
    #   2 -- kelvin^2

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

    Знакомый с физикой полёта читатель здесь уместно поинтересуется: откуда оконечному устройству (что поставляет сервис воздушных сигналов) знать калибровочные параметры датчика воздушной скорости? Ведь это предполагает осведомлённость датчика о собственном положении на летательном аппарате и об его аэродинамических свойствах. Принципы инкапсуляции и разделения ответственности предписывают, что соответствующие параметры настраиваются на самом поставщике сервиса воздушных сигналов (т.е. сетевом узле датчика) с целью сокрытия деталей реализации сервиса от его потребителей.

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

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

    uint16 differential_pressure_reading
    uint16 static_pressure_reading
    uint16 outside_air_temperature_reading

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

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

    Художника каждый может обидеть

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

    Коллеги, одумайтесь.

    Я вижу, как нашим микроскопом заколачивают ржавые гвозди, и представляю, сколько ещё подобного происходит за пределами моего поля зрения. В прошлом году уровень отчаяния в нашей скромной команде был столь высок, что мы опубликовали наноучебник, где объясняется, как выглядит сетевой сервис здорового человека: UAVCAN Interface Design Guidelines. Это, конечно, капля в море, но в один прекрасный день я всё-таки переведу его на русский язык ради подъёма уровня профессиональной грамотности.

    Непонимание основ организации распределённых вычислений затрудняет внедрение новых стандартов на замену устаревших подходов. Наши наработки в рамках стандарта DS-015 (созданного в коллаборации с небезызвестными NXP Semiconductors и Auterion AG) встречают определённое сопротивление ввиду своей непривычности для целевой аудитории, в то время как ключевые принципы, на которых они основаны, известны индустрии информационных технологий уже не одно десятилетие. Этот разрыв должен быть устранён.

    Желающие принять участие в движении за архитектурную чистоту и здравый смысл могут причаститься в телеграм-канале uavcan_ru или на форуме forum.uavcan.org.

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

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


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

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

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

            Примерно вот это: https://habr.com/ru/company/npf_vektor/blog/367653/. Да, на одном микроконтроллере.

              +2
              А зачем тут 100 k строк?
                +2

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

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

                    ¯\_(ツ)_/¯

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

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

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

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

                              Может быть по современным меркам QII и не такая уж сложная программа? В конце концов, в том же SQLite 150к строк кода, и 92 миллиона (!) строк кода в тестах.

                                +1
                                Это вряд ли. Вон сколько тут народу, но что-то уровня Quake-II ни один не написал.

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


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

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


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

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

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


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

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


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

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


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

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


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


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

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


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

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


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

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


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

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


                                      Вот как только он объяснит, как он умудрился в 100k+ сделать управление двигателями (со всеми протоколами и прочим) и запихнуть всё это в микроконтроллер, вот тогда и поверю. А пока нам рассказывают о задаче явно не соответствующей количеству строк.
                                        0

                                        Ну вот SQLite приведённый выше — 150к строк кода без тестов, компилируется в бинарник 500кбайт. Поиграть в неё, как в QII не получится. Ещё примеры нужны?

                                          0
                                          Каким образом SQLite отменяет сложность Quake-II и обосновывает 100k+ строк во встраиваемой системе автора? У него там тоже SQLite реализована на микроконтроллере?
                                            +2

                                            Я не понимаю, откуда мнение что Quake II сложная программа. Она очень даже простенькая. Ну да, там есть всякие трюки, но приложене прям "сложным" от этого не становится. Не умаляя заслуг Кармака конечно.


                                            Quake II написана за год 3 людьми. Сравните с приложенеим которое пишут 30 людей и не год а пять. А если брать не встраиваемые системы, а тот "бекенд" которы автор выше упоминает, то там пропорции бывают 300 разработчиков на 10+ лет

                                              –1
                                              Ну так в чём дело? Напишите. Просто напишите.

                                              то там пропорции бывают 300 разработчиков на 10+ лет


                                              Я тоже не понимаю, чего в науке сложного? Миллионы учёных, а нобелевку единицы получают.
                                                0
                                                Ну так в чём дело? Напишите. Просто напишите.

                                                Спервадобейся? Я уже сказал, что сложные приложения пишутся группой разработчиков. Каждого отдельно выдерни — кваку он наверное не напишет. Только что это доказывает?


                                                Я тоже не понимаю, чего в науке сложного? Миллионы учёных, а нобелевку единицы получают.

                                                То есть квейк у вас сложнее постгреса какого-нибудь я правильно понимаю? :) Или что это за аналогия такая?

                                                  0
                                                  Спервадобейся? Я уже сказал, что сложные приложения пишутся группой разработчиков.


                                                  Странно, а оценку вы всё-таки сделали. ;)
                                                  Не ваши ли слова выше «Она очень даже простенькая.» и «Quake II написана за год 3 людьми»? Ну так там и писать-то нечего. ;) Осилите? Я вот некое подобие DooM написал с нуля 19 лет назад, но у меня была книжка, где всё-всё было расписано. А без книжки хрен бы я чего сделал.

                                                  То есть квейк у вас сложнее постгреса какого-нибудь я правильно понимаю? :) Или что это за аналогия такая?


                                                  Это аналогия такая, что миллион обезьян не заменит одного высококвалифицированного специалиста.
                                                    0
                                                    Не ваши ли слова выше «Она очень даже простенькая.» и «Quake II написана за год 3 людьми»? Ну так там и писать-то нечего. ;)

                                                    А в чем проблема? Это просто 3 человекогода. Это очень небольшой объем работ по нынешним меркам, о чем тут ещё спорить?


                                                    Это аналогия такая, что миллион обезьян не заменит одного высококвалифицированного специалиста.

                                                    Надо полагать все крупные продукты написаны обезъянами, и нормальных квалифицированных специалистов там отродясь не было.

                                                      –1
                                                      А в чем проблема? Это просто 3 человекогода. Это очень небольшой объем работ по нынешним меркам, о чем тут ещё спорить?


                                                      А при чём тут объем работ? Речь шла о сложности. Так возьмите ту же электродинамику — объём работ там небольшой, но вы формул не выведете. То отдельные гении выводили.

                                                      Надо полагать все крупные продукты написаны обезъянами, и нормальных квалифицированных специалистов там отродясь не было.


                                                      То-то я смотрю уже 20 лет читаешь, что функционал тот же по сути, а ПО раздулось до невозможности. ;)
                                                        +1

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


                                                        Что сложнее Quake 2 или curl какой-нибудь? В последнем кода аж в пять раз больше, хотя казалось бы, делать HTTP запросики и всё. Да даже просто файлы грепать по-умному (ripgrep) и то половину объёма кваки получается.


                                                        Итого: QII — сложная программа 25 лет назад и совершенно непримечательная в наши дни, независимо от нашей личной способности (или неспособности) её с нуля написать.

                                        0
                                        Только какое отношение ваш кумир к разработке встраиваемых систем?
                                        Прямое. Он делал софт для ракет. См. Armadillo Aerospace.
                                        0

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


                                        Сейчас даже сам Кармак со своей командой не способен будет создать ничего подобного (по силе воздействия), потому что мир и игроки видели тысячи игр, чудовищно реалистичную графику, а железо стало мощнее в миллионы раз. Поэтому хоть бюджет типичной игры и подваливает к 100 миллионам баксов, но никакого вау-эффекта размером в quake II они не производят.

                                        +1
                                        Это узкоспециализированное пользовательское приложение

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

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


                                        50-100к имеется в виду?
                                        встраиваемых приложений?
                                    +3

                                    Когда начинаете реализовывать требования — оно все и вылезает.


                                    У нас вот например 70 микросервисов, размер каждого не очень большой — в среднем 10 kloc. Но суммарно дают почти миллион строк кода, да.


                                    И там логики-то не так уж много: почитали что-то откуда-то, что-то сделали. в очередь сообщение кинули. Но с миру по нитке — и куча кода готово.

                                      –2
                                      Для вас это предмет гордости? То, что кода много, а логики мало.
                                        +2

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


                                        Сделать MVP "крутая игра которая идет с такими-то ограничениями" это одно. Сделать так, чтобы можно было годами (десятилетиями?) её дорабатывать, чтобы запускалось на всем нужном железе, чтобы всякие метрики можно было снимать, чтобы падения были по возможности мягкими....


                                        Ну вот просто посмотрине на Linux, сколько там миллионов строк кода? И логики там тоже не сверх много: MVP операционок на хакатоне за день пишут. Но линукс у них за день почему-то не выходит никак.

                                          0
                                          «Особой» логики там нет, да. Но нюансов всегда дофига.
                                          Ну а в кваке есть и особая логика, и дофига нюансов, и куча взаимодействующих подсистем.

                                          Чего там нет — так это абстракций на абстракциях, развесистых деревьев зависимостей, сотен-тысяч сторонних библиотек, принятых в современном бэкэнде. Об этом собственно и речь.

                                          Может быть и в эмбеде вышеописанное не надо?
                                            +2
                                            Чего там нет — так это абстракций на абстракциях, развесистых деревьев зависимостей, сотен-тысяч сторонних библиотек, принятых в современном бэкэнде. Об этом собственно и речь.

                                            очень абстрактно все, давайте конкретно. Линукс это получается "абстракции на абстракциях"? И можно сделать на порядок проще? Надо бы линусу наверное пару десятков эмбедщиков нанять, срезали бы количество кода в 10 раз, а качество только поднялось бы.


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

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

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

                                                  "Проще" не значит "лучше", точно так же как "проще сейчас" не значит "проще потом". Эти все уровни абстракций берутся не потому что так написано в книге GoF или так захотелось синьору/архитектору. Опытный программист/архитектор хорошо понимает, что что в современном мире коммерческой разработки ПО простые проекты постепенно (а иногда даже и очень внезапно) могут стать сложными. И что многократно переделывать простое в сложное может оказаться гораздо сложнее и дороже, чем сделать чуть сложнее с самого начала. Иными словами, если мы делаем какое-то действие над какой-то сущностью, то казалось бы, можно сделать просто без кучи абстракций. Но в один прекрасный день заказчику захочется, чтоб над той же сущностью выполнялось похожее, но чуть-чуть другое действие. Или тоже самое действие, но над чуть-чуть другой сущностью. Или то же самое действие над той же самой сущностью, но при вызове из совсем другого места. Или чтобы оно еще при этом попукивало и мигало лампочками. Или чтобы можно было одну штуку заменить на другую более подходящую штуку, не разламывая всё, что с этой штукой взаимодействует. Или в Черную Пятницу резко возрастет нагрузка, и нужно будет часть действий вытащить в отдельный сервис на отдельный сервер, потому что первый уже захлебывается. И вот тут уже приходит понимание, что лучше бы изначально сделали всё с абстракциями и разделениями на слои, чем каждый раз пытаться впихнуть невпихуемое в "простую" структуру.

                                                  Ну и тесты, да. Если хочется не бояться что из-за правки в одном месте что-то взорвется в другом при неправильном положении Луны в доме Козерога, хорошо бы иметь покрытие тестами. Интеграционные тесты, конечно, хорошо, но чтобы не плодить стопицот миллионов ветвлений и чтобы быстрее и проще отлавливать, где конкретно и почему вы сломали, разумно тестировать гораздо более мелкие части и при необходимости подменять соседние части заглушками и ловушками. Что опять же приводит нас к дроблению конструкций и пониманию того, что паттерны -- это не фигни чтобы тешить ЧСВ на собеседованиях, а сложившиеся практики для эффективного решения часто встречающихся проблем.

                                                  И в эмбеддеде такое тоже актуально причем, гораздо чаще чем многие думают. Как тут уже метко сказали в комментах ...писал программу для прибора, так там сначала «а давай добавим ещё один экран,… ещё один интерфейс,… и что бы по WiFi в интернет отчёты отправлял,… и что бы на балалайке играл ..., так и более прозаичные вещи типа "Переезжаем с той же логикой и той же математикой на другую плату", "вместо модбаса через рс-232 теперь будем отдавать данные по эзернету", "вместо одного насоса теперь будем рулить тремя, но логика у каждого та же", и "эти наработки полезные, давайте переиспользуем их в другом изделии". Ну а покрытие тестами там зачастую даже гораздо нужнее и важнее, чем в вебдеве и десктопной разработке...

                                                    +2

                                                    Его можно сделать проще, но это усложнит последующую разработку.


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


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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

                                                0

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

                                                  0

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


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


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


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

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

                                            Интересно, а таблицы синуса, crc32 или ещё чего попадают под специфику?

                                              +15

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

                                                +1

                                                Охотно верю)

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

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

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

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


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

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

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

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

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

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

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

                                                      image

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

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

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

                                              +3
                                              Кармак ещё и для ракет софт писал. Несколько тысяч строк, с его слов.

                                              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
                                                +4

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


                                                Что вы хотите сказать вашим комментарием?

                                                  +8
                                                  В статье, которую я привёл, Кармак топит за идеи прямо противоположные вашим (меньше абстракций, проще и яснее структура, меньше кода).
                                                  Когда Кармак пишет Quake, он использует одну методологию, предпочитая скорость разработки качеству продукта.
                                                  Я немного читал код движков id-шных игр, и он на голову выше практически вообще всего, что я видел, по качеству. Да и предпосылок для того, чтобы софт для ракеты был как-то принципиально по-другому написан, по сравнению с движком кваки, особых нет.
                                                    +6
                                                    предпосылок для того, чтобы софт для ракеты был как-то принципиально по-другому написан, по сравнению с движком кваки, особых нет

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

                                                      –1
                                                      Я согласен с тем, что у разработчиков движков на практике лучше получается в надёжность, чем у бекэндеров. Поэтому уж чему, а практикам современного бекэнда в эмбэде, на мой взгляд, не место.
                                                        +7
                                                        Следовательно, разумное управление рисками предписывает, что на контроль качества Quake необходимо затратить меньше ресурсов, чем на аналогичные процессы в разработке ракеты,


                                                        Так получилось, что я знаком с разработкой очередной ракеты (которая оружие судного дня). Так вот, могу вам со всей уверенностью сообщить, что квалификация персонала в части архитектуры там ну очень низкая, а от кода и продуманности взаимодействия компонентов между собой у вас выпадут все волосы. Кстати, нужный результат достигается очень многократными проверками и прогонами одной и той же цепочки команд с ручным отслеживанием отказов. При этом 100 k строк кода там и в помине нет, а работа программы, обычно, весьма линейна (а вот математика может быть весьма сложна, но это только математика) и в случае чего просто сообщается «отказ» и на этом всё.
                                                        +1
                                                        Да и предпосылок для того, чтобы софт для ракеты был как-то принципиально по-другому написан, по сравнению с движком кваки, особых нет.

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

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

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

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

                                                    0
                                                    Охотно вам верю.
                                                      0

                                                      А драйверы от микроконтроллерной периферии не от чипвендоров существуют?

                                                        –1

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

                                                          +1

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

                                                            0
                                                            Не видел, если честно…

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


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

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

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

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

                                                                0
                                                                Лучше бы я никогда не смотрел исходники HAL для STM32. Когда функция, которая должна возвращать тики камня возвращает их с точностью до *1 мс*, а внутри кода паузы делаются циклами с volatile int--.
                                                                  0

                                                                  Интересно, драйверы не подвергаются контролю качества, а интересно ядро подвергается? Насколько тогда безопасно вообще применять камни от Microchip или ST ?

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

                                                                      А ещё довольно быстро workaround появляется в драйверах от производителя;)
                                                                      Но мой вопрос был другой

                                                                    –1
                                                                    Обратите внимание на RTEMS, NuttX, ChibiOS

                                                                    Да, действительно в ChibiOS обнаружено немного драйверов. Но их очень мало. Не уверен что ими вообще пользуются
                                                                0
                                                                в кейле для стм была библиотека спл, да еще и с ошибками.
                                                                  0
                                                                  Так в IAR тоже есть, только он её с сайта ST взял и в дистрибутив включил
                                                                +10

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

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

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

                                                                  0
                                                                  зашел чтобы увидеть именно КТ-178
                                                                  +5
                                                                  Разработчики встраиваемых систем давно программируют в симулинке решение задачи
                                                                  В одном месте из 10, а то и из 100.
                                                                  Причем чем серьезнее проект, тем меньше вероятности на подобное наткнуться.
                                                                  Возможно 90-е таких мест было поболее, да.
                                                                  +2

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

                                                                    +9
                                                                    Не следует думать, что я хочу определить всех эмбедеров в биореактор

                                                                    Значит, завтра всё-таки на работу.

                                                                    Да, бывают плохие архитектуры и плохой код проектах, но люди и компании разные и мазать всех одной краской не следует. Также, бывают вполне объективные причины — наследственный код, нехватка времени(денег), полная переработка хотелок в ТЗ, кривая архитектура на ранних этапах, которую потом не хотят переписывать, железячники часто поставляют reference-драйвера, которые просто вызывают через прокладки и пр. И одной, пусть и супер-хорошей библиотекой это не решить.
                                                                      +2

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


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

                                                                        +3
                                                                        что софт дело десятое, нам бы железку собрать — достаточно распространена
                                                                        Ни разу с таким не сталкивался, чаще было наоборот, что накупят всякого железного барахла и сношайтесь как хотите.
                                                                        «драйверы от чипвендоров», что не выдерживают никакой критики
                                                                        Есть одна российская компания, которая производит платы для MIL-STD-1553 c драйверами под Linux, на которые без слез не взглянешь и cli/sti на любой чих было не самой большой бедой — они просто не работали на «больших» скоростях. Ну что ж, не привыкать — переписал «с нуля» для проекта, предложили производителю. Так им этот драйвер был неинтересен даже за символическую плату. За всю практику, может, было лишь пару случаев, когда можно было пользоваться драйверами от производителя.
                                                                          0
                                                                          Есть одна российская компания, которая производит платы для MIL-STD-1553 c драйверами под Linux,


                                                                          Элкус? :)
                                                                            0
                                                                            Поскольку драйвера в открытом доступе, то да. Узреть всё своими глазами можно здесь, файл tmknll.c не рекомендуется к просмотру людям с неустойчивой психикой, беременным и детям до 30 лет.
                                                                              0
                                                                              Да я как бы знаю (так как использую их плату). :)
                                                                                0
                                                                                Но там прилично переписывать с нуля то…
                                                                                  0
                                                                                  Нет, через 2 недели новый драйвер передавал сообщения, неделя на вылизование кода и еще неделя ушла на воспроизведение ошибки на их драйвере, чтобы убедить железячников исправить прошивку.
                                                                                    0
                                                                                    Ну месяц приличный срок
                                                                                    для одной архитектуры переписали?
                                                                                      +1
                                                                                      3 недели, ошибка в прошивке всплыла рано или поздно на любом драйвере. Да, только Intel + *Linux*.
                                                                                        0
                                                                                        Незачёт элкусу.
                                                                                        Надеюсь хоть ошибку исправили
                                                                            +1
                                                                            Это всегда вопрос ресурсов, приоритетов и процессов разработки. И на мой взгляд последнее для встраиваемых систем не так уж и сильно отличается от всего остального мира. SOLID, CI/CD, парное программирование, тестирование кода и т.д. — ничего нового здесь нет.
                                                                            Я был во многих крупных проектах в эмбеддинге и там, где был грамотно выстроен процесс разработки и ресурсы позволяли, везде была вполне сносная архитектура кода, которая позволяла параллельно работать десяткам и сотням людей над проектом.
                                                                            Ну а если ресурсов хватает лишь на одного человека на полставки, то немудрено, что код будет тяп-ляп и готово.
                                                                          +16
                                                                          Сперва размазал пространных рассуждений, а потом вкинул рекламу своего велосипеда, ведь существующие обладают фатальным недостатком.
                                                                            –2

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

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

                                                                            а что вы подразумеваете под программированием?
                                                                            разработчик встроенных систем в первую очередь — электронщик электрик механик — и уж затем вишенка на тортике — программист
                                                                            причем если берем сферу микроконтроллеров — то там царит язык Си.
                                                                            я много писал на Си для микроконтроллеров — там вообще не было работы с файлами.
                                                                            это кардинально отличается от общего программирования — где работа с файлами — это главное.
                                                                            и я еще помню времена в 90ых когда спорили что лучше Си или ассемблер
                                                                            потому что процесоры работали на единицах мегагерц а с учетом количества тактов на операцию их реальное быстродействие было меньше 100 000 операций в секунду.
                                                                            что как бы и хватает для механики ( станков и промоборудования ) — но маловато для работы с электронными сигналами. поэтому в то время та сфера полностью обходилась минималистическими средствами программирования.
                                                                            во втором десятилетии 21 века микроконтроллеры перешагнули 100 мгц тактовой да еще с учетом что теперь часто операция выполняется за 1-2 такта — уже стали иметь место физические ограничения по вводу выводу. как известно сигналы больше 10-15 мгц уже требуют не тривиальной разводки и борьбы с помехами. с одной стороны чудовищно расширился круг возможностей микроконтроллеров — с другой стороны стремление упрощения программирования и туда пришло. скажем здравствуй языку питон — который пришел в микроконтроллеры — очень медленный язык но кому то очень удобный.
                                                                            или — если можно забивать гвозди микроскопом — то почему бы этого не делать?
                                                                            молотков мало ( медленных микроконтроллеров) а микроскопов много — (stm32).
                                                                            и стоят микроскопы stm32 уже дешевле молотков 8051 произведенных микрочипом.
                                                                            как человек много лет программировавший встроенную электронику — скажу — я заново учусь программированию когда пишу для вэб.
                                                                            программирование встройки и вэба имеют столько же общего как профессия штурмана в авиации и мореплавании.
                                                                            и там и там одинаковое штурманское дело — но с разными концепциями применения
                                                                              0
                                                                              разработчик встроенных систем в первую очередь — электронщик электрик механик — и уж затем вишенка на тортике — программист

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


                                                                              программирование встройки и вэба имеют столько же общего как профессия штурмана в авиации и мореплавании.

                                                                              Это может быть правдой, но это не означает, что разумное заимствование уместных практик из одного в другое не должно иметь места. Проблема в том, что рядовой эмбедер (основываясь исключительно на личном опыте) не видит разницы между интерфейсом и полиморфным классом, и не понимает, зачем нужно метапрограммирование, если есть void*. С этим следует бороться просветительскими методами.

                                                                                +3
                                                                                Это могло быть так до тех пор, пока ПО не стало в достаточной мере, если можно так выразиться, «системоопределяющим»

                                                                                людей пишущих софт для радаров или самолетов или аэс- мизер.
                                                                                а людей пишущих софт для тнп и промышленного оборудования — весь остальной мир.
                                                                                то есть все те премудрости стандартов MIL-XXXX — в промке и тнп — не нужны.
                                                                                я вот сам занимаюсь попыткой все в жизни делать в вэб после смерти windows XP — но и там слишком много телодвижений чтоб сделать простые вещи.
                                                                                современное программирование слишком увлеклось инкапсуляцией реальности
                                                                                +3

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

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

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


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

                                                                                      0
                                                                                      в микроконтроллерах часто бывает что пишешь програмку ножкодергалку.
                                                                                      это когда микроконтроллер выступает просто многофункциональной схемой — такое часто бывает.
                                                                                      там просто составляешь диаграмму работы устройства — и через паузы дергаешь ножки.
                                                                                      такой код — даже я спустя время свой не понимаю. потому что без описания всего устройства — его не вкурить.
                                                                                      еще раз говорю эмбедеры не изучают класические алгоритмы — они им не нужны.
                                                                                      они не манипулируют данными — они манипулируют сигналом и временем.
                                                                                      а на это библиотек алгоритмов нет
                                                                                        –1
                                                                                        эмбедеры не изучают класические алгоритмы — они им не нужны.
                                                                                        они не манипулируют данными

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

                                                                                          0
                                                                                          Вы напрасно вычёркиваете людей, которые занимаются реализацией сложных поведений из числа эмбедеров

                                                                                          я не вычеркиваю — я сразу оговорился в коментах — что рлс самолеты и аэс програмирует мало кто

                                                                                          всем остальным — знание сортировки пузырьком и прочего — как правило не нужно
                                                                                          говорю как человек поработавший и там и там
                                                                                          +6
                                                                                          еще раз говорю эмбедеры не изучают класические алгоритмы — они им не нужны.

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


                                                                                          они манипулируют сигналом и временем.
                                                                                          а на это библиотек алгоритмов нет

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


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

                                                                                          И если бы вы "изучали стандартные алгоритмы", то приделали бы сюда совершенно стандартную fsm, например.

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

                                                                                            нет ничего такого
                                                                                            эмбеддеры как раз одержимы сделать все по минимуму
                                                                                            тонн говнокода у них не бывает
                                                                                            всегда эмбеддерам ставят в вину что они делают самолет
                                                                                            за это да — ругают
                                                                                            потому как время тоже — деньги
                                                                                            а гомнокодерство — это там где используют шаблоны
                                                                                            И если бы вы «изучали стандартные алгоритмы», то приделали бы сюда совершенно стандартную fsm, например.

                                                                                            самый простой пример
                                                                                            шаговый мотор можно подключить множеством способов.
                                                                                            да и шаговые моторы бывают разные
                                                                                            я не слыхал о универсальной библиотеке управления моторами — аналогичной STL Степанова
                                                                                              0
                                                                                              тонн говнокода у них не бывает
                                                                                              Ещё как бывает, на каждом шагу почти, сам лично регулярно встречал в прошлом. Особенно если оценивать % говнокода от общего объёма кодовой базы :(
                                                                                              я не слыхал о универсальной библиотеке управления моторами — аналогичной STL Степанова
                                                                                              Вам говорят что для забивания гвоздей лучше использовать молоток, а не пытаться соорудить что-то из тапочка и кирпича, а вы в ответ говорите, что не встречали ещё молотков подходящих ко всем видам гвоздей, и со шляпкой 2 мм, и со шляпкой 20 см…
                                                                                              Для того, чтобы запилить простейшую FSM, не нужно никакой библиотеки, достаточно просто знать, что такое конечный автомат. Самый что ни на есть «классический алгоритм».
                                                                                                +3
                                                                                                я не слыхал о универсальной библиотеке управления моторами — аналогичной STL Степанова

                                                                                                Ну вот простенькая либа для FSM https://github.com/digint/tinyfsm
                                                                                                (да, я знаю что сипипи, но у си в целом с либами туго).


                                                                                                В достаточно продвинутых системах типов у вас даже попытка перейти из состояния 1 в состояние 5 может давать ошибку компиляции (при условии что это запрещенный переход офк).


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

                                                                                                  0
                                                                                                  у си в целом с либами туго


                                                                                                  O_o
                                                                                                  github.com/topics/state-machine?l=c
                                                                                                  Here are 48 public repositories

                                                                                                  На си подключить библиотеки сложно, больно

                                                                                                  O_o
                                                                                                  #include "header.h"

                                                                                                  И не забыть добавить файлы с исходниками в сборку.
                                                                                                  А в С++ не так?
                                                                                                    +2

                                                                                                    А этот header.h откуда взять?


                                                                                                    А в С++ не так?

                                                                                                    Нет, там через vcpkg можно ставить пакеты в +- 1 строчку.

                                                                                                      0
                                                                                                      А этот header.h откуда взять?


                                                                                                      В README.md обычно написано.

                                                                                                      Нет, там через vcpkg можно ставить пакеты в +- 1 строчку.


                                                                                                      #include «header.h» и добавление исходников в сборку (правка CMakeLists.txt) всё равно делается руками. И если разработчиков >1 — всегда есть вероятность, что один на свою машину установит одну версию исходников библиотеки, другой — другую, и результаты работы у них будут немного отличаться.
                                                                                                        +2
                                                                                                        В README.md обычно написано.

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


                                                                                                        И если разработчиков >1 — всегда есть вероятность, что один на свою машину установит одну версию исходников библиотеки, другой — другую, и результаты работы у них будут немного отличаться.

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


                                                                                                        А подключение зависимостей должно выглядеть вот так:


                                                                                                        [dependencies]
                                                                                                        iced = {version = "0.3.0", features=["canvas"] }
                                                                                                        rand = "0.8.3"

                                                                                                        Без readme.




                                                                                                        Кстати, обратите внимание что в случае cfg_if по ссылке выше зарезолвились две разных версии 0.1.10 и 1.0.0. Потому что где-то в транзитивных зависимостях используется одна версия, а в других — другая. Пакетник тут за меня проблему решил, подсунув каждой зависимости ту версию, которую она ожидает. В ридми это тоже описывается или каждый раз приходится выдумывать свое решение? Или "Такого не должно быть никогда"?

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

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


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

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


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

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

                                                                                                        0
                                                                                                        del, не та ветка.
                                                                                                        0
                                                                                                          +1
                                                                                                          А в С++ не так?
                                                                                                          Кстати, что в мире С, что в мире C++ все больше и больше проектов еще используют conan.io, например. Который в том числе умеет в интеграцию с Yocto и поддерживает даже сборки для bare metal.
                                                                                                        +2
                                                                                                        нет ничего такого

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


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

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


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

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


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

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

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

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

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

                                                                                                      0
                                                                                                      читаемость кода
                                                                                                  0
                                                                                                  это кардинально отличается от общего программирования — где работа с файлами — это главное.

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


                                                                                                  Непонятно, что за общее программирование.


                                                                                                  А от си у меня уже полгода вялотекущий баттхерт оттого, что семантика static внутри функции немного отличается от плюсовой, C11 с call_once есть не везде, позикс тоже есть не везде, а обмазываться атомиками лень, в итоге меня час назад снова попросили переделать мой пуллреквест (ну, когда выяснилось, что threads.h нет на макоси). Но это так, жёсткий оффтоп, просто выговориться, спасибо.

                                                                                                    +1
                                                                                                    А от си у меня уже полгода вялотекущий баттхерт оттого, что семантика static внутри функции немного отличается от плюсовой

                                                                                                    А существование обратного баттхерта допускаете?
                                                                                                      +1

                                                                                                      Нет: фичи static в плюсах являются строгим надмножеством таковых из C (если я не совсем забыл стандарты, конечно). Отчего там баттхёртить?


                                                                                                      Ну и да, раз пошла такая пьянка — предложите, как написать аналог того, что в C++ делается в одну строчку:


                                                                                                      static const SomeFuncPtr_t func = choose_func_based_on_cpuid();

                                                                                                      call_once нельзя (есть не на всех целевых платформах), pthread_once нельзя (под виндой будут проблемы), TLS нельзя (там тоже не очень понятные мне проблемы). Остаются атомики, увы.

                                                                                                        0

                                                                                                        Впрочем, извините, атомики не остаются: я тут ещё почитал стандарт и понял, что, похоже, вполне могут существовать реализации С, где нет в стандартной библиотеке ни тредов (__STDC_NO_THREADS__ — например, clang под macos big sur), ни атомиков (__STDC_NO_ATOMICS__, хз какие, но стандарт разрешает), но платформенные возможности для трединга есть. Соответственно, как решить упомянутую рядом задачу на стандартном, кроссплатформенном С, мне решительно непонятно. Пока что я склоняюсь к тому, чтобы просто откатываться к самой тупой версии функции в случае __STDC_NO_ATOMICS__ без рантайм-выбора оптимальной реализации функции, но это звучит как совершенно адовая заплатка и костыль. Непонятно, как настоящие сишники решают эту проблему.

                                                                                                        –1
                                                                                                        Непонятно, что за общее программирование.

                                                                                                        unix way
                                                                                                          +2

                                                                                                          Думается, доля настоящего юниксвея в работе современного программиста исчезающе мала.

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

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

                                                                                                                +1

                                                                                                                Ну да, "файловым дескриптором" может быть не только файл, но и сетевой сокет (на другом конце которого браузер, база данных или брокер с сервисами), именованный канал, устройство, и даже замаппленная область памяти.
                                                                                                                Вот только "читаем из вебсокета, пишем в пайп базы данных", по своей сути особо не отличается от записи в EEPROM и чтения данных с датчика с АЦП через I2C или SPI, что в Embedded на каждом шагу встречается (а с современными микросхемами так вообще зачастую можно разговаривать в форме запрос-ответ).

                                                                                                            –5
                                                                                                            Хорошего программиста низкоуровневым не назовут :)
                                                                                                              +1

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


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

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

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

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

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

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

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

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

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

                                                                                                                  Я, если начистоту, учусь у fillpackart. Но, видимо, без особого успеха.

                                                                                                                    +3

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

                                                                                                                  +5

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

                                                                                                                    –3

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

                                                                                                                      +2

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

                                                                                                                    +4

                                                                                                                    Тут на самом деле все гораздо глубже, проблема гораздо более комплексная и скорее психологически-идеологическая. Вспоминается старая классика:

                                                                                                                    «Открою ужасающий секрет — embedded-софт тестируют как минимум на порядок меньше и хуже, чем любой зачуханный веб-сервер. И пишут его зачастую динозавры, отладчик — это для слабаков, а «если код компилируется, значит, все работает».
                                                                                                                    … Я не шучу, к сожалению».
                                                                                                                    [из комментариев]
                                                                                                                    «Ничего удивительного. По моим наблюдениям, многие «железячники» считают, что производство устройства — это искусство, подвластное избранным, а вот написать к нему код он сможет сам, так, на коленке. Это ж вообще мелочь. Получается работающий тихий ужас. Они очень обижаются, когда им на пальцах объясняют, почему их код дурно пахнет, потому что… ну… они ж железку сделали, че тут, программа какая-то».
                                                                                                                    [из комментариев]
                                                                                                                      +2
                                                                                                                      если код компилируется, значит, все работает

                                                                                                                      Как хаскелист (и агдист-идрисист на полставки) одобряю такой подход.

                                                                                                                        0

                                                                                                                        … ага, особенно когда код на деле пишется не на хаскеле, а на C (ресурсов мало, а как готовить C++ с нулевым оверхедом никто ниасилил) или C++98 (потому что древний компилятор целевой платформы не умеет ни во что более современное, а если и умеет, то "напридумывал тут всякого новья, некогда разбираться, работать надо")

                                                                                                                      +3
                                                                                                                      Есть основания полагать, что ранний опыт использования MCS51/AVR/PIC оказывается настолько психически травмирующим, что многие страдальцы затем продолжают считать байты на протяжении всей карьеры, даже когда объективных причин для этого не осталось.
                                                                                                                      Считать байты и контролировать работу процессора до такта — это, наоборот, прикольно. Жалко, быстро становится невозможным уже на сколь-нибудь крупных проектах.
                                                                                                                        +15
                                                                                                                        Вот вам взгляд из соседней амбразуры.
                                                                                                                        Не всегда и не везде возможно запихнуть в контроллер чисто физически все ваши 100к правильных и красивых строк кода. Хорошо, когда вы пилите электронику для БелАЗа (там есть, куда всё запихнуть). А если это маленький дрон с очень ограниченным энергообеспечением, которое хорошо бы потратить на полетное время, а не на сотни мегагерц, чтобы ваш убер-сервер по супер-пупер шине подписался на датчик и опросил бы его? Или некое носимое устройство (от которого иногда жизнь зависит), которое должно гарантированно отработать не менее скольких-то часов от какого-то, извините, говна, которое пользователь туда засунет в качестве источника питания. А приходит вот такой правильный программист, не считающий байты и говорит — не, чувак, я ногодрыгалку на двух мегагерцах не напишу. Мне тут нужна ртос, оперативы побольше и вообще линупс хочу, там всё по щелчку пальцев делается готовыми библиотеками. А есть ведь еще ограничения на бюджет всей затеи. И хорошо бы прибыль после разработки начать получать.

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

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

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

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

                                                                                                                                +3
                                                                                                                                Если должно работать гарантированно и качественно — нужны тесты.
                                                                                                                                У тестов кроме того, что они непосредственно тестируют, есть еще и другое преимущество — наличие тестов вынуждает иметь нормальную архитектуру, поддающуюся тестированию. Что влечет за собой как раз-таки нормальное структурирование и дробление программы на модули и функциональные части, отсутствие жестких связей между ними и всякого треша типа тонны глобальных переменных. Что, в свою очередь, положительно влияет на читабельность, поддерживаемость и надежность кода.
                                                                                                                                И при правильном подходе, как уже было сказано, итоговый бинарь практически не раздувает.
                                                                                                                                –1
                                                                                                                                Бесполезно. Подсчёт байтов требует не только знание, но и понимание, а это уже другая лига.
                                                                                                                                +1

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

                                                                                                                                  0

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

                                                                                                                                  +1

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

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

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

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

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