Я очень рад, что вы знакомы в общих чертах с алгоритмом векторного управления, честно. Однако, запись формулы отличается от законченного продукта примерно как теория отличается от практики. Ваш ответ заставляет меня заподозрить, что с практическими внедрениями с корректной обработкой граничных случаев, вспомогательными режимами, коммуникационными протоколами, тестами, и т.п. вы никогда не сталкивались, иначе не писали бы здесь про один экран. Зачем вы это написали вообще? Что хотели сказать?
Я не вижу связи между программными пакетами для автомониторинга (self-test), на которые вы ссылаетесь, и драйверами периферии, которые мы обсуждаем в этой ветке.
эмбедеры не изучают класические алгоритмы — они им не нужны.
они не манипулируют данными
Моя заметка не про этих. Я вот в начале оставил оговорку, что мои соображения применимы лишь к проектам высокой сложности. Вы напрасно вычёркиваете людей, которые занимаются реализацией сложных поведений из числа эмбедеров.
предпосылок для того, чтобы софт для ракеты был как-то принципиально по-другому написан, по сравнению с движком кваки, особых нет
Вы согласны с тем, что разные вводные могут повлечь разные подходы к реализации? В плане интересов бизнеса, единичный отказ движка Quake обойдётся компании в несколько порядков меньшую сумму, чем единичный отказ ракеты. Усилия по снижению вероятности отказа стоят времени инженерного персонала. Следовательно, разумное управление рисками предписывает, что на контроль качества Quake необходимо затратить меньше ресурсов, чем на аналогичные процессы в разработке ракеты, иначе будет иметь место неоптимальное распределение ресурсов. Вы согласны с этим?
Возможно, хотя бы часть этих проблем можно решить банальным изменением отношения к вопросу. Просто сейчас точка зрения, которой делится 0FFH в комментарии ниже — что софт дело десятое, нам бы железку собрать — достаточно распространена, к сожалению. Именно здесь видится целесообразным применение упомянутых мною там же просветительских методов.
Технический долг (в отношении кодовой базы) не является вымыслом прикладников, это вполне реальная вещь, игнорирование которой порождает пресловутые "драйверы от чипвендоров", что не выдерживают никакой критики.
Я, если честно, утратил нить дискуссии к этому моменту. Вы хотите, чтобы я код выложил, или подробно рассказал о его устройстве? Это проприетарный продукт. Однако, с моим опенсорсным кодом вы можете ознакомиться на том же гитхабе. Я не ожидал, что упоминание сложных эмбедов привлечёт столько внимания.
Вы прекрасно читаете между строк. Есть класс новых проблем, с которыми наш велосипед справляется лучше других, о чём я подробно писал в предыдущем посте.
разработчик встроенных систем в первую очередь — электронщик электрик механик — и уж затем вишенка на тортике — программист
Это могло быть так до тех пор, пока ПО не стало в достаточной мере, если можно так выразиться, "системоопределяющим" (как инверсия термина "программно-определяемая система"). Учитывая роль ПО в современных продуктах, нельзя рассматривать эту дисциплину как придаток прочих процессов проектирования — баланс сместился. Впрочем, я не умаляю важности работы электронщиков и механиков.
программирование встройки и вэба имеют столько же общего как профессия штурмана в авиации и мореплавании.
Это может быть правдой, но это не означает, что разумное заимствование уместных практик из одного в другое не должно иметь места. Проблема в том, что рядовой эмбедер (основываясь исключительно на личном опыте) не видит разницы между интерфейсом и полиморфным классом, и не понимает, зачем нужно метапрограммирование, если есть void*. С этим следует бороться просветительскими методами.
Кармак молодец вообще, серьёзно. Только к дискуссии это какое отношение имеет? Когда Кармак пишет Quake, он использует одну методологию, предпочитая скорость разработки качеству продукта. Когда Кармак пишет софт для ракеты, он использует другую методологию, инвестируя в качество в ущерб скорости, потому что он понимает, что баланс риска совершенно иной.
Обратите внимание на RTEMS, NuttX, ChibiOS. Ещё, вероятно, драйверы поставляются с Zephyr, но я лично дела с ней не имел.
Не ну можно конечно, но зачем, если есть от чипвендора...
См. дискуссию выше. Драйверы, например, от Microchip, для их Automotive микроконтроллеров не подвергаются никакому контролю качества. То же самое можно сказать о популярном здесь ST Microelectronics. Если вы делаете сертифицируемый продукт, использовать эти драйверы вы всё равно, скорее всего, не сможете. Если вы делаете обычный продукт, то даже в этом случае использование кода с крайне высокой плотностью ошибок не оправдает экономии, если только продукт не совсем простой (об этом оговорка в начале статьи).
Это верно, я даже больше скажу: если бы она была написана как предлагается в статье, idSoftware обанкротились бы ещё до выхода продукта. Инструменты и методы подбираются сообразно задаче.
V-модель это методология разработки и управления проектом. Симулинк это инструмент реализации. Эти вещи никак не связаны. Даже если ваш код генерирует симулинк, это не отменяет потребности в формировании проектных требований с последующей валидацией и верификацией. Не следует думать, что V-модель куда-то ушла, она по-прежнему применяется при разработке ответственных систем. Например, обратите внимание на процесс сертификации DO-178.
Я очень рад, что вы знакомы в общих чертах с алгоритмом векторного управления, честно. Однако, запись формулы отличается от законченного продукта примерно как теория отличается от практики. Ваш ответ заставляет меня заподозрить, что с практическими внедрениями с корректной обработкой граничных случаев, вспомогательными режимами, коммуникационными протоколами, тестами, и т.п. вы никогда не сталкивались, иначе не писали бы здесь про один экран. Зачем вы это написали вообще? Что хотели сказать?
Конечно, не все такие, но вы согласны с тем, что проблема имеет место?
Я не вижу связи между программными пакетами для автомониторинга (self-test), на которые вы ссылаетесь, и драйверами периферии, которые мы обсуждаем в этой ветке.
Моя заметка не про этих. Я вот в начале оставил оговорку, что мои соображения применимы лишь к проектам высокой сложности. Вы напрасно вычёркиваете людей, которые занимаются реализацией сложных поведений из числа эмбедеров.
Вы согласны с тем, что разные вводные могут повлечь разные подходы к реализации? В плане интересов бизнеса, единичный отказ движка Quake обойдётся компании в несколько порядков меньшую сумму, чем единичный отказ ракеты. Усилия по снижению вероятности отказа стоят времени инженерного персонала. Следовательно, разумное управление рисками предписывает, что на контроль качества Quake необходимо затратить меньше ресурсов, чем на аналогичные процессы в разработке ракеты, иначе будет иметь место неоптимальное распределение ресурсов. Вы согласны с этим?
А как же. Для комментариев с хабра там ещё отдельный файл тоже.
Я, если начистоту, учусь у fillpackart. Но, видимо, без особого успеха.
Возможно, хотя бы часть этих проблем можно решить банальным изменением отношения к вопросу. Просто сейчас точка зрения, которой делится 0FFH в комментарии ниже — что софт дело десятое, нам бы железку собрать — достаточно распространена, к сожалению. Именно здесь видится целесообразным применение упомянутых мною там же просветительских методов.
Технический долг (в отношении кодовой базы) не является вымыслом прикладников, это вполне реальная вещь, игнорирование которой порождает пресловутые "драйверы от чипвендоров", что не выдерживают никакой критики.
Я, если честно, утратил нить дискуссии к этому моменту. Вы хотите, чтобы я код выложил, или подробно рассказал о его устройстве? Это проприетарный продукт. Однако, с моим опенсорсным кодом вы можете ознакомиться на том же гитхабе. Я не ожидал, что упоминание сложных эмбедов привлечёт столько внимания.
Вы прекрасно читаете между строк. Есть класс новых проблем, с которыми наш велосипед справляется лучше других, о чём я подробно писал в предыдущем посте.
Это могло быть так до тех пор, пока ПО не стало в достаточной мере, если можно так выразиться, "системоопределяющим" (как инверсия термина "программно-определяемая система"). Учитывая роль ПО в современных продуктах, нельзя рассматривать эту дисциплину как придаток прочих процессов проектирования — баланс сместился. Впрочем, я не умаляю важности работы электронщиков и механиков.
Это может быть правдой, но это не означает, что разумное заимствование уместных практик из одного в другое не должно иметь места. Проблема в том, что рядовой эмбедер (основываясь исключительно на личном опыте) не видит разницы между интерфейсом и полиморфным классом, и не понимает, зачем нужно метапрограммирование, если есть
void*. С этим следует бороться просветительскими методами.Кармак молодец вообще, серьёзно. Только к дискуссии это какое отношение имеет? Когда Кармак пишет Quake, он использует одну методологию, предпочитая скорость разработки качеству продукта. Когда Кармак пишет софт для ракеты, он использует другую методологию, инвестируя в качество в ущерб скорости, потому что он понимает, что баланс риска совершенно иной.
Что вы хотите сказать вашим комментарием?
Обратите внимание на RTEMS, NuttX, ChibiOS. Ещё, вероятно, драйверы поставляются с Zephyr, но я лично дела с ней не имел.
См. дискуссию выше. Драйверы, например, от Microchip, для их Automotive микроконтроллеров не подвергаются никакому контролю качества. То же самое можно сказать о популярном здесь ST Microelectronics. Если вы делаете сертифицируемый продукт, использовать эти драйверы вы всё равно, скорее всего, не сможете. Если вы делаете обычный продукт, то даже в этом случае использование кода с крайне высокой плотностью ошибок не оправдает экономии, если только продукт не совсем простой (об этом оговорка в начале статьи).
Конечно, ведь иногда есть драйверы от вендора ОС, либо свои доморощенные.
¯\_(ツ)_/¯
Это верно, я даже больше скажу: если бы она была написана как предлагается в статье, idSoftware обанкротились бы ещё до выхода продукта. Инструменты и методы подбираются сообразно задаче.
Есть местная специфика.
V-модель это методология разработки и управления проектом. Симулинк это инструмент реализации. Эти вещи никак не связаны. Даже если ваш код генерирует симулинк, это не отменяет потребности в формировании проектных требований с последующей валидацией и верификацией. Не следует думать, что V-модель куда-то ушла, она по-прежнему применяется при разработке ответственных систем. Например, обратите внимание на процесс сертификации DO-178.
Примерно вот это: https://habr.com/ru/company/npf_vektor/blog/367653/. Да, на одном микроконтроллере.
А драйверы для микроконтроллерной периферии от чипвендоров вы видели? Мысль о том, что они работают в реальных продуктах не даёт мне спать по ночам.