Параметры для выбора операционной системы, памяти и процессора для встроенной системы?

Question

Я занимаюсь разработкой встроенного программного обеспечения системы реального времени (на языке Си). Я разработал архитектуру программного обеспечения - мы знаем, какие требуются различные объекты, какие взаимодействия требуются между различными объектами, а также взаимодействие IPC между задачами. Основываясь на этой информации, мне нужно определиться с требованиями к операционной системе (RTOS), микропроцессору и объему памяти.

(Скорее всего, я бы использовал Quadros, как это было предложено клиентом на основании его предыдущего опыта в подобных проектах)

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

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

(Стоимость компонента (ов) может быть проигнорирована для этой оценки)

Answer 1

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

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

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

---

(Изменить; комментирование недоступно для меня)

Джеймс:

«Мы хотели бы получить приблизительную оценку оборудования и затрат, связанных с этим на данном этапе. Как вы думаете, это будет возможно?'

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

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

Можете ли вы внедрить систему на существующем компьютере, используя функции короткого замыкания (путем компиляции кода с коротким возвратом, а не # ifdef'ом), которые не имеют смысла в этой среде?

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

Answer 2

Похоже, вы уже сделали несколько вариантов дизайна.

мы знаем, что требуются различные объекты, взаимодействие между различными объектами и взаимодействие IPC между задачами.

вам нужна многопоточная ОС и UC, который будет ее запускать, обычно это означает, что вы хотите нацелиться на процессор с MMU. Опции ОС - это Quadros, QNX, Linux, Wince и т.д.

Исходя из того, что делают ваши "объекты" (модули лучше подходят для C :)), вы можете определить, какой тип архитектуры вам нужен. Достаточно ли 16-битной арки? нужно больше памяти или работать с большими числами, тогда 32-битный правильный ответ? много работы с плавающей точкой? тогда вам, вероятно, понадобится процессор с FPU. Делать много DSP, как работа? может быть, вам нужен DSP или ОК с DSP-подобными инструкциями или совместным процессом. Запуск графического дисплея? Нужна SoC со встроенным контроллером LCD или ожидайте, что это будет сделано снаружи. Делаете тяжелую 2D графику? нужна SoC с некоторым графическим ускорением.

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

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

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

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

* Какого размера адресного пространства мне нужно? 16bit? 32bit? так далее

* Нужен ли мне внешний ОЗУ или будет достаточно внутреннего ОЗУ? <- ответьте после того, как вы выберете архитектуру и сможете заняться охотой на SoC

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

То же самое может быть справедливо в отношении выбора ОС: linux vs QNX vs quadros - это проблема для большинства приложений, обычно лучшим ответом является тот, с которым у вас больше всего опыта. Даже если это окажется немного дороже, сокращение времени разработки часто компенсирует стоимость сборки. Убедитесь, что у ОС есть необходимые функции, общие библиотеки, межпроцессное взаимодействие, каналы, все, что вам нужно.

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

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