Zalety 32-bitowych mikroprocesorów 48-96 MHz (np. W Arduino Due)


10

Wygląda na to, że Arduino Due (32-bitowy, 84 MHz, SAM3X8E oparty na ARM-Cortex-M3) został wydany dzisiaj.

Ponadto wyraźnie jest mnóstwo procesorów w tej kategorii (32-bit / 48-96 MHz / ARM), a także odpowiednie płytki prototypowe:

  • NXP LPC1768 / mBed
  • STM32 / Discovery
  • PIC32 / ChipKit
  • Śmigło PIC32 / Parallax
  • LM4F120 / TI Launchpad
  • itp.

Staram się zrozumieć atrakcyjność tych „pośrednich” mikroprocesorów, które wydają mi się znajdować pomiędzy niskiej klasy AVR / MSP430 / itp. (zalety: niedrogi, energooszczędny, zajmujący niewiele miejsca) i wysokiej klasy ARM7 / etc (pro: zdolny do wykonywania znacznie większych instrukcji na sekundę).

W jakich sytuacjach lub sposobach odpowiedni jest mikroprocesor 32-bitowy / 48-96 MHz / ARM? Mówiąc dokładniej, zastanawiam się, w jakich aplikacjach lub w jakich parametrach byłyby lepszym wyborem podczas projektowania, zarówno w przypadku niższych 8-bitowych mikrokontrolerów, jak i bardzo zaawansowanych procesorów ARM7.


Cóż - przede wszystkim myślę, że możesz przetwarzać strumienie wideo na żywo - gdzie Arduino nie mógł sobie z tym poradzić. Pozwala także na zaawansowane algorytmy szyfrowania lub mieszanie (szybsze i łatwiejsze niż w Arduino) Dziwi mnie, że Arduino wyszło z 32-bitową platformą, ale to po prostu pokazuje - Niektórzy ludzie chcą zrobić coś więcej niż kontrolować przekaźnik. To wielki dzień dla Arduino!
Piotr Kula

Nie będziesz robił nic więcej niż trywialne przetwarzanie wideo na żywo na procesorze <100 MHz, chyba że zrobisz to w dołączonym specjalnym rdzeniu funkcji. A zwłaszcza nie w dość ograniczonym pokładowym pamięci RAM tych urządzeń. Bardziej realistycznym punktem jest to, że koszt tych układów nie jest znacznie wyższy niż koszt części 8-bitowych; może faktycznie być niższy niż ATMEGA przy porównywalnym flashowaniu i pamięci RAM.
Chris Stratton

3
O ile mi wiadomo, Parallax Propeller to niestandardowy układ bez związku z PIC32. Jakieś źródła połączenia?
AndrejaKo,

Odpowiedzi:


12

Jest to jeden z tych tematów, który może stać się przedmiotem dyskusji. Jest tak wiele różnych punktów widzenia, a różne rzeczy są ważne dla różnych ludzi. Spróbuję udzielić wyczerpującej odpowiedzi, ale zrozumiem, że zawsze znajdzie się ktoś, kto się nie zgodzi. Po prostu zrozum, że ci, którzy się ze mną nie zgadzają, są w błędzie. (Żartuję.)

Szybkie podsumowanie:

Ta odpowiedź będzie długa, więc podsumuję to z góry. Dla zdecydowanej większości ludzi najnowsza oferta układów ARM Cortex-M0 / M3 / M4 oferuje najlepsze rozwiązanie, najlepsze cechy pod względem kosztów. Jest to nawet prawdą, porównując te 32-bitowe jednostki MCU z ich 8 i 16-bitowymi przodkami, takimi jak PIC i MSP430. M0 można kupić za mniej niż 1 USD / każdy i M4 za mniej niż 2 USD / każdy, więc z wyjątkiem bardzo wrażliwych na cenę aplikacji rozwiązania ARM są bardzo ładne. M0 mają bardzo niską moc i powinny być wystarczające dla większości ludzi. Dla tych, którzy są bardzo wrażliwi na moc, MSP430 mogą być nadal lepszym wyborem, ale M0 są warte rozważenia nawet dla tych aplikacji.

Jeśli jesteś zainteresowany bardziej szczegółową analizą, czytaj dalej, w przeciwnym razie możesz przestać czytać teraz.

Teraz spojrzę na każdy obszar i porównam różne MCU:

Szybkość wykonania

Oczywiście 32-bitowe jednostki MCU będą szybsze. Zwykle mają większą prędkość zegara, ale także wykonują więcej pracy dla każdego z tych zegarów. MCU, takie jak ARM Cortex-M4, zawierają instrukcje przetwarzania DSP, a nawet mogą obsługiwać zmiennoprzecinkowe w sprzęcie. Procesory 8 i 16 bitowe mogą działać na liczbach 32-bitowych, ale nie jest to wydajne. Spowoduje to szybkie zużycie rejestrów procesora, cykli zegara procesora i pamięci flash do przechowywania programów.

Łatwość rozwoju

Moim zdaniem jest to najcenniejszy powód korzystania z nowoczesnych 32-bitowych MCU - ale także najbardziej niedoceniany. Pozwól mi najpierw porównać to z 8-bitowymi PIC. To najgorsze porównanie przypadków, ale także najlepiej ilustrujące moje punkty.

Mniejsze PIC zasadniczo wymagają programowania w języku asemblera. To prawda, że ​​dostępne są kompilatory C nawet dla 8-bitowych PIC, ale są one bezpłatne lub dobre. Nie można uzyskać kompilatora, który jest zarówno dobry, jak i darmowy. Darmowa wersja kompilatora została okaleczona, ponieważ jej optymalizacja nie jest tak dobra, jak wersja „Pro”. Wersja Pro kosztuje około 1000 USD i obsługuje tylko jedną rodzinę układów PIC (8, 16 lub 32 bity). Jeśli chcesz korzystać z więcej niż jednej rodziny, musisz kupić kolejną kopię za kolejne 1000 USD. „Standardowa” wersja kompilatora zapewnia średni poziom optymalizacji i kosztuje około 500 USD za każdą rodzinę układów. 8-bitowe PIC są wolne jak na współczesne standardy i wymagają dobrej optymalizacji.

Dla porównania istnieje wiele dobrych kompilatorów C dla jednostek MCU ARM, które są bezpłatne. W przypadku ograniczeń limity te dotyczą zazwyczaj maksymalnego rozmiaru obsługiwanej pamięci Flash. W narzędziach Freescale Codewarrior limit ten wynosi 128 KB. To dużo dla większości ludzi na tym forum.

Zaletą korzystania z kompilatora C jest to, że nie musisz zawracać sobie głowy (tak bardzo) szczegółami niskiego poziomu mapy pamięci procesora. Stronicowanie na PIC jest szczególnie bolesne i najlepiej go unikać, jeśli to w ogóle możliwe. Kolejną zaletą jest to, że nie musisz zawracać sobie głowy bałaganem związanym z przekazywaniem 16 i 32-bitowych liczb na 8-bitowym MCU (lub 32-bitowych liczb na 16-bitowym MCU). Chociaż nie jest to bardzo trudne w języku asemblera, jest to problem z tyłu i jest podatny na błędy.

Istnieją inne kompilatory C inne niż ARM, które działają dobrze. Kompilator MSP430 wydaje się wykonywać rozsądną robotę. Narzędzia Cypress PSoC (zwłaszcza PSoC1) są wadliwe.

Płaski model pamięci

MCU, które ma stronicowaną pamięć RAM / rejestry / Flash, jest po prostu głupie. Tak, mówię o 8-bitowych PIC. Głupi, głupi, głupi. To mnie tak bardzo zniechęciło do PIC, że nawet nie zadałem sobie trudu, aby spojrzeć na ich nowsze rzeczy. (Oświadczenie: oznacza to, że nowe PIC mogą zostać ulepszone i po prostu tego nie wiem.)

Przy 8-bitowym MCU dostęp do struktur danych większych niż 256 bajtów jest trudny (ale nie niemożliwy). Z 16-bitowym MCU, który zwiększa się do 64 kB lub kwordów. Z 32-bitowymi jednostkami MCU, które zwiększają się do 4 gigabajtów.

Dobry kompilator C może ukryć wiele tego przed programistą (alias You), ale nawet wtedy wpływa to na rozmiar programu i szybkość wykonywania.

Istnieje wiele aplikacji MCU, dla których nie będzie to stanowić problemu, ale oczywiście jest wiele innych, które będą miały z tym problemy. Jest to głównie kwestia tego, ile danych potrzebujesz (tablice i struktury) w pamięci RAM lub Flash. Oczywiście wraz ze wzrostem prędkości procesora rośnie również szansa na użycie większych struktur danych!

wielkość paczki

Niektóre małe PIC i inne 8-bitowe MCU są dostępne w naprawdę małych pakietach. 6 i 8 pinów! Obecnie najmniejszy znany mi ARM Cortex-M0 znajduje się w QFN-28. Chociaż QFN-28 jest wystarczająco mały dla większości, nie jest wystarczająco mały dla wszystkich.

Koszt

Najtańszy PIC to około jednej trzeciej ceny najtańszego ARM Cortex-M0. Ale to naprawdę 0,32 USD vs. 0,85 USD. Tak, ta różnica cen ma dla niektórych znaczenie. Ale sądzę, że większość ludzi na tej stronie nie przejmuje się tak niewielką różnicą kosztów.

Podobnie, porównując bardziej wydajne MCU z ARM Cortex-M0 / M3 / M4, zwykle ARM Cortex wychodzi „z grubsza nawet” lub na wierzchu. Gdy uwzględni się inne rzeczy (łatwość programowania, koszty kompilatora itp.), ARM są bardzo atrakcyjne.

Drugie podsumowanie

Chyba prawdziwe pytanie brzmi: dlaczego NIE używałbyś ARM Cortex-M0 / M3 / M4? Kiedy absolutny koszt jest bardzo ważny. Gdy bardzo niskie zużycie energii ma kluczowe znaczenie. Gdy wymagany jest najmniejszy rozmiar paczki. Gdy prędkość nie jest ważna. Jednak w zdecydowanej większości aplikacji żadna z nich nie ma zastosowania, a ARM jest obecnie najlepszym rozwiązaniem.

Biorąc pod uwagę niski koszt, chyba że istnieje dobry powód, aby nie używać ARM Cortex, wówczas warto go użyć. Pozwoli to na szybszy i łatwiejszy czas programowania z mniejszymi problemami i większymi marginesami projektowymi niż większość innych MCU.

Dostępne są inne 32-bitowe jednostki MCU spoza ARM Cortex, ale też nie widzę w nich żadnej korzyści. Standardowa architektura procesora ma wiele zalet, w tym lepsze narzędzia programistyczne i szybsze wprowadzanie innowacji w tej technologii.

Oczywiście rzeczy mogą się zmieniać. To, co mówię, jest ważne dzisiaj, ale może nie być ważne za rok, a nawet miesiąc. Odrób swoją pracę domową.


1
Aby uzyskać dostęp do dowolnej lokalizacji pamięci za pomocą ARM, należy najpierw załadować rejestr o adresie znajdującym się w jego 4K; wiele urządzeń I / O ma przydzieloną więcej niż 4K przestrzeni adresowej, chociaż wiele z nich używa tylko kilku dyskretnych adresów. Natomiast PIC 18Fxx mogą bezpośrednio działać w większości lokalizacji we / wy za pomocą jednej instrukcji, niezależnie od stanu bankowości. Środki, za pomocą których gromadzona jest większość pamięci RAM, są dość irytujące, ale w przypadku niektórych rodzajów bitów (cel, dla którego architektura PIC została zaprojektowana w latach 70.) architektura PIC działa bardzo dobrze.
supercat

1
BTW, ciekawi mnie, że chociaż popularny 8-bitowy mikroprocesor z lat 70-tych mógł skutecznie przetwarzać arbitralnie wyrównane 256-bajtowe struktury danych, a popularny 16-bitowy procesor mógł dobrze współpracować z 65 536-bajtowymi strukturami danych, które zostały wyrównane do 16 -bajtowe granice lub dowolnie wyrównane struktury danych prawie tak duże, nowsze 8-bitowe i 16-bitowe procesory utrudniają pisanie wydajnego kodu, który przekracza granice strony / banku.
supercat

@ superuper Zakres adresów 4K dla instrukcji „Natychmiastowe przesunięcie LDR / SRT” jest prawdziwy, ale często nie stanowi problemu. Nie zgadzam się z resztą twojego komentarza. Patrząc na dokumenty Freescale M4, każde urządzenie peryferyjne nie zajmuje więcej niż 4K zakresu adresów, więc pojedynczy „wskaźnik adresu bazowego” jest wystarczający do uzyskania dostępu do wszystkich rejestrów w tym urządzeniu peryferyjnym. Istnieją również 32 rejestry ogólnego przeznaczenia, z których każdy może być używany jako wskaźnik adresu bazowego - więc szybki dostęp do wielu urządzeń peryferyjnych w tej samej sekcji kodu jest stosunkowo bezbolesny.

1
@ superuper Twój drugi punkt dotyczy całej debaty RISC vs. CISC. ARM to procesor RISC, co oznacza, że ​​jest zoptymalizowany do wykonywania najczęstszych zadań. Zadania, które nie są częste, takie jak niezaangażowane dostępy, wymagają więcej pracy lub zajmują więcej czasu (w zależności od Arch CPU). Uważam to za coś pozytywnego, a nie negatywnego. Właśnie dlatego otrzymujemy szybkie 32-bitowe jednostki MCU w cenie starszej wersji 8-bitowej. Nawet z tymi dziwactwami, wziąłbym jeden z tych procesorów przez PIC każdego dnia.

Źle powiedziałem; Nie chciałem sugerować, że jeden rejestr podstawowy nie byłby w stanie obsłużyć całego urządzenia peryferyjnego, ale raczej, że rejestr musiałby być często ładowany dla każdego urządzenia peryferyjnego (więc nie można po prostu np. Pozostawić rejestru z IO_BASE_ADDR cały czas ). W przypadku niektórych typów kodu możliwość ustawienia bitu we / wy w jednym cyklu za pomocą instrukcji typu „bsf LATA, 4”, bez konieczności wcześniejszego wstępnego ładowania rejestrów, może być bardzo przydatna. Lubię ARM, ale bezpośrednie mapowanie I / O na PIC może być całkiem fajne (szkoda, że ​​inny dostęp do pamięci nie jest tak miły).
supercat

3

David Kessner ma rację. Chciałbym dodać następujące.

  1. 8-bitowe jednostki MCU są jedynymi jednostkami MCU, które są łatwo dostępne w pakietach PDIP, które są łatwe w obsłudze i łatwe do naklejenia w płytce prototypowej.
  2. 32-bitowe MCU mogą zużywać mniej energii niż MCU 8-bitowe. Niekoniecznie jest prawdą, że 8-bitowy MCU <20 MHZ zużywa mniej energii niż Cortex M4.
  3. 8-bitowe MCU są często używane przez hobbystów, którzy zwykle nie wymagają wiele od MCU. Może kilkaset linii prostego kodu C.

Zgadzam się, że w dzisiejszych czasach nie ma powodu, aby nie używać 32-bitowych jednostek MCU. Używałbym ich tylko [8-bitowe MCU] z dwóch powodów: podoba mi się łatwość pakietu PDIP (nie wymaga lutowania); Często nie potrzebuję więcej mocy / złożoności niż to, co może zaoferować 8-bitowy MCU.

Łamacz interesów to tak naprawdę dostępne narzędzia.


Do prototypowania istnieją gniazda dla LQFP, które działają dość dobrze. I oczywiście można lutować LQFP ręcznie, po prostu zajmuje trochę praktyki. QFN, DFN i BGA Nie lutowałbym ręcznie, ale wtedy każde 32-bitowe MCU niskiej jakości na rynku jest dostarczane z LQFP.
Lundin

1

Używamy względnie niemodnego Freescale MCF52259, MCU obsługującego 32-bit ~ 80 MHz.

Powody / przemyślany proces wyboru były następujące:

  • Zastępował 32-bitowe urządzenie M.Core, więc przenoszenie było stosunkowo proste
  • Oznaczało to również, że możemy trzymać się istniejącego IDE (CodeWarrior)
  • Potrzebowaliśmy dużo IO: Kontrola kroku / kierunku w 3 silnikach krokowych, 4 kanałach PWM, 3 UART oraz I2C i SPI.
  • Dużo się działo (patrz ostatni punkt) i niektóre z nich musiały się odbyć w odpowiednim czasie, więc musieliśmy się upewnić, że jest wystarczająco dużo cykli procesora, aby wszystko załatwić.
  • Stary kod zderzał się z 256k flashowym rozmiarem i 32k RAM pamięci M.Core, więc podwojenie pamięci flash i pamięci RAM sprawiło, że życie szybko zaczęło działać.

W dzisiejszych czasach bardziej opłacalne (i celowe) jest nadmierne specyfikowanie / rozszerzanie możliwości sprzętu (pamięć, szybkość, operacje wejścia / wyjścia itp.) Niż poświęcanie cennego czasu na programowanie na optymalizację kodu w celu wtłoczenia w nieco tańsze / mniejsze MCU, chyba że miejsce lub moc to duże problemy.

W naszym przypadku urządzenie było dwukrotnie lepsze niż M.Core za połowę ceny, przejście na tańszą MCU pozwoliłoby zaoszczędzić tylko grosze na płytę, ale kosztowało dużo czasu rozwoju i ograniczyło potencjał do dalszego rozwoju bez zmiany MCU ponownie.

Gdybyśmy budowali milion desek, warto by wykonać ćwiczenie inżynierii kosztów w celu sparaliżowania rzeczy, ale w tej chwili nie warto poświęcać czasu na opracowanie.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.