Параметры для выбора Операционной системы, памяти и процессора для встроенной системы?
Я разрабатываю встроенное программное обеспечение системы реального времени (на языке C). Я разработал s/w архитектуру - мы знаем различные требуемые объекты, взаимодействия, требуемые между различными объектами и коммуникацией IPC между задачами. На основе этой информации я должен выбрать операционную систему (RTOS), микропроцессор и требования емкости памяти.
(Скорее всего, я использовал бы Quadros, как он был предположен клиентом на основе их предшествующего опыта в подобных проектах),
Но я смущен, о котором для начала, начиная с выбора можно было повлиять на выбор другого.
Вы могли также вести меня на параметрах для рассмотрения для оценки требований к памяти от дизайна s/w (нижний предел и верхний предел требования к памяти)?
(Стоимость компонента (компонентов) могла быть проигнорирована для этой оценки),
2 ответа
Память является более дешевой, чем Ваше время, по крайней мере, для первых нескольких созданных систем. Наполните максимум всего, что Вы можете на управление по Вашей опытной системе и оснащать heck из Вашего кода. Можно купить менее хорошо смонтированные платы для производства, но теперь Вы хотите мега ресурсы.
- Выделите намного большие стеки, чем Вы думаете, что будете когда-либо нуждаться и предварительно заполнять их набором повторяющегося текста, такого как название потока, который владеет тем стеком. То, сколько из этого перезаписывается, покажет Вам, сколько стека каждый поток использовал. Примените удобный коэффициент безопасности к тому числу для получения заключительного выделения.
- Выделите много "кучи". Еще лучше, вместо того, чтобы использовать "кучу" во время выполнения, предварительно выделите "кучу" при запуске к одному (или несколько) пулы памяти (или несколько) зафиксированные размеры блока. Выделите и освободите только от тех, которые во время выполнения.
- Память журнала использует в большое (или проспект) буфер или журнал идентификатор запрашивающей стороны в преамбулу, отличную от фактического пространства данных блока - что-либо, что оставит следы, которые можно найти позже, чтобы помочь проанализировать спрос на память, исчерпание ресурсов памяти или катастрофические отказы.
- Не допустите буферы в свои стеки, таким образом, переполнения не принесут все к визжащему останову, или хуже, подвергнутся диким передачам управления.
- Удар в системе. Проведите его через любые сценарии, Вы думаете, подчеркнут стек и требования к памяти. Зарегистрируйте некоторых типичных и нетипичных пользователей, чтобы сделать то же. Некоторые из них попробуют, делают вещи, которые Вы не ожидали. Поощрите это.
Когда Вы сделали все, что у Вас будет намного лучший дескриптор на Ваших требованиях к памяти, чем можно добраться теперь.
(Редактирование; комментарий не доступный мне)
James:
'мы хотели бы получить грубую оценку аппаратных средств и стоить включенный на данном этапе. Вы думаете, что это было бы возможно?'
Короткий ответ да, RAM, вероятно, будет небольшой частью Ваших затрат на оборудование, таким образом идти вперед и переоценивать - необходимо все еще быть близкими.
Как грубая проверка, Вы могли бы получить примерную оценку для требований статического ЗУ - кода и статических данных - путем записи и компиляции нескольких функций для получения грубых исходных строк к отношению памяти и экстраполирования. Вам будут нужны грубое количество и некоторые образованные приблизительные оценки о том, как Ваш дизайн расширится в функции и строки кода. Можно ли высказать образованные предположения об использовании дизайна во время выполнения динамических структур - стеки и "куча" или пулы? Я, вероятно, по крайней мере, удвоил бы или увеличил бы свои оценки в четыре раза.
Можно ли реализовать систему на существующем компьютере, закоротив функции (путем компиляции кода с коротким возвратом, а не #ifdef'ing это), которые не имеют смысла в той среде?
Если действительно необходимо оценить, не реализовывая очень, я думаю, что Вы идете в застрявший в экстраполировании.
Это кажется, что Вы уже сделали некоторые проектные решения.
мы знаем различные требуемые объекты, взаимодействия, требуемые между различными объектами и коммуникацией IPC между задачами.
Вам нужны многопоточная ОС и uC, который выполнит ее, обычно означая, что Вы хотите стремиться к процессору с MMU. Опции ОС являются вещами как Quadros, QNX, Linux, содрогание, и т.д.
На основе какой делают Ваши "объекты" (модули лучший термин для C :)), можно, вероятно, определить, в какой архитектуре Вы нуждаетесь. Дуга на 16 битов достаточно? нуждаетесь в большей памяти или работаете с большим числом, затем 32 бита правильный ответ? большая работа с плавающей точкой? затем Вам, вероятно, нужен процессор с FPU. Выполнение большого количества DSP как работа? возможно, Вам нужны DSP или uC с DSP как инструкции или co-proc. Выполнение графического дисплея? нуждаюсь в SoC с созданным в жидкокристаллическом контроллере или ожидаю делать это внешне. Выполнение тяжелой 2D графики? нужен SoC с некоторым графическим ускорением.
Составьте список функций, в которых Вы нуждаетесь и оцениваете, сколько из Вашего кода попадает в категории как целочисленные операции, цикличное выполнение, операция в секунду с плавающей точкой, графические операции, операции DSP, и т.д.
Это должно позволить Вам классифицировать уровень устройства, в котором Вы нуждаетесь. Для некоторой архитектуры Вы могли пересечь компиляцию некоторый код с помощью GCC и эмулировать его с помощью qemu сверху Linux. Это, вероятно, только стоит того, если необходимо проверить производительность критического алгоритма на конкретной архитектуре. Это может помочь Вам масштабировать скорость, в которой Вы нуждаетесь для своего приложения.
Второе соображение должно быть энергопотреблением и поддержкой управления питанием. Объединенный с необходимой производительностью можно сделать выбор DSP, uC, прикладного процессора, и т.д.
Поскольку другие сказали, что я не волновался бы об использовании памяти, просто нацелиться большой, часто различные размеры поршня совместимы по выводам, таким образом, можно просто сократить поршень для производства. Единственные реальные вопросы ответить впереди вот:
*Как большой из адресного пространства мне нужно? 16 битов? 32 бита? и т.д.
*Мне нужен внешний поршень, или uC внутренний поршень будет достаточно? <-отвечают на это после того, как Вы выберете архитектуру и сможете пойти поиск SoC.
По большей части выбор среди процессоров в том же классе является "священной войной" иначе в 32 битах risc рынок, некоторые поддержат ARM, некоторые поддержат coldfire, некоторые могут даже поддержать PIC32. В конце дня, вероятно, любой работал бы. Необходимо выбрать на основе доступного SoCs с необходимыми периферийными устройствами, простотой разработки (насколько хороший набор инструментальных средств), и стоимость.
То же может быть верным для выбора ОС, Linux по сравнению с QNX по сравнению с quadros является броском для большинства приложений, обычно лучший ответ является тем, с которым у Вас есть большая часть опыта. Даже если это заканчивает тем, что было немного более дорогим, сокращение во время разработки часто смещает стоимость сборки. Действительно удостоверьтесь, что ОС имеет необходимые функции, совместно использованные библиотеки, межпроцессное взаимодействие, каналы, независимо от того, что Вам нужно.
Как правило я выбрал бы Вашу архитектуру сначала. Это окажет намного более высокое влияние на производительность Вашего устройства, чем операционная система будет. Кроме того, операционные системы в этом пространстве часто поддерживаются на многой архитектуре. Также лучшей ОС является POSIX, совместимый, записанный правильно, объем Вашего кода должен смочь работать на нескольких ОС.
Не плохо себя чувствуйте, если необходимо предпринять несколько попыток сделать верный выбор. Можно найти ядро, которое отлично соответствует потребностям кода, но найдите после некоторого исследования, что оно не поддерживает некоторую незначительную функцию, в которой Вы нуждаетесь, или нет доступного SoC с периферийными устройствами, в которых Вы нуждаетесь, или даже что вещь назад заказана в течение 6 месяцев. Просто удостоверьтесь после совершения начального выбора, который Вы исследуете, как дизайн объединится на основе той части так, чтобы Вы видели камень преткновения теперь, а не половину пути посредством разработки.