Wzrost popularności 32-bitowych mikrokontrolerów (MCU) wśród społeczności embedded nie jest zaskoczeniem. Te bogate w funkcje urządzenia nadają się do wielu różnych zastosowań, co wyjaśnia, dlaczego wielu programistów wybiera je do swoich kolejnych projektów. Projektanci zdają sobie sprawę, że takie złożone urządzenia oferują wszystko, czego potrzebują w zakresie surowej mocy obliczeniowej, bogatego zestawu peryferiów oraz łatwego dostępu do szerokiej gamy narzędzi programistycznych i bibliotek.
Wiele z tych 32-bitowych urządzeń opartych jest na cieszących się dużym powodzeniem rdzeniach ARM. Dzięki temu programiści mogą być pewni, że mają dostęp do urządzeń z drugiego źródła oraz kompleksowego zestawu narzędzi do rozwoju, testowania i walidacji, które są dostępne na rynku.
Jednakże bliższe przyjrzenie się ostatnim trendom na rynku MCU ujawnia, że urządzenia 32-bitowe nie są jedynymi, które przeżywają silny wzrost (tabela 1). Dynamicznie rozwijający się rynek 8-bitowych MCU może pochwalić się złożoną stopą wzrostu (6,4%) zbliżoną do stopy wzrostu rynku 32-bitowego (6,9%). Inni analitycy branżowi przewidują identyczne wskaźniki wzrostu dla mikrokontrolerów 8- i 32-bitowych.
Szczytny wzrost popularności urządzeń 8-bitowych wyraźnie pokazuje, że muszą istnieć istotne powody, aby stosować urządzenia 8-bitowe zamiast 32-bitowych MCU. W tym artykule staramy się wyjaśnić, dlaczego urządzenia 8-bitowe zachowują udział w rynku.
Zasadnicze różnice
Zasadnicze różnice między 8- i 32-bitowymi jednostkami MCU to koszt i struktura cenowa, wydajność procesora, łatwość obsługi, wydajność w zakresie funkcji zbliżonych do sprzętowych oraz statyczny pobór mocy. Rozpoczynając prace nad nowym projektem, programiści muszą dokładnie określić wymagania dotyczące MCU, biorąc pod uwagę wymaganą wydajność przetwarzania, stopień wymaganego interfejsu oraz, w przypadku projektów zasilanych bateryjnie, profile zużycia energii. Nie ma wątpliwości, że 32-bitowy MCU zapewnia wyższą wydajność niż urządzenie 8-bitowe, ale inżynier staje przed tradycyjną decyzją wyboru pomiędzy najlepszym dostępnym na rynku urządzeniem a rzeczywistymi potrzebami aplikacji.
Oczywiście, decyzje te w znacznym stopniu wpłyną na prawdopodobny koszt rachunku materiałów (BOM). Przy niższej liczbie bramek, mniej złożone urządzenie 8-bitowe będzie z pewnością tańsze niż urządzenie 32-bitowe. Porównując 8- i 32-bitowe MCU wiodących producentów, każdy z podobną ilością pamięci flash, rozmieszczeniem pinów itd., urządzenia 8-bitowe kosztują zwykle o około 20% mniej. Ale to tylko pierwsza z wielu kwestii, które należy wziąć pod uwagę. Kolejny aspekt dotyczy łatwości konfiguracji nowego projektu.
Łatwość rozwoju
Dostawcy układów scalonych zwykle dodają więcej cech i funkcjonalności do swoich urządzeń 32-bitowych w porównaniu z produktami 8-bitowymi. W związku z tym w przypadku bardziej złożonych urządzeń pojawia się znacznie więcej problemów związanych z konfiguracją. Podczas gdy niektóre 32-bitowe MCU mogą pracować z ograniczoną konfiguracją podobną do tej w urządzeniach 8-bitowych, nie można skorzystać z dodatkowych funkcji potężniejszego urządzenia.
 |
Pobierz ten artykuł w formacie .PDF Ten typ pliku zawiera grafikę w wysokiej rozdzielczości i schematy, jeśli dotyczy. |
Na przykład typowe 32-bitowe urządzenie ARM będzie miało niezależne ustawienia zegara dla samego rdzenia, magistrali AHB, magistrali APBA i magistrali APBB. Wszystkie one mogą być ustawione na różne częstotliwości. Zazwyczaj będziesz musiał także przełączać się na zegar, którego chcesz używać, ponieważ jest on ustawiany programowo, a nie sprzętowo, jak w przypadku większości części 8-bitowych. Co więcej, zmiana zegara oznacza konieczność ustawienia stanów oczekiwania dla pamięci flash, prawdopodobnie w oparciu o zmierzone napięcie VCC.
Takie ustawienia mogą być znacznie prostsze w przypadku 8-bitowych MCU. Na przykład, produkty tinyAVR i megaAVR firmy Atmel wymagają jedynie inicjalizacji wskaźnika stosu, co zwykle zajmuje cztery linie kodu, przed zakodowaniem aplikacji. Wybór zegara, detektora wyłączeń, funkcji pinu resetującego, itd. jest wstępnie zaprogramowany w urządzeniu.
Architektura jest również dużo prostsza niż w przypadku urządzeń 32-bitowych z wewnętrznymi rejestrami, urządzeniami peryferyjnymi i pamięcią SRAM mapowanymi na tej samej szynie danych. Urządzenia peryferyjne i procesor zazwyczaj pracują z tą samą częstotliwością, więc nie jest konieczna konfiguracja magistrali peryferyjnej. Ponadto projektanci mogą uniknąć obaw o opóźnienia w synchronizacji między różnymi domenami zegara.
Wydajność
Jeśli chodzi o pożądaną wydajność procesora, inżynier powinien rozważyć wszystkie przypadki użycia. Rzeczywistość jest taka, że wiele projektów wbudowanych nie ma wysokich wymagań obliczeniowych. Często wymagana jest bardzo niewielka manipulacja danymi, więc zrównoważenie tych potrzeb z wymaganiami dotyczącymi zużycia energii i współpracy z peryferiami staje się kluczowe.
Na przykład, prosta aplikacja termostatu spędzi większość swojego życia w trybie uśpienia. Co jakiś czas będzie się budzić i mierzyć temperaturę, a następnie podejmować decyzję o włączeniu/wyłączeniu przekaźnika lub wysłaniu instrukcji do kontrolera hosta. Następnie powróci do stanu uśpienia. Wymagania obliczeniowe i interfejsowe tej aplikacji są niewielkie, ale wiele innych aplikacji, takich jak czujniki pożarowe, elektronarzędzia, przepływomierze i układy sterujące urządzeniami, również mają podobny profil użycia.
Efektywność sprzętowych funkcji bliskich
Wiele nowoczesnych mikrokontrolerów zawiera pewne funkcje sprzętowe, które pomagają procesorowi centralnemu działać tak wydajnie, jak to tylko możliwe. W przypadku firmy Atmel, zarówno 8-bitowe AVR jak i 32-bitowe MCU oparte na ARM posiadają system zdarzeń peryferyjnych. System zdarzeń to zestaw funkcji sprzętowych, które pozwalają urządzeniom peryferyjnym na interakcję bez interwencji ze strony CPU. Pozwala on urządzeniom peryferyjnym na wysyłanie sygnałów bezpośrednio do innych urządzeń peryferyjnych, zapewniając krótki i w 100% przewidywalny czas reakcji.
Przy pełnym wykorzystaniu możliwości systemu zdarzeń, układ można skonfigurować do wykonywania złożonych operacji przy bardzo niewielkiej interwencji CPU, oszczędzając zarówno cenną pamięć programu, jak i czas wykonania. W przypadku wykrywania zdarzeń sprzętowych ważne jest, aby najpierw wykryć zdarzenie, a następnie przełączyć sterowanie na żądaną procedurę obsługi przerwania (ISR).
W takich sytuacjach szybkość procesora nie jest jedynym decydującym czynnikiem. Jest to kwestia tego, jak długo, w kategoriach cykli, trwa odpowiedź na przerwanie, uruchomienie ISR i powrót. Jak pokazuje poniższy przykład, urządzenia 8-bitowe mogą być bardziej wydajne w obsłudze sprzętowych akcji w pobliżu.
Rozważmy otrzymanie jednego bajtu na SPI, użycie przerwania do jego wykrycia, a następnie uruchomienie prostej procedury ISR w celu odczytania bajtu z peryferium SPI i zapisania go w SRAM. Używając tego scenariusza, tabela 2 przedstawia porównania pomiędzy 8-bitowym urządzeniem AVR firmy Atmel a 32-bitowym MCU firmy Atmel ARM Cortex M0+. Obliczone na podstawie dostępnych informacji, wyniki są oparte na minimalnych implementacjach. Inżynierowie powinni jednak sprawdzić swoje własne aplikacje, ponieważ detekcja przerwania i powrót z przerwania mogą zająć więcej cykli niż pokazano w tabeli. Wymaganie 12 cykli w porównaniu z 33 cyklami równa się posiadaniu teoretycznej maksymalnej przepustowości SPI wynoszącej 1,67 MB/s dla 8-bitowego CPU i przepustowości 606 kB/s dla 32-bitowego CPU przy pracy z częstotliwością 20 MHz.
Stopień przetwarzania liczbowego może mieć również wpływ na stos i wymaganą pamięć. Zastosowanie algorytmu Fibonacciego jest jedną ze szczególnie dobrych metod testowania wymagań pamięciowych. Ponieważ używa on tylko zmiennej lokalnej, wszystko musi być wypchnięte na stos.
Przy porównaniu 8-bitowego AVR z 32-bitowym urządzeniem ARM opartym na CM0+ i zastosowaniu rekurencyjnego 15-stopniowego algorytmu Fibonacciego, AVR używa w sumie 70 bajtów stosu, w tym 30 na stos powrotny (15 wywołań w głąb). Urządzenie oparte na ARM używa 192 bajtów (60 powinno być stosem powrotnym). Oznacza to, że CSTACK jest ponad trzykrotnie większy niż w przypadku rozwiązania 8-bitowego. W typowym kodzie C, więcej zmiennych na stosie często przychodzi w spakowanym formacie, więc jest to skrajny narożnik. Jednak stwierdzenie, że do tej samej 8-bitowej aplikacji na urządzeniu 32-bitowym (w porównaniu z natywnym 8-bitowym) potrzeba od 1,5 do 3 razy więcej pamięci SRAM, jest uczciwym szacunkiem.
Zużycie energii
Żaden artykuł o MCU nie byłby kompletny bez zbadania statycznego zużycia energii. Sam ten czynnik może być kluczowym czynnikiem przy wyborze pomiędzy urządzeniem 8- i 32-bitowym, zwłaszcza w przypadku aplikacji zasilanych z baterii. Tabela 3 ilustruje różnice w poborze mocy między urządzeniami 8- i 32-bitowymi zarówno w trybie aktywnym, jak i statycznym.
Agresywne technologie produkcji zwiększają prąd upływu tranzystora, który z grubsza podwaja się z każdą generacją procesu i jest proporcjonalny do liczby bramek. Prąd upływu wzrasta wykładniczo w wyższych temperaturach, co można łatwo przeoczyć przy projektowaniu konstrukcji konsumenckich. Telefony komórkowe i osobiste odtwarzacze multimedialne są przenoszone wszędzie, a jak wszyscy się przekonaliśmy, temperatury doświadczane latem wewnątrz samochodu mogą łatwo przekroczyć 40°C.
Ilość czasu, jaki mikrokontroler spędzi w trybie aktywnym w porównaniu z trybem statycznym, przyczynia się znacząco do ogólnego budżetu mocy aplikacji.
Naturalnie, stosunek pomiędzy trybami aktywnymi i statycznymi będzie się różnił w zależności od wymagań aplikacji. Biorąc pod uwagę poprzedni przykład przerwania SPI (tabela 2, ponownie) i zakładając przepustowość danych SPI na poziomie 80 kb/s, 8-bitowy procesor spędzi 1,2% czasu w trybie aktywnym w porównaniu do 32-bitowego, który spędzi w trybie aktywnym 3,3% (tabela 4).
Podsumowanie
Kontemplowanie, czy w przyszłym projekcie użyć mikrokontrolera 8- czy 32-bitowego, może dotyczyć aplikacji Internetu rzeczy (IoT). Sposób, w jaki IoT faktycznie nabierze kształtu, wywołuje wiele dyskusji, ale z pewnością będzie wyzwaniem dla inżynierów, aby dokonać szczegółowej oceny wymagań dotyczących MCU. Łączność bezprzewodowa, zwłaszcza ZigBee, będzie również istotnym elementem, ale to nie oznacza automatycznie, że będzie wymagać urządzenia o większej mocy.
|
Pobierz ten artykuł w formacie .PDF Ten typ pliku zawiera grafikę o wysokiej rozdzielczości i schematy, jeśli dotyczy. |
Liczba dostępnych produktów z mikrokontrolerami 8-bitowymi zaspokaja potrzebę niskiego poziomu przetwarzania i łączności bezprzewodowej. Jednym z takich przykładów jest seria ATmegaRFR2 firmy Atmel, która zapewnia zgodne z IEEE 802.15.4, jednoukładowe, bezprzewodowe rozwiązanie mikrokontrolerowe pracujące w paśmie 2,4 GHz, które nadaje się do zasilanych bateryjnie, tanich projektów IoT.
Ingar Fredriksen, dyrektor ds. marketingu MCU firmy Atmel w regionie EMEA, mieszka w Trondheim, Normay. Otrzymał tytuł licencjata w dziedzinie inżynierii elektrycznej w Trodheim University College.
Paal Kastnes, inżynier w zespole MCU Applications, specjalizujący się w szkoleniu pracowników firmy Atmel oraz klientów w zakresie używania mikrokontrolerów i narzędzi firmy Atmel, również pracuje w Trondheim. Uzyskał tytuł licencjata w dziedzinie inżynierii elektrycznej w Trondheim University College.