Переваги 32-бітових мікропроцесорів 48-96 МГц (наприклад, у Arduino Due)


10

Схоже, Arduino Due (32-бітний, 84 МГц, SAM3X8E на базі ARM-Cortex-M3) вийшов сьогодні.

Крім того, чітко є безліч процесорів цієї категорії (32-бітний / 48-96 МГц / ARM), а також відповідні плати прототипування:

  • NXP LPC1768 / мБед
  • STM32 / Відкриття
  • PIC32 / ChipKit
  • Пропелер PIC32 / Parallax
  • LM4F120 / TI Launchpad
  • тощо.

Я намагаюся зрозуміти привабливість цих мікропроцесорів "між", які, як мені здається, лежать між AVR / MSP430 / тощо. (плюси: недорогий, малопотужний, малопомітний) і висококласний ARM7 / тощо (професіонал: здатний набагато більше інструкцій в секунду).

У яких ситуаціях чи способах мікропроцесори на основі 32-бітних / 48-96 МГц / ARM є підходящим вибором? Більш конкретно, мені цікаво, які додатки або в яких параметрах вони б зробили для найкращого вибору під час проектування, як над 8-бітовими мікроконтролерами низького класу, так і над висококласними процесорами ARM7.


Ну, перше, на мій погляд, ви можете обробити прямі потоки відео - там, де Arduino не впорається з цим. Він також дозволяє вдосконалені алгоритми шифрування або хешування (швидше і простіше, ніж у Arduino). Я здивований, що Arduino вийшов з 32-бітовою платформою, але це просто показує вам - Деякі люди хочуть зробити більше, ніж управляти реле. Це прекрасний день для Ардуїно!
Пьотр Кула

Ви не будете займатися більш тривіальною обробкою відео в режимі <100 МГц, якщо тільки ви не зробите це в прикріпленому спеціальному функціональному ядрі. І особливо не в досить обмеженому бортовому барі на цих пристроях. Більш реалістичним моментом є те, що вартість цих чіпів просто не істотно вище, ніж 8-бітових деталей; вона може бути нижчою, ніж ATMEGA із порівнянними спалахами та рамками.
Кріс Страттон

3
Наскільки я знаю, Parallax Propeller - це власний чіп, який не має відношення до PIC32. Будь-які джерела для підключення?
AndrejaKo

Відповіді:


12

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

Короткий підсумок:

Ця відповідь буде довгою, тому дозвольте підсумувати це наперед. Для переважної більшості людей остання врожай мікросхем ARM Cortex-M0 / M3 / M4 пропонує найкраще рішення, найкращі характеристики за вартістю. Це навіть вірно, порівнюючи ці 32-бітні MCU з їх 8 та 16-бітовими предками, такими як PIC та MSP430. M0 можна придбати за менше ніж 1 долар США / кожен, а M4 - менше, ніж 2 долари США / кожен, тому, за винятком дуже чутливих до ціни програм, рішення ARM дуже приємні. M0 мають дуже низьку потужність і повинні бути досить хорошими для більшості людей. Для тих, хто дуже чутливий до потужності, MSP430 можуть все-таки бути кращим вибором, але M0 варто розглянути навіть для цих програм.

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

Зараз я розгляну кожну область та порівняю різні MCU:

Швидкість виконання

Звичайно, 32-бітні MCU будуть швидшими. Вони, як правило, мають більш високу тактову частоту, але також роблять більше роботи для кожного з цих годин. MCU, такі як ARM Cortex-M4, включають інструкції з обробки DSP і навіть можуть мати технічну підтримку з плаваючою комою. 8 і 16 бітні процесори можуть працювати на 32-бітних номерах, але це не ефективно в цьому. Це дозволить швидко споживати регістри процесора, тактові цикли процесора та флеш-пам’ять для зберігання програми.

Простота розвитку

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

Менші PIC-програми в основному вимагають, щоб програмування було виконано мовою складання. Правда, є навіть компілятори C, доступні навіть для 8-бітних ПІК, але ці компілятори є безкоштовними або хорошими. Ви не можете отримати компілятор, який є і хорошим, і безкоштовним. Безкоштовна версія компілятора покалічена тим, що її оптимізація не така хороша, як версія "Pro". Версія Pro становить приблизно 1000 доларів США і підтримує лише одне сімейство чіпів PIC (8, 16 або 32 бітових чіпів). Якщо ви хочете використовувати більше однієї родини, тоді вам доведеться придбати іншу копію ще на 1000 доларів США. "Стандартна" версія компілятора робить середній рівень оптимізації і коштує близько 500 доларів США для кожної сім'ї чіпів. 8-бітні PIC-карти повільні за сучасними стандартами і потребують хорошої оптимізації.

Для порівняння, існує багато хороших компіляторів С для ARM MCU, які є безкоштовними. Якщо є обмеження, ці обмеження зазвичай є на максимальному розмірі підтримуваної Flash-пам'яті. На інструментах Freescale Codewarrior ця межа становить 128 Кбайт. Для більшості людей на цьому форумі це достатньо.

Перевага використання компілятора C полягає в тому, що вам не доведеться турбуватися (настільки сильно) з деталями низького рівня карти пам'яті процесора. Пейджинг на ПІК особливо болючий і його краще уникати, якщо це можливо. Ще одна перевага полягає в тому, що вам не доведеться турбуватися з безладом передачі 16 і 32 бітових чисел на 8-бітний MCU (або 32 бітові числа на 16-бітному MCU). Хоча це не складно зробити це мовою складання, болі в тилу і схильні до помилок.

Є й інші компілятори, що не належать до ARM, які добре працюють. Здається, компілятор MSP430 робить розумну роботу. Інструменти Cypress PSoC (особливо PSoC1) є помилковими.

Модель з плоскою пам'яттю

MCU, який запрограмував оперативну пам'ять / регістри / Flash, просто дурний. Так, я кажу про 8-бітові фотокамери. Тупий, німий, німий. Це настільки відключило мене від ПІК, що я навіть не потрудився подивитися на їх новіші речі. (Відмова: це означає, що нові PIC можуть бути вдосконалені, і я просто не знаю цього.)

За допомогою 8-бітного MCU важко (але не неможливо) отримати доступ до структур даних розміром понад 256 байт. З 16-бітним MCU, який збільшується до 64 кбайт або kwords. З 32-бітними процесорами, розміром до 4 гігабайт.

Хороший компілятор C може приховати багато цього від програміста (він же), але навіть тоді він впливає на розмір програми та швидкість виконання програми.

Існує багато програм MCU, для яких це не буде проблемою, але, звичайно, є багато інших, які матимуть проблеми з цим. Це здебільшого питання про те, скільки потрібних вам даних (масивів та структур) в оперативній пам'яті або Flash. Звичайно, у міру збільшення швидкості процесора збільшуються шанси на використання великих структур даних!

Розмір упаковки

Деякі з невеликих ПІК та інші 8-бітні MCU доступні в дійсно невеликих пакетах. 6 і 8 шпильок! В даний час найменший ARM Cortex-M0, про який я знаю, знаходиться в QFN-28. Хоча QFN-28 достатньо малий для більшості, він недостатньо малий для всіх.

Вартість

Найдешевший PIC становить приблизно третину ціни найдешевшого ARM Cortex-M0. Але це дійсно 0,32 долара США проти 0,85 долара США. Так, різниця в ціні має значення для деяких. Але я вважаю, що більшість людей на цьому веб-сайті не переймаються такою незначною вартістю.

Аналогічно, при порівнянні більш спроможних MCU з ARM Cortex-M0 / M3 / M4 зазвичай ARM Cortex виходить «приблизно рівним» або зверху. Якщо враховувати інші речі (простота розробки, витрати на компілятор тощо), ARM дуже привабливі.

Друге резюме

Я думаю, що справжнє питання: Чому б ви НЕ використовували ARM Cortex-M0 / M3 / M4? Коли абсолютна вартість надзвичайно важлива. Коли надзвичайно низьке енергоспоживання є критичним. Коли потрібен найменший розмір упаковки. Коли швидкість не важлива. Але для переважної більшості застосувань жодне з них не застосовується, і ARM в даний час є найкращим рішенням.

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

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

Звичайно, все може і змінитися. Те, що я кажу, є дійсним сьогодні, але може бути недійсним через рік чи навіть місяць. Зробіть власні домашні завдання.


1
Щоб отримати доступ до будь-якого місця пам'яті за допомогою ARM, потрібно спочатку завантажити реєстр з адресою, що знаходиться в межах 4K від нього; багатьом пристроям вводу / виводу виділено більше 4 К адресного простору, хоча багато хто використовують лише кілька дискретних адрес. На противагу цьому, PIC 18Fxx можуть безпосередньо працювати в більшості локацій вводу / виводу за допомогою однієї інструкції, незалежно від стану банківської справи. Засоби, якими користується більша частина оперативної пам’яті, досить дратують, але для деяких типів біт-ударів (мета, для яких архітектура PIC була розроблена в 1970-х роках) архітектура PIC працює дуже добре.
supercat

1
До речі, мені здається цікавим, що хоча популярний 8-бітовий мікропроцесор з 1970-х років міг ефективно обробляти довільно вирівняні 256-байтні структури даних, а популярний 16-розрядний процесор міг добре працювати з 65,536-байтними структурами даних, вирівняними на 16 -байтові межі або довільно вирівняні структури даних майже у таких великих, новіших 8-бітових та 16-бітних процесорів ускладнюють написання ефективного коду, який стримує межі сторінки / банку.
supercat

@supercat Діапазон адрес 4K для інструкції "Невідкладне зміщення LDR / SRT" є правдою, але часто це не є проблемою. Я не згоден з рештою вашого коментаря. Дивлячись на документи Freescale M4, кожна периферія не займає більше 4К діапазону адрес, тому одного "базового вказівника адреси" достатньо для доступу до всіх регістрів цієї периферії. Існує також 32 регістри загального призначення, будь-який з яких може використовуватися в якості вказівника базової адреси - тому доступ до декількох периферійних пристроїв швидко в одному і тому ж розділі коду відносно безболісний.

1
@supercat Ваш другий пункт стосується всієї дискусії щодо RISC проти CISC. ARM - це процесор RISC, що означає, що він оптимізований для виконання найчастіших завдань. Завдання, які не є частими, як нестандартний доступ, вимагають або більше роботи, або вимагають більше часу (залежно від арки процесора). Я розглядаю це як позитив, а не негатив. Ось чому ми отримуємо швидкі 32-бітні MCU за ціну старшого 8-бітного. Навіть з цими химерностями я б взяв один із цих процесорів над PIC будь-якого дня.

Я пропускаю помилку; Я не мав на увазі, що один базовий реєстр не може обробляти всю периферійну мережу, а навпаки, що регістр часто доводиться завантажувати для кожної периферії (тому не можна просто, наприклад, залишати реєстр, який постійно працює з IO_BASE_ADDR ). Для деяких типів коду можливість встановити біт вводу / виводу в одному циклі за допомогою команди "bsf LATA, 4", не потребуючи попереднього завантаження будь-яких регістрів, може бути дуже зручною. Мені подобається ARM, але пряме відображення вводу / виводу на PIC може бути дуже приємним (занадто поганий доступ до іншої пам'яті не так приємно).
supercat

3

Девід Кесснер правильно. Я хотів би додати наступне.

  1. 8-бітні MCU - це єдині MCU, які легко доступні в пакетах PDIP, які легко обробляти і легко вставляти на макеті прототипу.
  2. 32-бітні MCU можуть реально використовувати меншу потужність, ніж 8-бітні MCU. Не обов'язково вірно, що <20 МГц 8-бітний MCU буде використовувати менше енергії, ніж Cortex M4.
  3. 8-бітні MCU часто використовуються любителями, які зазвичай не вимагають багато від MCU. Можливо, кілька сотень рядків простого коду С.

Я погоджуюся, що в наші дні є мало причин не використовувати 32-бітні MCU. Я б використовував їх [8-бітні MCU] лише з 2 причин: мені подобається легкість пакету PDIP (не потрібна пайка); Мені часто не потрібно більше енергії / складності, ніж те, що може запропонувати 8-бітний MCU.

Укладач угод - це справді доступні інструменти.


Для прототипування є розетки для LQFP, які працюють досить добре. І звичайно, ви можете паяти LQFP вручну, просто потрібно трохи практики. QFN, DFN та BGA я б не паяв вручну, але тоді кожен окремий 32-розрядний 32-розрядний MCU на ринку поставляється з LQFP.
Лундін

1

Ми використовуємо відносно немодний Freescale MCF52259, 32-бітний ~ 80 МГц, здатний MCU.

Причини / думки про вибір:

  • Він заміняв 32-розрядний пристрій M.Core, тому перенос був відносно простим
  • Це також означало, що ми можемо дотримуватися існуючої IDE (CodeWarrior)
  • Нам знадобилося багато IO: управління кроком / напрямком на 3 крокових двигунах, 4 каналах ШІМ, 3 UART та I2C та SPI.
  • Багато що відбувалося (див. Останній пункт), і деякі з них повинні були відбутися своєчасно, тому нам потрібно було впевнитись, що є достатньо циклів процесора, щоб все зробити.
  • Старий код натрапив на розмір спалаху 256k та 32 Кб оперативної пам’яті M.Core, тому подвоєння спалаху та оперативної пам’яті полегшили життя швидко та швидко працювали.

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

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.