Один большой микроконтроллер или множество маленьких микроконтроллеров?

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

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

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

Я думаю, мой вопрос действительно двойственный:

1. Является ли подход «все в одном» хорошей идеей, когда требуется многозадачность, или лучше сегментировать и изолировать, и

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

Я смотрю на умеренные dsPIC33 вплоть до ARM SoC, на которых работает RTOS. Систематический способ отточить то, что мне нужно, очень помог бы мне.

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

Небольшие количества

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

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

Так что в этом случае ответ на ваши вопросы:

Является ли подход «все в одном» хорошей идеей, когда требуется многозадачность, или лучше сегментировать и изолировать, и

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

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

В этом случае разница в стоимости между 32-разрядным процессором с большим количеством ресурсов и 8-разрядным процессором с ограниченными ресурсами невелика по сравнению с количеством времени, которое вы собираетесь потратить на разработку. Нет никаких оснований пытаться выяснить, сколько энергии вам нужно - просто получите самый большой процессор, для которого, как вы считаете, вы можете его разработать, и используйте его. Если в какой-то момент вам понадобится оптимизировать стоимость проекта, сравнительно легко измерить фактическое использование ресурсов процессора, тогда выберите процессор-арендодатель, который сможет справиться с фактической нагрузкой. До тех пор используйте самый большой и не беспокойтесь о поиске «наилучшего соответствия».

Массовое производство

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

Является ли подход «все в одном» хорошей идеей, когда приходится выполнять многозадачность, или лучше сегментировать и изолировать?

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

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

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

Ваши подпрограммы BLDC PI будут потреблять X циклов процессорного времени 100 раз в секунду, и для каждой из них потребуется около 50 байтов оперативной памяти, 16 байтов EEPROM для настройки и 1 Кбайт для кода. Каждому из них понадобится 3 шестнадцатеричных PWM периферийных устройства в микроконтроллере. Вам может потребоваться указать джиттер, который будет иметь особые требования к задержке прерывания.

Ваши USB и последовательные подпрограммы будут потреблять Y циклов процессорного времени по мере необходимости, 2 КБ ОЗУ, 64 байт EEPROM и 8 КБ флэш-памяти. Это потребует USB и последовательных периферийных устройств.

Ваш графический интерфейс будет потреблять Z циклов мощности процессора 30 раз в секунду, и ему потребуется 2 КБ ОЗУ, 128 байт ЭСППЗУ и 10 КБ флэш-памяти. Он будет использовать 19 входов / выходов для связи с ЖК-дисплеем, кнопками, регуляторами и т. Д.

Когда вы только начинаете, может быть трудно понять, что такое X, Y, Z, и это немного изменится в зависимости от архитектуры процессора. Тем не менее, вы должны иметь возможность понять, в рамках приблизительной оценки, сколько оперативной памяти, EEPROM и флэш-памяти понадобится вашему дизайну, и какие периферийные устройства вам нужны. Вы можете выбрать семейство процессоров, которое соответствует вашим требованиям к памяти и периферийным устройствам и имеет широкий диапазон параметров производительности в этом семействе. На этом этапе для разработки вы можете просто использовать самый мощный процессор в семействе. После того, как вы реализовали свой дизайн, вы можете легко перевести семью с точки зрения энергопотребления к более дешевому варианту без изменения вашего дизайна или среды разработки.

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

Я бы выделил управление двигателем и имел бы отдельный микроконтроллер, который включает в себя ШИМ (возможно, PIC18) для каждого из двух двигателей BLDC, поскольку управление ПИ является изолированной задачей после запуска и после написания кода, который вы используете. можно использовать на обоих микро. Вы можете подключить их обратно к основному микроконтроллеру через интерфейс, такой как I²C, и загрузить параметры для управления PI оттуда, если хотите. Это позволит вам изменить их в вашем графическом интерфейсе.

Затем я запустил бы все остальное в главном микроконтроллере, таком как PIC24 (PIC32, вероятно, излишне, в зависимости от задач, которые вы перечислили). Кроме того, самые быстрые PIC24E могут работать почти так же быстро, как PIC32.

Выбирая микроконтроллер, я сначала оцениваю объем флэш-памяти и ОЗУ, которые мне нужны, а затем смотрю на длину слова и скорость процессора. Для более поздних, часто самым сложным требованием является самое быстрое прерывание, которое вы ожидаете обработать. Например, если вы выводите звук с частотой 16 кГц и прерываете его каждые 62,5 мкс, то вам лучше иметь микроконтроллер с временем выполнения команд в десятки наносекунд, иначе вы не сможете его обслуживать и получать другие работа сделана.

Существует полуформальный подход, который вы можете использовать, чтобы помочь вам выработать свой ответ. Я настоятельно рекомендую прочитать главу 2 «Проектирования встраиваемых систем» Уайта, большинство из которых доступно в Google Книгах .

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

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

Что касается того, «как я узнаю, достаточно ли у меня контроллера», я предпочитаю как можно больше вкладывать в свою песочницу проектирования, а затем вычислять, сколько ресурсов я могу сократить, как только проект станет лучше. путь. Разница в цене между микроконтроллером за 10 долларов США и микроконтроллером за 3 доллара США в целях создания прототипов может быть всего лишь неделями переоснащения и переворота в ожидании новых деталей, в то время как дизайн всегда будет двигаться, если у вас достаточно энергии.

Я работаю над системой, которая в целом соответствует тому, что вы описываете: двигатели, IO, дисплей, 3x UART + SPI + I2C, работающие на Coldfire 52259 (средний диапазон 32-бит, ~ 80 МГц micro), и это не слишком сложно, хотя и получается правильная архитектура программного обеспечения важна - у нас есть много вещей, работающих на оборудовании и прерываниях (все, что аппаратное обеспечение может обрабатывать самостоятельно, мы выполняем в оборудовании и обслуживании с прерываниями), оставляя цикл main () для выполнения всей служебной работы.

Лично мне не нравится большинство RTOS, которые я видел, на низком уровне они раздувают проект, добавляют еще одну вещь для изучения, и вы получите лучшую производительность от оборудования, выполняя действия напрямую (используя доступные аппаратные функции + прерывания) вместо того, чтобы притворяться с программным обеспечением.

В конце концов, в наши дни, кажется, так мало разницы между MCU, который является сложным и достаточно мощным, чтобы по- настоящему извлечь выгоду из RTOS и чего-то (SoC), которое просто запускает встроенный Linux.

Тем не менее, в этом случае я бы сказал, что есть некоторая ценность в использовании небольших дешевых микросхем для обработки критических функций (например, управление двигателем, когда время или остановка на пределе имеют решающее значение) под командой основного «мозгового» процессора, так что вы не полагаетесь на «не в реальном времени» ОС, чтобы сделать что-то своевременно.

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

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

$\frac{1}{((1-p)+\frac{p}{s})}$

Конечно, стоимость, простота внедрения; и т. д. важно и даже более важно учитывать.

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

«Лошадиная сила» является вторичной по отношению к тому, можете ли вы выполнить свои ограничения в реальном времени.

Если у вас есть два выхода PWM, и оба должны переключаться в одно и то же время, то для этого нужно иметь необходимый параллелизм. Если у вас есть выделенный ШИМ-контроллер, который заботится о точной синхронизации, он будет работать даже с довольно небольшим микроконтроллером, в то время как решение на основе GPIO будет чрезвычайно сложным, даже если имеется много вычислительной мощности.

Для большинства протоколов современные MCU имеют встроенные реализации тех частей протокола, которые имеют ограничения в реальном времени, поэтому, если вы можете найти MCU, который имеет необходимые периферийные устройства и имеет требуемую скорость ЦП для обработки потоков данных (то есть жесткие требования в реальном времени вырождаются в мягкое требование формы в реальном времени «сможет читать из FIFO до того, как оно заполнится, и быстрее, чем заполняется»), это было бы оптимальным выбором.

Если такого решения не существует, ваши варианты переносят функции на отдельные контроллеры, используя решение CPU + FPGA (например, FPGA с жестким ядром ARM), или чистое решение FPGA (опционально с мягким CPU, в зависимости от требований сложности).