Как вы определяете, сколько флэш / оперативной памяти вам нужно для микроконтроллера?

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

Используете ли вы доску разработчика и сначала кодируете свой проект, а затем смотрите, сколько памяти вы использовали, а затем выбираете подходящий микроконтроллер, который соответствует этой памяти?

Вы просто выбираете мощный протокольный микроконтроллер для прототипа, а затем уменьшаете масштаб, когда у вас есть работающий продукт?

Вы просто выбираете что-то, что, как вы уверены, будет достаточно, и если у вас не хватит места, просто перейдите на более плотную память, в противном случае вы просто сохраните существующий микроконтроллер?

Что считается хорошей практикой?

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

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

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

Однако для производственных целей это позволит вам сбрасывать достаточное количество с каждой единицы.

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

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

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

Это «как» также включает в себя размышления о разработке программного обеспечения, ответы на такие вопросы, как:

• Вам нужна операционная система? Который из? Какие ресурсы ему нужны?
• Хотите иметь многоуровневую архитектуру? Это требует интерфейсов, которые могут потреблять оперативную память
• Какие библиотеки уже доступны и полезны / необходимы для вашей цели, и сколько памяти им нужно (хорошая документация библиотеки отвечает этому на основании хотя бы одной эталонной сборки)?
• Какие структуры и переменные вы должны реализовать для своих собственных драйверов и вашего приложения?

Суммирование всех этих значений дает вам приблизительную оценку. Насколько вы можете доверять, зависит от того, насколько подробен ваш анализ, и зависит от вашего опыта :-)
Добавление маржи в размере не менее 30 ... 50% от вашей оценки, безусловно, хорошая идея.

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

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

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

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

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

Как правило, производители микроконтроллеров помещают в свои устройства диапазон памяти, подходящий для типичных приложений. Таким образом, если вам нужно всего лишь несколько выводов ввода-вывода и один SPI на небольшом устройстве, вы вряд ли найдете что-либо, что поставляется с 500 кБайт Flash и 64 кБайт RAM. С более крупными устройствами, которые ближе к пакетам SoC, даже самые маленькие почти наверняка достаточно велики, если только вы не планируете делать какие-то серьезные вычисления, такие как обработка изображений.

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

Многие компании приняли подход Agile как к программному, так и к электронному проектированию, который включает в себя создание «библиотеки» небольших функциональных плат (например, плат RS-485, плат АЦП и т. Д.) Вместе с платами общей платформы, на которых размещены микроконтроллеры. , аналогично использованию dev-kit и плагинов. Затем можно быстро (в течение нескольких часов) создать прототип продукта, выбрав и подключив набор плат, необходимых для функций. Программное обеспечение аналогичным образом собирается из библиотечных модулей и может быть быстро перенесено и протестировано. Как только размер аппаратной части кода известен, обычно достаточно выбрать наименьшую часть, которая будет содержать это. Исключение составляет упомянутое выше, где функциональность устройства включает большие данные или очень сложные алгоритмы. Этот метод обеспечивает точный,

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