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


24

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

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

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

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

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


Мне кажется, что с информационной точки зрения должна быть возможность оценить требования к ОЗУ с точностью до порядка (стиль размерного мышления), исходя из спецификации задачи. Хммм ...
Линдон Уайт

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

Ответы:


20

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

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

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

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


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

В «реальной» среде определенно будут лучшие способы, давайте подождем других ответов!
Дэвид

Absatively. Развейтесь в большой песочнице и вырубите позже. Время, которое вы сэкономите, превысит 4 доллара, которые вы потратите на разработку микроконтроллера. Это работает не только на уровне хобби, а на самом деле даже важнее. Фото 12 человек, ожидающих перехода к большему контроллеру вместо одного !!
Скотт Сейдман

13

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

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

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

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

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

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

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


2
Re: «80..90% ОЗУ используется». Стандартная практика заключается в том, чтобы использовать максимум 50% загрузки как процессора, так и памяти, чтобы иметь возможность приспосабливаться к будущим обновлениям и исправлениям ошибок.
Данк

1
@ Dunk: зависит от бизнеса. В автомобильной промышленности 80% всех ресурсов (CPU, RAM, Flash) в SOP общеприняты. Например, в дешевой бытовой электронике это может быть даже больше: какова вероятность обновления системы со сроком службы всего 2-3 года?
микрофон

@Dunk: Я могу ошибаться, но похоже, что вы привыкли к программному обеспечению в стиле рабочего стола с динамической памятью и всеми неопределенностями, которые сопровождают это. Подавляющее большинство встроенных приложений распределяют все статически. Гарантируется отсутствие утечек памяти. Тогда вы можете использовать ровно 100% и всегда быть в порядке, пока вы не измените его. Конечно, это работает только в том случае, если у вас есть отдельный стек из рабочей ОЗУ или если вы точно знаете, как этот стек будет себя вести постоянно. Это хорошая идея, чтобы оставить для этого место, но 10-20% достаточно для того, что я сделал.
AaronD

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

3
Хотите ли вы стремиться к цели 80% или цели 50%, будет зависеть от вашего клиента. С фиксированной спецификацией и необходимыми исправлениями ошибок, 80% - это хорошо. Ненадежная спецификация, ожидаемая ползучесть функций и достаточно большой запас, чтобы позволить вам платить больше за запас. Однажды мы купили в 2 раза больше микроконтроллеров, чем нам было нужно, и выбрали те, которые разгонятся настолько, чтобы дать нам необходимую производительность, что было намного дешевле, чем перепроектирование печатной платы для более мощного чипа.
Марк Бут

3

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

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

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

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


Где можно найти формулу для преобразования строк кода в память кода?
EasyOhm

Это зависит от того, какой язык и компилятор вы используете. Если вы используете Ассемблер, одна строка примерно равна одному слову памяти (независимо от размера слова вашего чипа). Если вы используете C, это может быть около 3-5 слов в строке, а если вы используете C ++ или что-то еще более сложное, это может быть намного больше. Лучше всего скомпилировать несколько программ, написанных на этом языке, и сравнить строки кода с памятью кода, чтобы получить среднее значение.
Даккарон

2

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.