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

8

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

Мой вопрос заключается в том, как я могу написать программное обеспечение и протестировать его без аппаратного обеспечения?

Есть ли какие-то стандарты, которым нужно следовать? Как ты делаешь это?

anishkumar
источник
В зависимости от сложности оборудования, вы можете попробовать симулятор. Это вполне выполнимо, если это всего лишь микроконтроллер с простой периферией. Более того, и вам не повезло на этом маршруте.
Мачта
6
Попробуйте найти платы разработки для микро- и любых других периферийных устройств, которые вы используете, и постарайтесь соединить их все так, чтобы это наиболее близко соответствовало дизайну вашей команды аппаратного обеспечения. Это будет большой и уродливый, но вы должны быть в состоянии собрать систему, которая достаточно близка к реальной - по крайней мере, насколько ваша прошивка может сказать ...
brhans
В худшем случае, если вы не можете правильно смоделировать аппаратное обеспечение, есть способ его отключить. Всего пару недель назад я хотел проверить сетевое взаимодействие с другой программой, но обнаружил, что так и будет, exit()потому что он попытался отобразить жестко закодированные адреса в / dev / mem.
Исана
1
На самом деле во многих случаях предпочтительнее использовать симулятор для разработки встроенного программного обеспечения - его гораздо легче отлаживать. Проблема, конечно, в том, что вам нужен приличный симулятор. Иногда есть универсальный, который можно адаптировать, иногда умный стажер может написать один в безумие кодирования на кофеине.
Hot Licks

Ответы:

34

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

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

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

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

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

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

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

Олин Латроп
источник
Хотелось бы добавить: получите доски разработчиков (да, несколько, потому что вы, вероятно, убьете хотя бы одну ...) как можно скорее и получите драйверы низкого уровня на месте. Модульный тест как можно большей части вашего кода. Да, вы можете объединить аппаратно-касательный код. Нет, вы не можете полностью смоделировать аппаратное обеспечение, но вы можете получить правильную 90% функциональности даже до того, как начнете мигать в первый раз. Я сделал все вышеперечисленное в недавнем проекте, и у нас была функциональность на 99%, и мы работали, когда пришло настоящее оборудование. Это было великолепно.
Чендрикс
13

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

Techydude
источник
1
Согласовано. Я бы сказал это сильнее. В такой ситуации, когда программное обеспечение должно быть завершено одновременно с аппаратным обеспечением, я бы использовал только микроконтроллер с подходящей платой разработки или оценки.
Стив Г
Даже если у вас есть понимание того, что разрабатывает OP, у большинства семейств микроконтроллеров все еще есть симуляторы.
Олин Латроп
Я использую оба метода. Тем не менее, я также слежу за производственным оборудованием, необходимым для испытаний. Вы можете встретиться с производственными инженерами и проектировать оборудование, чтобы протестировать ваши драйверы, которые затем могут стать частью производственного тестирования. Если вам повезет, они могут даже собрать оборудование для платы разработки / прототипа, чтобы они тоже опередили процесс. Все зависит от того, как вы подадите запрос о помощи ...
Ложка
Это лучший ответ на этот вопрос, так как у меня всегда есть доска разработчика для программирования основных функций, прежде чем я попробую ее на печатной плате.
lucas92
2

В зависимости от того, насколько аппаратно-зависимым будет приложение, вы можете просто начать реализацию проекта на стандартном ПК (Windows, Linux ...). В любом случае большая часть периферийного доступа должна быть абстрагирована, поэтому нет ничего страшного в том, чтобы реализовать некоторые фиктивные функции, которые будут заменены позже. Если невозможно смоделировать какое-либо поведение, вы можете, по крайней мере, выполнить макет системы (API ...), поэтому фактическая реализация станет намного быстрее и понятнее, как только оборудование будет готово.

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

Конечно, все это сильно зависит от различных факторов:

  • Можете ли вы использовать один и тот же / похожий набор инструментов на контроллере и ПК (например, gcc)?
  • Насколько аппаратно зависит система?
  • Насколько вы опытны в программировании на ПК?

Я, например, сначала проектирую почти каждый модуль прошивки на ПК.

Erebos
источник
Тоже самое. Некоторые различия между компиляторами (встроенные функции, специальные ключевые слова, ОС с закрытым исходным кодом и сетевой стек, не совсем совместимый с BSD) и ошибками (с C ++) вынуждают интенсивно использовать предварительно включенные файлы и препроцессор для конкретных файлов, но сам код может быть практически идентичен между DSP и ПК. Для ПК-версии я могу использовать строгую и серьезную проверку ошибок во время выполнения (CodeGuard), и его возможности отладки не могут быть сопоставлены на встроенных платформах. Дополнительным бонусом является то, что у меня может быть несколько дополнительных виртуальных устройств для любой сети и нагрузочного тестирования.
TMSZ
Благодаря наличию Raspberry Pi и BeagleBone ваша среда разработки также может быть вашей средой выполнения - никаких проблем с набором инструментов и т. Д. Кроме того, вы можете использовать valgrind / helgrind, gdb и т. Д.
jhfrontz
1

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

Если вы не можете получить симулятор, абстрагируйтесь как можно больше через HAL (уровень аппаратной абстракции). Все водители получают за это. Попробуйте абстрагировать всю платформу-сборку за вызовом некоторой функции C и думать о них как о драйверах Напишите остальное как переносимый код C / C ++, создайте тонкий HAL для x86 и запустите его на своем компьютере со всеми тестовыми примерами.

Таким образом, когда вы получаете оборудование, вам нужно будет только отладить HAL. Чем он тоньше, тем быстрее вы его отладите и все заработает. Помните, что если вы используете сборку для конкретной платформы для ускорения операций, вы ОЧЕНЬ ХОТИТЕ ОЧЕНЬ ХОРОШО, чтобы получить точные битовые тесты .

Ронан Пайшао
источник
Битовая точность особенно важна, если используется DSP с фиксированной точкой.
Ронан Пайшао
Это может или не может применяться к конкретному случаю, но в целом точность битов имеет свою цену. Недавно QEMU (2 года назад) решила внедрить точный битовый FPU, и угадайте, что случилось с производительностью ?
Дмитрий Григорьев
Точность битов не так важна при использовании FPU. Это очень важно, если используется фиксированная точка. Тем более, что программная фиксированная точка везде нуждается в дополнительных проверках.
Ронан Пайшау,
Что является результатом плохой практики кодирования. Люди научились принимать меры предосторожности при использовании a == bсравнений с числами с плавающей запятой, но они все еще бездумно используют их с числами с фиксированной запятой.
Дмитрий Григорьев
Хотя плохая практика кодирования является довольно большой проблемой, есть много других проблем, особенно в крайних случаях. Переполнения быстро приходят на ум, как и потеря точности , округление , насыщенность и ширина по сравнению со сдвигом битов . При этом легко игнорировать некоторые потери точности в обычных тестовых случаях. Проблема заключается в том, что когда ваше приложение достигает меньшего числа случаев, а ошибки переходят от дробных к целочисленным битам, что происходит, если диапазон неверно рассчитан. Просто зайдите на страницу возможностей MATLAB Designer с фиксированной точкой, чтобы увидеть, что еще может пойти не так.
Ронан Пайшао
1

Ваш вопрос немного широк. Аппаратное обеспечение (HW) может означать полноценную разработку ASIC / FPGA, DSP, запрограммированные на ассемблере, или «только» типичную встроенную систему, основанную на готовых микропроцессорах / микроконтроллерах / SoC и т. Д. (Конечно, SoC также может содержать DSP). что вы можете захотеть запрограммировать ....). В больших количествах продажа ASIC не редкость.

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

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

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

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

Во всех случаях общение является ключевым.

bluesceada
источник
0

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

Как ?

Сначала вы должны знать основную цель этой системы. Таким образом, из этого вы можете выбрать соответствующий контроллер из обширного источника, такого как digikey, mouser.

И выбрать симулятор, как Proteus. Это будет имитировать точный процессор / контроллер, теперь вы можете начать кодирование. Но вы не можете ожидать точности, как в аппаратном обеспечении.

Photon001
источник
Почему понизить? Могу ли я узнать, что не так с этим ответом?
Photon001