Что микропрограммные инженеры могут изучить от разработчиков программного обеспечения? [закрытый]

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

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

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

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

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

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

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

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

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

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

Тест Джоэла

1. Используете ли вы систему контроля версий?
2. Можете ли вы сделать сборку за один шаг?
3. Вы делаете ежедневные сборки?
4. Есть ли у вас база данных об ошибках?
5. Исправляете ли вы ошибки перед написанием нового кода?
6. У вас есть актуальное расписание?
7. У вас есть спецификация?
8. У программистов тихие условия работы?
9. Используете ли вы лучшие инструменты, которые можно купить за деньги?
10. Есть ли у вас тестировщики?
11. Пишут ли новые кандидаты код во время собеседования?
12. Вы проводите тестирование юзабилити в коридоре?

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

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

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

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

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

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

There are several data structures that allow you to grow dynamically. As the 2 previous replies suggest, you can use an array of pointers, a linked-list etc.

Все зависит от требований вашей реализации:

1. Будете ли вы обращаться к этим строкам более одного раза?
2. Как только вы их получите, собираетесь ли вы обращаться к ним всем (для некоторых вычислений) или по одной за раз время (например, словарь)?
3. Что вы думаете о пространстве / памяти?
4. Есть ли какое-то значение для порядка, в котором вы их получаете (предлагает очередь или реализацию стека)?
5. Есть ли неотъемлемая часть связь между строками (предполагая древовидную или древовидную структуру)?

и т. д. Предлагаю прочитать немного о структурах данных и решить, что вам больше подходит. Все они могут быть реализованы на C.
См. эту статью в Википедии (перейдите в раздел «Примеры» для получения списка опций, если вы хотите пропустить теорию)

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

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

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

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

Кстати, для получения дополнительной информации о неиспользовании C ++ во встроенных системах см. этот вопрос .

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

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

• Блог о переполнении стека и подкаст
• The Daily WTF
• Говорят о качестве
• Ужас программирования
• Секретный компьютерщик
• Джоэл о программном обеспечении
• Другой Блог о переполнении стека ; этот посвящен встроенным системам.

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

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

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

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

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

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

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

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

Let me first address an assumption in your question. The assumption is that embedded software engineers (ESE) do not know or are not aware of modern software engineering practices and need to learn new practices. This assumption should be tossed out right away. I believe you would find the same statistical distribution of ESEs who keep their skills and techniques up-to-date as non-embedded SEs.

So, maybe your question becomes an array of questions like:

1. Why do ESEs use a separate code editor and a command line compiler and not an IDE?
2. Why is C preferred over C++ in the majority of embedded projects?
3. Why isn't there as much experimentation in programming practices in the embedded world?

The following paragraphs answer these questions.

1. ESEs usually use a specific code editor because it is a personal preference or it is what is used by his/her company. IDEs are not as common because ESEs work very closely to the silicon and not all chip manufacturers develop an IDE for their line of chips. Only the chips that achieve highest market penetration, such as ARM, have enough momentum to warrant the development of IDE-based tools. Furthermore, an IDE doesn't provide as much of an assistance to the ESE as it does to, say, a desktop developer. IDEs provide help with making the glue to the GUI or code-completion for large APIs; neither of which is commonly found or as standard as in the embedded world.

2. I'm sure there are better write-ups as to why C is preferred over C++ in embedded systems than I can make up on the spot. The short of it is that you use what works. C works and is more common (more programmers know C than C++). The other reason might be that the OO methodology was devised to help programmers solve large problems by abstracting the solution into manageable conceptual objects. In the embedded world, the problems are usually whittled down to as small a problem (and solution) as possible so that the embedded system becomes more reliable by having a smaller code base.

3. There is less experimentation by ESEs because an embedded product, in general, must be far less prone to error and have higher reliability than a desktop program. This means a rigid application of well-proven practices and more time spent in testing. Why? Because often there is no feasible path to upgrade the firmware of an embedded device; it's either impossible due to the system being deployed beyond reach or implausible because of the cost of updating millions of devices.

In conclusion, ESEs use tools and practices that best suit their needs just as non-embedded SEs do. As a practicing ESE, I believe the embedded software discipline is far more different than my non-ESE friends believe it is. So the apparent disparity of programming practices is not a matter of ESEs needing to learn modern practices, but non-ESEs needing to understand how different embedded programming is.

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

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

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

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