Один великий мікроконтролер, чи багато малих мікроконтролерів?

Я звик робити основні і прості речі з мікроконтролерами, відносно кажучи. Такі речі, як світлодіодні двигуни, запущені двигуни, основні режими роботи, графічні інтерфейси на РК-дисплеях символів тощо, але завжди лише одне ключове завдання з максимум кількома невеликими побічними завданнями. Це призвело до того, що я маю на увазі низькі кінцеві продукти, оскільки це справді все, що потрібно в цих випадках.

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

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

Я думаю, моє запитання справді двояке:

1. Чи гарна ідея підходу "все в одному", коли потрібно робити багатозадачність, чи краще сегментувати та ізолювати, і

2. Як я можу інтуїтивно дізнатись, чи є у мікроконтролера, на який я дивлюсь, достатня обчислювальна потужність, щоб зробити те, що мені потрібно, виходячи зі списку завдань?

Я дивлюся на помірні dsPIC33, аж до ARM SoC, які працюють з RTOS. Систематичний спосіб зменшити те, що мені потрібно, дуже допоможе мені.

Відповіді на ваші запитання різні залежно від того, яка ваша кінцева мета. Якщо вам потрібна кілька або менше цих пристроїв, вам слід полегшити розробку, а не турбуватися про вартість деталей. Якщо ви збираєтеся виготовити тисячу і більше таких, варто проаналізувати свої вимоги та зменшити вартість апаратного забезпечення пристрою.

Невеликі кількості

Якщо ви робите одноразовий або невеликий запуск цих пристроїв, тоді ваші зусилля з розвитку збираються зменшити ваші витрати за кожний товар, і вам слід зосередитись на тому, що буде найпростішим / швидким для вашого розвитку, а не на витратах / розмір мікроелектроніка.

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

Тож у цьому випадку відповідь на ваші запитання:

Чи гарна ідея підходу "все в одному", коли потрібно робити багатозадачність, чи краще сегментувати та ізолювати, і

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

Як я можу інтуїтивно дізнатись, чи є у мікроконтролера, на який я дивлюсь, достатня обчислювальна потужність, щоб зробити те, що мені потрібно, виходячи зі списку завдань?

У цьому випадку різниця у вартості між 32-бітовим процесором з великою кількістю ресурсів і 8-бітним процесором з обмеженими ресурсами невелика щодо кількості часу, який ви збираєтеся витратити на роботу над розробкою. Немало підстав намагатися розібратися, яка потужність вам потрібна - просто отримайте найбільший процесор, який ви відчуваєте, що можете його розробити і використовувати. Якщо в якийсь пізній момент вам доведеться витратити гроші на оптимізацію дизайну, виміряти фактичне використання ресурсів процесора порівняно просто, то вибирайте процесор-лізингодавець, який може впоратися з фактичним навантаженням. До цього часу використовуйте найбільший і не переживайте за те, щоб знайти "найкращу форму".

Масове виробництво

Якщо ви плануєте виготовити багато з цих пристроїв, то ретельний аналіз принесе значну економію коштів. Взагалі кажучи, більший мікроконтролер обійдеться менше двох мікроконтролерів, здатних замінити один мікроконтролер, хоча, безумовно, є винятки залежно від конкретних необхідних завдань. У цих кількостях вартість апаратного забезпечення, ймовірно, буде значно більшою, ніж вартість розробки, тому слід розраховувати витратити більше часу на аналіз своїх вимог та виконання розробки, ніж ви б, якби ви робили лише кілька.

Чи гарна ідея підходу «все в одному», коли потрібно робити багатозадачність, або краще сегментувати та ізолювати?

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

Як я можу інтуїтивно дізнатись, чи є у мікроконтролера, на який я дивлюсь, достатня обчислювальна потужність, щоб зробити те, що мені потрібно, виходячи зі списку завдань?

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

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

Ваші USB та послідовні програми будуть вимагати Y циклів процесорного часу за необхідності, 2 кб оперативної пам’яті, 64 байт EEPROM та 8 кб спалаху. Для цього знадобиться USB та послідовна периферія.

Ваш графічний інтерфейс споживає Z циклів потужності процесора 30 разів на секунду, і йому знадобляться 2 кб оперативної пам’яті, 128 байт EEPROM та 10k спалах. Він використовуватиме 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 Books .

У цій главі йдеться про розробку архітектур системи та пропонується напівформальний підхід до того, як можна найкраще інкапсулювати завдання. Хоча розділ в основному стосується однієї системи контролерів, вона легко поширюється на кілька контролерів. Це допоможе вам уявити, якими ресурсами потрібно ділитися, і допоможе вам вибрати рівень інкапсуляції для кожного завдання.

Вона пропонує розглянути різні погляди, один з яких я показую нижче, але є багато корисних маніпуляцій. Це, звичайно, не має особливого сенсу саме по собі, але я сподіваюся, що це спонукає вас перевірити розділ.

Щодо "як я можу знати, чи є у мене достатньо контролера", моя власна перевага полягає в тому, щоб вкласти якомога більше енергії в мою розробку пісочниці, наскільки я можу, а потім з'ясувати, скільки ресурсів я можу скоротити після того, як дизайн добре підійде. шлях. Різниця в ціні між мікроконтролером $ 10 і мікроконтролером $ 3 для цілей прототипування може бути лише тижнями переобладнання та подвійним пальцем, які чекають нових деталей, тоді як дизайн завжди може рухатися, якщо у вас є достатня потужність.

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

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

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

Однак у цьому випадку я б сказав, що є деяка цінність у використанні невеликих дешевих мікросхем для обробки критичних функцій (управління двигуном EG, коли час і зупинка на ліміті є критичними) під командуванням головного процесора "мозку", тому ви не покладаєтесь в ОС "не в реальному часі", щоб зробити щось своєчасно.

Усі відповіді краще, але я маю трохи додати, що може бути корисним. Це може бути трохи поза межею, і я хотів би додати це як коментар, але є правило 50 повторів :(

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

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

Звичайно, вартість, простота реалізації; тощо важливі і ще важливіші для розгляду.

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

"Кінські сили" є вторинними щодо того, чи зможете ви виконати свої обмеження в режимі реального часу.

Якщо у вас є два вихідні ШІМ, і обидва потрібно перемикатися в той самий час, тоді вам потрібно мати необхідний паралелізм, щоб мати можливість це робити. Якщо у вас є спеціалізований контролер ШІМ, який піклується про точні терміни, він буде працювати навіть при досить невеликому мікроконтролері, тоді як рішення на основі GPIO будуть досить складними, навіть якщо доступна велика кількість обчислювальної потужності.

У більшості протоколів сучасні MCU вбудовують реалізацію тих частин протоколу, які мають обмеження в режимі реального часу, тому якщо ви можете знайти MCU, який має необхідні периферійні пристрої та має необхідну швидкість процесора для обробки потоків даних (тобто жорсткі вимоги реального часу вироджуються вимога форми «м'якого в реальному часі» «зможе прочитати з FIFO до того, як вона буде заповнена, і швидше, ніж вона заповниться»), це було б оптимальним вибором.

Якщо такого рішення не існує, ваші параметри є або переміщенням функцій в окремі контролери, використовуючи рішення процесора + FPGA (наприклад, FPGA з жорстким ядром ARM), або чисте рішення FPGA (необов'язково з м'яким процесором, залежно від вимог складності).