Elektroda.pl
Elektroda.pl
X
IGE-XAOIGE-XAO
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Poradnik: Mikroprocesor czy mikrokontroler - jaki wybór jest dobry?

ghost666 10 Sty 2020 18:02 2055 11
  • Poradnik: Mikroprocesor czy mikrokontroler - jaki wybór jest dobry?
    Mikroprocesor (MPU) czy mikrokontroler (MCU)? To pytanie stawia sobie wielu projektantów systemów elektronicznych. W poniższym artykule przyjrzymy się, jakie czynniki należy wziąć pod uwagę przy wyborze odpowiedniego urządzenia przetwarzającego do naszego następnego projektu.

    Wybór odpowiedniego urządzenia, na którym ma zostać oparty nowy projekt, może być zniechęcający dla wielu projektantów. Potrzeba wybrać element, który zapewni właściwą równowagę ceny, wydajności i zużycia energii - ma to bardzo wiele implikacji. Po pierwsze, należy wziąć pod uwagę natychmiastowe względy technologiczne dotyczące projektu, który można wdrożyć, ale jeśli urządzenie - czy to mikrokontroler, czy mikroprocesor stanie się podstawą do stworzenia platformy dla szeregu nowych produktów, wówczas decyzja może mieć długotrwałe konsekwencje dla firmy.

    Po pierwsze, rozważmy niektóre podstawowe różnice między MCU i MPU. Zazwyczaj mikrokontroler wykorzystuje wbudowaną pamięć Flash do przechowywania i wykonywania programu. Przechowywanie programu w ten sposób oznacza, że układ taki bardzo szybko uruchamia się i może wykonywać kod niemalże od podania zasilania. Jedynym praktycznym ograniczeniem korzystania z pamięci wbudowanej jest to, że całkowita dostępna pamięć jest skończona i ograniczona specyfikacją danego MCU. Większość urządzeń wyposażonych jest w pamięć Flash, układy dostępne na na rynku mają maksymalnie 2 MB pamięci programu i, w zależności od aplikacji, może to okazać się czynnikiem ograniczającym ich stosowanie. Jednostki MPU nie mają z kolei pamięci w ten sposób ograniczonej. Mikroprocesory używają pamięci zewnętrznej do przechowywania programów i danych. Program jest zwykle przechowywany w nieulotnej pamięci, takiej jak NAND lub szeregowy układ Flash; przy uruchomieniu program jest ładowany do zewnętrznej pamięci DRAM, a następnie rozpoczyna się jego wykonywanie. Oznacza to, że mikroprocesor nie uruchomi się tak szybko jak mikrokontroler, ale ilość pamięci DRAM i nieulotnej (pamięć programu i danych), którą można podłączyć do procesora, wynosić może nawet setki mega-, a nawet gigabajtów. Kolejną różnicą jest sposób zasilania. Dzięki wbudowaniu własnego zasilacza mikrokontroler potrzebuje na ogół tylko jednej szyny zasilającej. Z kolei mikroprocesor wymaga zazwyczaj kilku szyn zasilania o zróżnicowanym napięciu – osobno dla rdzenia układu, interfejsu DDR itp. Projektant systemu musi zastosować odpowiednio rozbudowany system zasilania, korzystający z dodatkowych układów scalonych, stabilizatorów liniowych i przetwornic impulsowych (problem nie leży tylko w samej ilości domen zasilania i konieczności stabilizacji różnych napięć z różną wydajnością prądową etc. Problematyczne jest także np. uruchamianie systemu, z uwagi na konieczność załączania odpowiednich domen zasilania w ściśle zdefiniowanej kolejności – przyp. red.).

    Z perspektywy aplikacji niektóre aspekty specyfikacji projektu mogą w jasny sposób wpływać na wybór konkretnego rozwiązania. Na przykład, czy liczba kanałów dla interfejsów do podłączania peryferii jest tak duża, że nie może zostać pokryta mikrokontrolerem? A może specyfikacja marketingowa określa jakieś funkcje interfejsu użytkownika, które nie będą możliwe do realizacji w przypadku mikrokontrolera, ponieważ ten nie posiada wystarczającej ilości pamięci wbudowanej w układ lub nie ma wymaganej wydajności?

    Podczas rozpoczynania projektu, wiedząc o tym, że istnieje duże prawdopodobieństwo, że będzie wiele odmian produktu, łatwiej jest podjąć decyzję dotyczącą wyboru konkretnego układu, czy też całej platformy. W takim przypadku jest bardzo możliwe, że preferowane będzie właśnie podejście oparte na platformie. Oznaczałoby to więcej „rezerwy” pod względem mocy obliczeniowej i możliwości interfejsów, w celu uwzględnienia przyszłych aktualizacji systemu i kolejnych jego wersji.

    Trudnym do określenia atrybutem jest wymagana wydajność przetwarzania, jakiej może wymagać dany projekt. Moc obliczeniowa mierzona jest najczęściej w Dhrystone MIPSach (DMIPS). Pomiar taki pomaga w kwantyfikacji tych kryteriów. Na przykład mikrokontroler oparty na rdzeniu ARM Cortex-M4, taki jak np. SAM4 firmy Atmel, ma około 150 DMIPS, podczas gdy procesor aplikacyjny z rdzeniem ARM Cortex-A5, taki jak SAMA5D3 także firmy Atmel, może dostarczyć nawet do 850 DMIPS. Jednym ze sposobów oszacowania wymaganej ilości DMIPS naszego układu, jest spojrzenie na te części aplikacji, które wymagać mogą największej wydajności przetwarzania. Uruchamianie pełnego systemu operacyjnego, takiego jak Linux, Android lub Windows CE, wymaga do poprawnego działania co najmniej 300..400 DMIPS. W wielu aplikacjach wystarczający jest jednak prosty RTOS, dla którego około 50 DMIPS to już więcej niż wystarczająca wartość. Korzystanie z RTOS ma również tę zaletę, że wymaga niewielkiej ilości pamięci; jądro o wielkości zaledwie kilku KB jest typowe. Dodatkowo, pełny system operacyjny wymaga jednostki zarządzającej pamięcią (MMU) do uruchomienia; to z kolei określa rodzaj rdzenia procesora, który może być używany, i wymaga większej wydajności od procesora.

    Aby uruchamiać aplikacje, które są wystarczająco wymagające co do wydajności obliczeniowej, należy dodatkowo zwiększyć wymaganą liczbę DMIPS naszego układu – potrzebne jest wtedy nie tylko uruchomienie samego systemu operacyjnego, ale także złożonej obliczeniowo aplikacji. Im bardziej aplikacja jest oparta na przeliczaniu danych, tym bardziej prawdopodobne jest, że wymagany jest mikroprocesor.

    Niezależnie od tego, czy dana aplikacja jest przeznaczona dla elektroniki użytkowej czy automatyki przemysłowej, interfejs użytkownika (UI) może być poważnym wyzwaniem i czynnikiem mocno wpływającym na dobór układu. Jako konsumenci przyzwyczailiśmy się do komfortu korzystania z kolorowych i intuicyjnych interfejsów graficznych. Aplikacje przemysłowe coraz częściej korzystają z takiej samej metody interakcji z operatorem, chociaż środowisko operacyjne może ograniczyć to, na ile jest to realnie uzasadnione. W przypadku interfejsu użytkownika jest bardzo wiele czynników, które trzeba uwzględnić. Po pierwsze, wymagany jest pewien narzut przetwarzania. W przypadku biblioteki interfejsu użytkownika, takiej jak na przykład Qt, która jest powszechnie używana tak na Linuksie, jak i na innych systemach operacyjnych, może wystarczyć narzut w wysokości 80-100 DMIPS, ale istnieją o wiele bardziej wymagające biblioteki czy interfejsy. Drugi czynnik dotyczy złożoności samego interfejsu użytkownika. Im więcej znajdzie się tam animacji, efektów, treści multimedialnych, im więcej zmian zostanie zastosowanych do wyświetlanego obrazu, tym więcej mocy obliczeniowej i pamięci potrzebne jest w systemie, który uruchamiać ma to UI. Wymagania te rosną wraz z rozdzielczością obrazu, dlatego dla aplikacji zaprojektowanych tak, aby były zorientowane na zaawansowany interfejs użytkownika, mikroprocesor o wiele lepiej się sprawdzi. Z drugiej strony mikrokontroler może wyświetlać bez problemu prostszy interfejs użytkownika z pseudostatycznymi obrazami na ekranie o niższej rozdzielczości. Kolejnym argumentem przemawiającym za wykorzystaniem mikroprocesora jest to, że najczęściej są one wyposażone we wbudowany kontroler TFT LCD. Bardzo niewiele mikrokontrolerów ma tego rodzaju wbudowane peryferia. Kontroler TFT LCD i niektóre inne zewnętrzne elementy sterownika należy dodać zewnętrznie. Tak więc, chociaż jest to możliwe do osiągnięcia za pomocą MCU, projektant musi spojrzeć na ogólne zestawienie komponentów potrzebnych do realizacji danego interfejsu. Dodatkowo, jakkolwiek niektóre mikrokontrolery dostępne są z wbudowanymi kontrolerami TFT LCD, to wciąż musi on posiadać wystarczającą ilość wbudowanej pamięci SRAM do obsługi takiego wyświetlacza. Na przykład 16-kolorowy format QVGA 320 x 240 wymaga 150 kB SRAM do działania i odświeżania wyświetlacza. Jest to dość duża ilość pamięci do poświęcenia; oznacza to, że może być wymagana dodatkowa pamięć i dalsze dodawanie elementów do listy dla wypełnianie luki względem MPU. Bardziej złożone i zaawansowane graficzne interfejsy użytkownika, szczególnie przy ekranach większych niż 4,3 cala, wymagają już mikroprocesora. Jak widać, MPU dominują, jeśli chodzi o uruchamianie interfejsu użytkownika na kolorowym ekranie TFT, ale MCU to królowie wykorzystania segmentowego lub punktowego wyświetlacza LCD i innych ekranów z interfejsami szeregowymi.

    Z punktu widzenia łączności, sprawdza się większość mikrokontrolerów i mikroprocesorów z popularnymi interfejsami peryferyjnymi. Jednakże peryferyjne urządzenia komunikacyjne o wysokiej przepustowości, takie jak High Speed USB 2.0, wyposażenie układu w wiele portów Ethernet 10/100 lub też nawet gigabitowy Ethernet, są zwykle domeną mikroprocesorów, ponieważ są one w stanie lepiej obsługiwać i przetwarzać duże ilości danych. Kluczowe pytanie brzmi, czy liczba kanałów i przepustowość jest wystarczająca do obsługi ruchu danych. W zależności od używanych protokołów komunikacyjnych należy sprawdzić wpływ ich wykorzystania na ilość potrzebnego kodu programu, przy użyciu wybranych stosów do ich obsługi. Aplikacje wymagające szybkiej łączności, szczególnie w połączeniu ze stosami opartymi na systemie operacyjnym, będą wymagały projektu opartego na mikroprocesorze.

    Kolejnym kluczowym aspektem, który będzie decydował o wyborze między MCU a MPU, jest konieczność deterministycznego sterowania aplikacji w czasie rzeczywistym. Ze względu na rdzeń zastosowany w mikrokontrolerze, wbudowaną pamięć Flash i łatwość zastosowania systemów RTOS albo oprogramowanie układu w gołym C, mikrokontroler zdecydowanie lepiej nadaje się do systemów czasu rzeczywistego, gdzie determinizm aplikacji jest krytyczny.

    Ostatnim punktem do rozważenia jest zużycie energii podczas pracy. Podczas gdy mikroprocesory mają tryby niskiego poboru mocy, nie ma ich tak wiele i nie są to tak niskie pobory, jak te, które oferują nawet typowe mikrokontrolery. Dodatkowo, z uwagi na konieczność podłączenia dużej ilości zewnętrznych elementów do mikroprocesora, przełączenie go w tryb niskiego poboru mocy może być nieco bardziej skomplikowane niż w przypadku MCU. Ponadto rzeczywiste zużycie prądu przez mikrokontroler jest mniejsze niż w przypadku mikroprocesora, w trybie niskiego poboru mocy. Wynika to z obecności dodatkowych układów, takich jak na przykład zewnętrzna pamięć SRAM, która służy do przechowania wartości rejestrów. Zwiększa to zapotrzebowanie na prąd układu o współczynnik od 10 do 100 razy. Dokładna jego wartość jest bezpośrednio związana z ilością pamięci RAM wykorzystywanej przez system operacyjny i musi być zasilana, aby móc natychmiast wznowić działanie systemu. Decyzje projektowe dotyczą dokładnej metody usypiania mikroprocesora czy mikrokontrolera są bardzo liczne i ściśle wiążą się z potrzebną wydajnością systemu, możliwościami i budżetem.

    Mówiąc ogólnie, mikrokontrolery są zwykle stosowane w rozwiązaniach zoptymalizowanych pod względem kosztów, w których niezbędna jest ścisła kontrola listy i kosztów elementów i oszczędność energii. Mikroprocesory z kolei są zwykle używane do bogatych funkcjonalnie i wydajnych aplikacji. Mikrokontrolery są zwykle używane w aplikacjach o bardzo niskim zużyciu energii, takich jak piloty zdalnego sterowania, elektryczne urządzenia konsumenckie i inteligentne liczniki, w których nacisk kładziony jest głównie na żywotność baterii i brak interakcji z interfejsem użytkownika. Są również stosowane tam, gdzie potrzebne jest wysoce deterministyczne zachowanie systemu. Mikroprocesory są idealne dla aplikacji przemysłowych i konsumenckich opartych na systemie operacyjnym, które mogą wymagać intensywnych obliczeń, a także wymagają wielu szybkich połączeń lub bogatego interfejsu użytkownika.

    Gdy dokonamy wyboru pomiędzy mikroprocesorem a mikrokontrolerem, musimy jeszcze dokonać wyboru dostawcy układu. Zaleca się wybrać firmę, która oferuje wysoce kompatybilne produkty w zakresie obu segmentów – MCU i MPU. Pozwala to na łatwe migrowanie tak w górę, jak i w dół naszych wymagań przy jednoczesnym maksymalizowaniu ponownego wykorzystania oprogramowania i schematów, zapewnia redukcję kosztów projektowania i przyspieszenie wprowadzania nowych urządzeń na rynek.

    Źródło: https://www.arrow.com/en/research-and-events/articles/mpu-v-mcu

    Fajne! Ranking DIY
    Potrafisz napisać podobny artykuł? Wyślij do mnie a otrzymasz kartę SD 64GB.
    O autorze
    ghost666
    Tłumacz Redaktor
    Offline 
    Fizyk z wykształcenia. Po zrobieniu doktoratu i dwóch latach pracy na uczelni, przeszedł do sektora prywatnego, gdzie zajmuje się projektowaniem urządzeń elektronicznych i programowaniem. Od 2003 roku na forum Elektroda.pl, od 2008 roku członek zespołu redakcyjnego.
    ghost666 napisał 9501 postów o ocenie 7547, pomógł 157 razy. Mieszka w mieście Warszawa. Jest z nami od 2003 roku.
  • IGE-XAOIGE-XAO
  • #2
    fotomh-s
    Poziom 21  
    ghost666 napisał:
    Jedynym praktycznym ograniczeniem korzystania z pamięci wbudowanej jest to, że całkowita dostępna pamięć jest skończona i ograniczona specyfikacją danego MCU.

    ghost666 napisał:
    Mikroprocesory używają pamięci zewnętrznej do przechowywania programów i danych.

    Istnieją przecież mikrokontrolery z wbudowanym kontrolerem zewnętrznej pamięci. STM chyba takie robi. Działa to na tej samej zasadzie co w klasycznych mikroprocesorach, szyny danych, adresowa i kontrolna.
  • IGE-XAOIGE-XAO
  • #3
    khoam
    Specjalista - ESP32, ESP8266
    ghost666 napisał:
    to wciąż musi on [MCU] posiadać wystarczającą ilość wbudowanej pamięci SRAM do obsługi takiego wyświetlacza. Na przykład 16-kolorowy format QVGA 320 x 240 wymaga 150 kB SRAM do działania i odświeżania wyświetlacza. Jest to dość duża ilość pamięci do poświęcenia; oznacza to, że może być wymagana dodatkowa pamięć i dalsze dodawanie elementów do listy dla wypełnianie luki względem MPU.

    Nie wiem, czy aż taka duża ilość pamięci skoro są na rynku MCU 32-bitowe, które mają wbudowane 520 KB SRAM.

    ghost666 napisał:
    Mikrokontrolery są zwykle używane w aplikacjach o bardzo niskim zużyciu energii, takich jak piloty zdalnego sterowania, elektryczne urządzenia konsumenckie i inteligentne liczniki, w których nacisk kładziony jest głównie na żywotność baterii i brak interakcji z interfejsem użytkownika. Są również stosowane tam, gdzie potrzebne jest wysoce deterministyczne zachowanie systemu.

    "Wysoce deterministyczne zachowanie systemu" lub aplikacji w pierwszej kolejności zależy od szeroko rozumianej jakości oprogramowania, a nie od tego, czy użyty jest MPU czy MCU. To taki dziwny pseudo-inżynierski kanon: "jak wybierzesz MCU o nazwie BestInTheWorld32, to system będzie bardziej stabilny i bezpieczny niż jak wybierzesz inny MCU". To z żądanego zakresu funkcjonalności oprogramowania powinien wynikać wybór MCU/MPU, a nie odwrotnie. Boeingi dalej będą spadały z powodu kiepskiego softu, niezależnie od użytego hardware.

    Co do "braku interakcji z interfejsem użytkownika" w wypadku MCU, to Autor (ten oryginalny) artykułu zapewne jeszcze nie słyszał o IoT.
  • #4
    piotr_go
    Poziom 28  
    Są jeszcze w dzisiejszych czasach mikroprocesory?
    Dziś każdy procek ma wbudowaną pamięć (cache, można uruchomić w nim program bez pamięci zewnętrznej), proste IO czy bardziej rozbudowane interfejsy.
    Od mikrokontrolerów różni się zazwyczaj tylko... ̶p̶o̶b̶o̶r̶e̶m̶ ̶p̶r̶ą̶d̶u̶ ̶c̶z̶y̶ ̶s̶t̶o̶p̶n̶i̶e̶m̶ ̶s̶k̶o̶m̶p̶l̶i̶k̶o̶w̶a̶n̶i̶a̶ hmmmm miałem tak napisać ale są mikrokontrolery bardziej skomplikowane niż niektóre x86.

    Ja bym sobie odpuścił zastanawianie się "Czy to mikroprocesor, czy mikrokontroler?" Naprawdę nie ma sensu. Granica się zatarła.

    Aaaaa
    ghost666 napisał:
    Na przykład 16-kolorowy format QVGA 320 x 240 wymaga 150 kB SRAM

    Albo 16bit, albo ~38KB.
  • #6
    fotomh-s
    Poziom 21  
    Albo syntezowane na miękko na FPGA lub jako część SOC.
    A tak na poważnie to są cały czas stosowane np. w PCtach albo sektorze mobile. Raczej jest im dane działać w sektorach nieco innych niż klasyczny embedded.
  • #7
    Atlantis86
    Poziom 19  
    piotr_go napisał:
    Są jeszcze w dzisiejszych czasach mikroprocesory?


    Oczywiście, że są. Po pierwsze kilka firm ciągle produkuje klasyczne CPU sprzed kilkudziesięciu lat, w nieco nowszych wersjach CMOS. Dzięki temu ciągle można kupić nowe wersje 6502 albo Z80, różniące się od klasycznych poborem mocy, obciążalnością wyjść i maksymalnym taktowaniem.
    Po drugie istnieją przecież układy ARM, MIPS albo RISC-V z wyprowadzoną magistralą systemową, projektowane z myślą o korzystaniu z zewnętrznej pamięci flash i RAM.
  • #8
    piotr_go
    Poziom 28  
    Atlantis86 napisał:
    kilka firm ciągle produkuje klasyczne CPU sprzed kilkudziesięciu lat, w nieco nowszych wersjach CMOS. Dzięki temu ciągle można kupić nowe wersje 6502 albo Z80

    Układów z przed kilkudziesięciu lat nie zaliczył bym do dzisiejszych czasów.
    Mam nawet taki Z80 z 2019. :)

    Atlantis86 napisał:
    Po drugie istnieją przecież układy ARM, MIPS albo RISC-V z wyprowadzoną magistralą systemową, projektowane z myślą o korzystaniu z zewnętrznej pamięci flash i RAM.

    Ale to już są mikrokontrolery/SOCe/APU... czy inne cuda.
  • #9
    tronics
    Poziom 37  
    No dobra, ale rzekomo gdzie jest jakaś historyczna granica? 68k było w wersji zarówno mikroprocesora z cache (68020 i wyżej iirc), jak i multiprotocol processor (68302) z wbudowanym ram i peryferiami, wreszcie jako mikrokontroler (np. 68332 - też z ram, timerami i/o i niewiele więcej). Gdzie jest ta jasno określona różnica? Zapewne i palmtopowe układy sprzed 2 dekad mogły nieużywane interfejsy traktować jako cyfrowe i/o ... tak jak robią to obecnie tabletowe i sbc SoC. Taki MCP8245 to niby procesor, a ma i2c, uart, pci. Myślę, że te rozróżnienie było iluzoryczne już dawno temu i od dawna służy tylko określeniu "dedykowanego targetu" ;) Bo i co stoi na przeszkodzie by mikrokontroler z wyprowadzonymi magistralami systemowymi nie był sercem układu mikroprocesorowego? No nic. A co stoi na przeszkodzie by mikroprocesor sterował falownikiem gdy nadzór oraz generowanie pwm i tak robi fpga (acopos 1045 na przykład). No właśnie. Pamiętam jak swego czasu naprawiałem urządzenie gdzie układ nie miał w zasadzie żadnych peryferiów, wszystko miał na zewnątrz z wyjątkiem rom i ram, był reklamowany jako "single chip computer" i de facto zaliczany do mikrokontrolerów.
  • #10
    Atlantis86
    Poziom 19  
    tronics napisał:
    Bo i co stoi na przeszkodzie by mikrokontroler z wyprowadzonymi magistralami systemowymi nie był sercem układu mikroprocesorowego?


    Często stoi architektura harwardzka w połączeniu z dekoderem adresów na stałe zaszytym w krzemie. Rozdzielone przestrzenie adresowe dla programu i danych właściwie uniemożliwiają używanie mikrokontrolera w roli uniwersalnego komputera, bo nie da się załadować kodu do RAM-u, a potem go z niego wykonać.

    Dlatego właśnie komputery i konsole "retro" robione na AVR-ach opierają się na kombinowaniu. Albo mamy bootloader ładujący program z nośnika (np. karty SD) do flasha, albo interpreter BASIC-a lub jakąś prostą maszynę wirtualną.

    W przypadku takich układów jak ESP8266 albo ESP32 uruchamianie kodu maszynowego z RAM-u jest już możliwe.
  • #11
    tronics
    Poziom 37  
    Cytat:
    Często stoi architektura harwardzka w połączeniu z dekoderem adresów na stałe zaszytym w krzemie

    Eee, no fajnie, to teraz pytanie - czy w L1I mogę trzymać dane? Czy w L1D mogę trzymać instrukcje? ;) Archaiczne podziały są (znów) od dłuuugiego czasu takie mało ciekawe. Na poziomie blisko samego potoku wykonawczego akurat mamy harvarda tak czy inaczej. A jeśli chodzi o przestrzenie adresowe to megaAVR 0-series ma jednolitą. Nie zmienia to faktu, że z tego co pamiętam nadal nie da się odpalić kodu z RAM (czy EEPROM). Z kolei SAMD21 ma również jednolitą przestrzeń, ale architektura to jest zasadniczo harvard (Cortex M0+) czy bardziej słusznie modifed harvard - jak i połowa cortex m - a można kod przenieść do RAM i z niego wykonać. Zatem w swoich wywodach niech kolega nie ogranicza się do AVR8 :)
  • #12
    khoam
    Specjalista - ESP32, ESP8266
    Atlantis86 napisał:
    W przypadku takich układów jak ESP8266 albo ESP32 uruchamianie kodu maszynowego z RAM-u jest już możliwe.

    Raczej należałoby napisać, że chodzi o Xtensa i o procesor typu RISC.