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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как ?

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

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