Что инженеры прошивки могут узнать у инженеров-программистов?

Ответ 1

Что инженеры прошивки могут узнать у инженеров-программистов? Много!

Я удивлен тем, как сегодня реализуется аналогичная разработка прошивки, так как это было 25 лет назад, когда мы впервые начали использовать C для встроенной разработки. C был большим шагом вперед от ассемблера, но есть еще много уроков, которые инженеры прошивки могут и должны учиться. Да, некоторые из инструментов лучше, но многие практики застряли в 70-х и 80-х годах.

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

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

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

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

Управление зависимостями

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

На практике это означает, что только ограниченное подмножество программных модулей должно иметь знание базового оборудования (и операционной системы). По мере того, как аппаратное обеспечение развивается, и это всегда происходит, инвестиции в аппаратный независимый код могут быть сохранены. См. Мой ah ha!.

Роберт Мартин много писал о принципах дизайна SOLID. Встроенные разработчики должны узнать их и применить их к своим проектам.

• Принцип ответственности S-Singled
• Открытые закрытые принципы
• Принцип замены L-Лискова
• Принцип разделения I-интерфейса
• Принцип инверсии D-зависимостей

Эти принципы приводят к проектам, которые лучше выдерживают испытание временем. Принципы SOLID поощряют создание единых и независимых модулей. Они основаны на объектно-ориентированных идеях, но могут быть применены к C. Мы должны остановить структуру данных вызова функций бесплатно для всех, что слишком распространено во встроенном C-коде.

Языки С++ и OO

Почему вы не можете использовать С++ и OO? Потому что они слишком медленные или слишком большие. Какие факты? С++ - это большой и загадочный язык, но вам не нужно его использовать. Взгляните на Почему вы все еще используете C?

С++ компенсирует некоторые проблемы, с которыми C не очень помогает:

• Укрытие инкапсуляции и информации
• Программирование на интерфейсы
• Подставляемые объекты
• Специальная инициализация

С++ можно эффективно использовать для встроенной разработки. Ну, вам нужен компилятор С++ и запас. Возможно, это невозможно в вашем мире, или, может быть, это стоимость ведения бизнеса. Начните с изучения:

• classes - это структуры с функциями-членами, а также данные-члены.Конструкторы
• - это позволяет все время инициализировать правильно.
• деструкторы - если вы изучаете конструкторы, вы также должны научиться деструкторам сохранять равновесие Вселенной.
• inheritance - использовать это в основном для определения интерфейсов, содержащих только чистые виртуальные функции. Интерфейсы обеспечивают важные разрывы зависимостей и точки гибкости. Как правило, они несправедливо обескуражены во встроенных. Здесь не должно быть никаких тайн или предрассудков; Виртуальные функции - это указатели на функции под капотом. Альтернативой эффективному использованию интерфейсов является сложная условная логика, то, что встроенные C-программы обычно имеют слишком много.

Если встроенные разработчики использовали эти части С++, они могли бы создавать более гибкий дизайн и не обладать высокой стоимостью.

Разработка, управляемая тестированием

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

Embedded представляет некоторые уникальные проблемы для TDD. Например, TDD требует чрезвычайно быстрого инкрементного цикла редактирования/компиляции/ссылки/запуска. Для многих встроенных разработчиков это означает осторожное Управление зависимостями и запуск unit test сначала на цель. Подробнее о адаптация TDD для встроенных.

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

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

Непрерывный рефакторинг

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

Непрерывная интеграция

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

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

Инкрементальная доставка

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

Сотрудничество

Встроенные разработчики! выходите оттуда кубиками и работайте вместе. Как вы можете стать лучше, когда увидите только свой собственный код? Как вы можете улучшить, когда вы являетесь экспертом по технологии XXX, освоили его и не получили возможность работать в разных областях.

Есть много, чтобы узнать там. Вы несете ответственность за то, что вы все можете

Ответ 2

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

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

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

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

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

Ответ 3

• Контроль источника
• Тестирование модулей (TDD)
• Непрерывная интеграция (или ночная сборка)
• Отслеживание ошибок

Инженеры прошивки, с которыми я работал, ничего не делают.

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

Ответ 4

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

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

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

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

К счастью, есть те, кто пытается компенсировать это. Я настоятельно рекомендую прочитать статьи Джека Гансля (на его веб-сайт и в его обычной колонке embedded.com).

Кроме того, MISRA-C был создан некоторое время назад, чтобы попытаться избежать общих источников ошибок в программном обеспечении C для автомобильной промышленности, и с тех пор он был принят многими во встроенном мире программного обеспечения. Добавьте статический анализатор, например PC-Lint, и вы уже кое-что улучшили свой код.

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

Кстати, более подробно о неприменении С++ во встроенных системах см. этот вопрос.

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

Некоторые из других веб-сайтов, которые я часто посещаю, включают:

• Блог и подкаст
• The Daily WTF
• Обсуждение качества
• Ужас кодирования
• Secret Geek
• Joel on Software
• Разный Блог; это один, предназначенный для встроенных систем.

РЕДАКТИРОВАТЬ: В ответ на комментарий Gabe, "какие инструменты мы должны искать для адаптации?", несколько примеров spring:

Независимые от компилятора IDE: много IDEs для C, но, насколько я могу судить, немногие из них могут быть использовались для их небольшого потенциала без совместимого компилятора. Я бы хотел, чтобы разработчики компилятора и разработчики IDE сходились, чтобы в идеале любой компилятор мог использоваться с любой IDE.

В отсутствие совместимого компилятора я хотел бы использовать PC-Lint (или эквивалент) в качестве своего "официального" компилятора с IDE по своему выбору.

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

PS: колонка Джона Гансля на этой неделе озаглавлена: " Что делает встроенные разные?", и так (свободно) связано с вопрос выше.

Ответ 5

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

Что касается С++, то понятно, что не стесняйтесь вникать в него, потому что много накладных расходов по сравнению с C. C почти похоже на язык ассемблера с libc, тогда как на С++ даже простой вызов функции может быть виртуальным. Внедрение полного времени выполнения С++ не может быть таким простым, учитывая сложность языка.

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

Тест Джоэля

• Используете ли вы контроль источника?
• Можете ли вы сделать сборку за один шаг?
• Делаете ли вы ежедневные сборки?
• У вас есть база данных ошибок?
• Вы исправляете ошибки перед написанием нового кода?
• У вас есть современное расписание?
• Есть ли у вас спецификация?
• У программистов есть спокойные условия работы?
• Используете ли вы лучшие инструменты, которые могут купить деньги?
• У вас есть тестеры?
• Записывают ли новые кандидаты код во время интервью?
• Вы проводите тестирование удобства пользования прихожей?

Ответ 6

Прошивка достаточно широка. От PIC до DSP все они имеют разную степень физических ресурсов. В наши дни DSP довольно мощные (сравнимые с процессорами ~ 5 лет), могут поддерживать большой объем памяти и т.д. Но опять же у вас есть PICS, которые работают с несколькими килобайтами. Более скудные ресурсы, программист должен использовать гениальные хаки, чтобы максимально использовать возможности устройства. И основное внимание уделяется "заставить его работать", а не "писать элегантный код".

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

Я также хотел бы увидеть лучшие инструменты для DSP (TI: пожалуйста, передайте CCS кому-то полезному для создания IDE), и больше разработчиков библиотек, использующих С++ (я смотрю на вас, ATEME), для создания лучших библиотек.

А также инженеры-аппаратчики лучше оценивают ориентацию объектов, а не выскакивают, "если это С++ будет медленным".

Ответ 7

Позвольте мне сначала рассмотреть предположение в вашем вопросе. Предполагается, что разработчики программного обеспечения (ESE) не знают или не знают о современных методах разработки программного обеспечения и нуждаются в изучении новых практик. Это предположение должно быть немедленно выброшено. Я считаю, что вы найдете такое же статистическое распределение ESE, которые сохраняют свои навыки и методы современными, не внедренными SE.

Итак, может быть, ваш вопрос станет массивом вопросов вроде:

• Почему ESE используют отдельный редактор кода и компилятор командной строки, а не IDE?
• Почему C предпочтительнее С++ в большинстве встроенных проектов?
• Почему в практике программирования во встроенном мире не так много экспериментов?

Следующие пункты отвечают на эти вопросы.

• ESE обычно используют специальный редактор кода, потому что это личное предпочтение, или это то, что используется его/ее компанией. IDE не так распространены, потому что ESE работают очень близко к кремнию, и не все производители чипов разрабатывают IDE для своей линейки чипов. Только чипы, которые достигают наивысшего уровня проникновения на рынок, такие как ARM, имеют достаточный импульс, чтобы гарантировать разработку инструментов на основе IDE. Кроме того, IDE не обеспечивает столько поддержки ESE, как это делает, например, разработчик настольных систем. IDE предоставляют помощь в создании клей для GUI или завершения кода для больших API-интерфейсов; ни один из которых обычно не найден или не является стандартным, как во встроенном мире.

• Я уверен, что есть лучшие рецензии о том, почему C является предпочтительным по сравнению с С++ во встроенных системах, чем я могу составить на месте. Короче говоря, вы используете то, что работает. C работает и является более распространенным (больше программистов знают C, чем С++). Другая причина может заключаться в том, что методология OO была разработана, чтобы помочь программистам решать большие проблемы, абстрагируя решение в управляемые концептуальные объекты. Во встроенном мире проблемы обычно уменьшаются до такой небольшой проблемы (и решения), насколько это возможно, так что встроенная система становится более надежной, имея меньшую базу кода.

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

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

Ответ 8

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

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

Отслеживание ошибок
Вы собираетесь рано или поздно забыть. Журнал ошибок должен содержать версию (см. "Управление версиями" ), в которой проблема была впервые обнаружена, и версия, в которой она была исправлена.

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

Ответ 9

Это, вероятно, немного вне контекста.
Краткая ссылка на столбец прошивки на Встроенный,

• Стандарты кодирования ошибок для прошивки
• Некоторые страницы переходят в статью, Десять правил убийства ошибок

Я всегда находил хорошие статьи о разработке прошивки в Embedded.
Который, вероятно, многие заинтересованы в этом вопросе, тоже...