Czym różnią się 8-bitowe mikrokontrolery od 32-bitowych mikrokontrolerów, jeśli chodzi o ich programowanie

19

Tak, w tej chwili mamy na świecie 8-bitowy, 16-bitowy i 32-bitowy mikrokontroler. Wszystkie są często używane. Czym różni się programowanie mikrokontrolerów 8-bitowych i 16-bitowych? Mam na myśli, czy to wymaga innej techniki lub umiejętności? Weźmy na przykład mikroczip. Jakich nowych rzeczy musi się nauczyć osoba, która chce przejść z 8-bitowych mikrokontrolerów do 32-bitowych mikrokontrolerów?

quantum231
źródło
Nie. Z pewnością istnieją różne obawy, ale w dużej mierze dotyczą one poziomu szczegółowości specyficznej dla urządzenia. Na przykład, czy dozwolony jest nieprzystosowany dostęp do słów? (Na ARM tak nie jest - jeszcze na x86 jest). To pytanie nie jest wystarczająco szczegółowe.
Chris Stratton
Wow, dzięki za odpowiedzi. Istnieją więc bardzo ważne różnice, które musimy wziąć pod uwagę przy programowaniu procesorów 32-bitowych w porównaniu z procesorami 8-bitowymi. Miałem tu na myśli C, ponieważ myślę, że większość ludzi nie zagłębia się w Zgromadzenie w celu programowania z powodów, które wszyscy bardzo dobrze znamy. Dzięki za szczegółowe odpowiedzi, naprawdę to doceniam.
quantum231
Z 32-bitowymi komputerami Uc jest o wiele więcej opcji i DUŻO więcej rejestrów, które musisz poprawnie wykonać. Myślę, że to zależy od tego, co robisz. To powiedziawszy, w dzisiejszych czasach można uzyskać płytę programistyczną, kompilator, debugger, IDE za około 50 USD. Wracając do dnia, który kosztowałby blisko 1000 USD.

Odpowiedzi:

33

Ogólnie rzecz biorąc, przejście z mikrokontrolerów od 8 do 16 do 32 bitów oznacza, że ​​będziesz mieć mniej ograniczeń zasobów, w szczególności pamięci i szerokości rejestrów używanych do wykonywania operacji arytmetycznych i logicznych. 8, 16 i 32-bitowe monikery ogólnie odnoszą się zarówno do wielkości wewnętrznych i zewnętrznych magistral danych, jak również do wielkości rejestru wewnętrznego (rejestrów) wykorzystywanego do operacji arytmetycznych i logicznych (kiedyś był to jeden lub dwa nazywane akumulatorami , teraz zwykle są zarejestrowane banki 16 lub 32).

Rozmiary portów I / O będą również generalnie odpowiadały rozmiarom magistrali danych, więc 8-bitowe mikro będzie miało 8-bitowe porty, 16-bitowe będzie miało 16-bitowe porty itp.

Pomimo 8-bitowej magistrali danych, wiele 8-bitowych mikrokontrolerów ma 16-bitową magistralę adresową i może adresować 2 ^ 16 lub 64 KB bajtów (co nie znaczy, że mają one gdziekolwiek zaimplementowane). Ale niektóre 8-bitowe mikroskopy, takie jak niskiej jakości PIC, mogą mieć bardzo ograniczoną przestrzeń RAM (np. 96 bajtów na PIC16).

Aby obejść ich ograniczony schemat adresowania, niektóre 8-bitowe mikroskopy używają stronicowania, w którym zawartość rejestru stron określa jeden z kilku banków pamięci do użycia. Zwykle dostępna będzie pewna dostępna pamięć RAM, bez względu na ustawiony rejestr stron.

16-bitowy mikrokontroler jest zwykle ograniczony do 64 KB pamięci, ale może również użyć technik stronicowania, aby obejść ten problem. 32-bitowe mikrokontrolery oczywiście nie mają takich ograniczeń i mogą adresować do 4 GB pamięci.

Wraz z różnymi rozmiarami pamięci jest rozmiar stosu. W dolnych mikrach można to zaimplementować w specjalnym obszarze pamięci i być bardzo małe (wiele PIC16 ma 8-poziomowy stos wywołań głębokich). W 16-bitowych i 32-bitowych mikrach stos będzie zwykle ogólnie RAM i będzie ograniczony tylko przez rozmiar RAM.

Istnieją również ogromne różnice w ilości pamięci - zarówno programowej, jak i RAM - zaimplementowanej na różnych urządzeniach. 8-bitowe mikroskopy mogą mieć tylko kilkaset bajtów pamięci RAM i kilka tysięcy bajtów pamięci programu (lub znacznie mniej - na przykład PIC10F320 ma tylko 256 14-bitowych słów pamięci flash i 64 bajty pamięci RAM). 16-bitowe mikroskopy mogą mieć kilka tysięcy bajtów pamięci RAM i dziesiątki tysięcy bajtów pamięci programu. 32-bitowe mikroskopy często mają ponad 64 KB pamięci RAM, a może 1/2 MB lub więcej pamięci programu (PIC32MZ2048 ma 2 MB pamięci flash i 512 KB pamięci RAM; nowo wydany PIC32MZ2064DAH176, zoptymalizowany pod kątem grafiki, ma 2 MB pamięci flash i aż 32 MB pamięci RAM na chipie).

Jeśli programujesz w języku asemblera, ograniczenia wielkości rejestru będą bardzo widoczne, na przykład dodanie dwóch liczb 32-bitowych jest obowiązkowe dla 8-bitowego mikrokontrolera, ale banalne dla 32-bitowego. Jeśli programujesz w C, będzie to w dużej mierze przezroczyste, ale oczywiście skompilowany kod będzie znacznie większy dla 8-gorzkiego.

Powiedziałem, że w dużej mierze przejrzyste, ponieważ rozmiar różnych typów danych C może być różny dla różnych rozmiarów mikro; na przykład kompilator ukierunkowany na 8 lub 16-bitowy mikro może używać „int”, co oznacza 16-bitową zmienną ze znakiem, a na 32-bitowej mikro to 32-bitowa zmienna. Dlatego wiele programów używa #defines, aby wyraźnie powiedzieć, jaki jest pożądany rozmiar, np. „UINT16” dla 16-bitowej zmiennej bez znaku.

Jeśli programujesz w C, największy wpływ będzie miał rozmiar twoich zmiennych. Na przykład, jeśli wiesz, że zmienna zawsze będzie mniejsza niż 256 (lub w zakresie od -128 do 127, jeśli jest podpisana), powinieneś użyć 8-bitowego (char lub char bez znaku) na 8-bitowej mikro (np. PIC16 ), ponieważ użycie większego rozmiaru będzie bardzo nieefektywne. Podobnie ponownie 16-bitowe zmienne na 16-bitowej mikro (np. PIC24). Jeśli używasz 32-bitowej mikro (PIC32), to tak naprawdę nie ma znaczenia, ponieważ zestaw instrukcji MIPS zawiera instrukcje bajtów, słów i podwójnych słów. Jednak na niektórych 32-bitowych mikrach, jeśli nie mają takich instrukcji, manipulowanie zmienną 8-bitową może być mniej wydajne niż zmiennej 32-bitowej z powodu maskowania.

Jak zauważył członek forum vsz, w systemach, w których masz zmienną, która jest większa niż domyślny rozmiar rejestru (np. 16-bitowa zmienna na 8-bitowym mikro) i ta zmienna jest dzielona między dwa wątki lub między wątkiem podstawowym i obsługi przerwań, należy wykonać dowolną operację (w tym po prostu odczyt) na zmiennej atomowej , to znaczy, że wydaje się, że jest wykonywana jako jedna instrukcja. Nazywa się to sekcją krytyczną. Standardowym sposobem na złagodzenie tego jest otoczenie sekcji krytycznej parą wyłączania / włączania przerwań.

Przechodząc od systemów 32-bitowych do 16-bitowych lub 16-bitowych do 8-bitowych, wszelkie operacje na zmiennych tego typu, które są teraz większe niż domyślny rozmiar rejestru (ale nie były wcześniej), należy uznać za krytyczne Sekcja.

Inną główną różnicą między poszczególnymi procesorami PIC jest obsługa urządzeń peryferyjnych. Ma to mniej wspólnego z rozmiarem słowa, a więcej z rodzajem i liczbą zasobów przydzielonych na każdym chipie. Ogólnie rzecz biorąc, Microchip starał się, aby programowanie tego samego urządzenia peryferyjnego stosowanego w różnych układach było jak najbardziej podobne (np. Timer0), ale zawsze będą różnice. Korzystanie z bibliotek peryferyjnych w dużym stopniu ukryje te różnice. Ostatnią różnicą jest obsługa przerwań. Ponownie jest tutaj pomoc z bibliotek Microchip.

tcrosley
źródło
Warto zauważyć, że na poziomie asemblera procesory 8-bitowe mają zwykle mniej rejestrów i mniej ortogonalnych instrukcji (AVR jest wyjątkiem bardziej RISCy), co jest konsekwencją ograniczeń projektowych podczas ich opracowywania. Procesory 32-bitowe zwykle są potomkami RISC (RX Renesas, nowoczesny CISC, jest jednym wyjątkiem, a ColdFire Freescale pochodzi z m68k).
Paul A. Clayton
9
Aby nie zaczynać nowej odpowiedzi tylko dla tego dodatku, myślę, że ważne jest, aby dodać, że przejście z 32 bitów na 16 z 16 na 8 może powodować paskudne niespodzianki, ponieważ arytmetyka przestaje być atomowa. Jeśli dodasz dwie 16-bitowe liczby do 8-bitowego mikrokontrolera i użyjesz ich w przerwie, musisz zadbać o to, by były bezpieczne dla wątków, w przeciwnym razie możesz skończyć dodaniem tylko połowy z nich przed wyzwoleniem przerwania, co spowoduje niepoprawna wartość w procedurze obsługi przerwań.
vsz
2
@vsz - Dobra uwaga, zapomniałem o tym. Zasadniczo należy wyłączyć przerwania wokół dowolnego dostępu (w tym po prostu odczytywanie) dowolnej zmiennej lotnej, która jest większa niż domyślny rozmiar rejestru.
tcrosley
1
Czy to prawda, że ​​32-bitowy interfejs użytkownika zwykle ma 32-bitowe interfejsy we / wy? Myślę, że i tak częściej jest to po prostu komunikacja szeregowa.
clabacchio
1
@clabacchio Z mojego doświadczenia wynika, że ​​wszystkie rejestry portów I / O są zdefiniowane jako 32-bitowe, ale czasami 16 górnych bitów 16-31 jest nieużywanych, więc port równoległy to nadal 16 fizycznych pinów. W innych przypadkach, takich jak rejestr RTCC, wykorzystywane są wszystkie 32 bity.
tcrosley,
8

Jedną wspólną różnicą między 8-bitowymi i 32-bitowymi mikrokontrolerami jest to, że 8-bitowe często mają pewien zakres pamięci i przestrzeni we / wy, do których można uzyskać dostęp w pojedynczej instrukcji, niezależnie od kontekstu wykonania, podczas gdy 32-bitowe mikrokontrolery często wymagają sekwencji wielu instrukcji. Na przykład na typowym 8-bitowym mikrokontrolerze (HC05, 8051, PIC-18F itp.) Można zmienić stan bitu portu za pomocą pojedynczej instrukcji. W typowym ARM (32-bitowym), jeśli zawartość rejestru była początkowo nieznana, potrzebna byłaby sekwencja instrukcji składająca się z czterech instrukcji:

    ldr  r0,=GPIOA
    ldrh r1,[r0+GPIO_DDR]
    ior  r1,#64
    strh r1,[r0+GPIO_DDR]

W większości projektów kontroler spędza większość czasu na robieniu innych rzeczy niż ustawianie lub kasowanie poszczególnych bitów We / Wy, więc fakt, że operacje takie jak czyszczenie pin portu wymagają więcej instrukcji często nie mają znaczenia. Z drugiej strony zdarzają się sytuacje, w których kod będzie musiał „huknąć” wiele manipulacji portami, a możliwość robienia takich rzeczy za pomocą jednej instrukcji może okazać się bardzo cenna.

Z drugiej strony 32-bitowe kontrolery są niezmiennie zaprojektowane tak, aby skutecznie uzyskiwać dostęp do wielu rodzajów struktur danych, które mogą być przechowywane w pamięci. Dla porównania, wiele kontrolerów 8-bitowych jest bardzo nieefektywnych w dostępie do struktur danych, które nie są przydzielone statycznie. 32-bitowy kontroler może wykonać w jednej instrukcji dostęp do tablicy, który wymagałby pół tuzina lub więcej instrukcji na typowym 8-bitowym kontrolerze.

supercat
źródło
Zakładam, że miałeś na myśli „bit-bang”. Warto zauważyć, że ARM obsługuje regiony pasma bitowego (w których operacje na słowach są operacjami jednobitowymi), a rozszerzenie specyficzne dla aplikacji MCU dla MIPS zapewnia Atomic Set / Clear Bit w instrukcjach Byte (ASET / ACLR).
Paul A. Clayton
@ PaulA.Clayton: Tak naprawdę nie patrzyłem na MIPS przez ostatnie 20 lat; jeśli chodzi o regiony pasm bitowych, nigdy nie wymyśliłem sposobu na użycie ich w rozsądnie wyglądającym kodzie, a nawet gdybym mógł ich użyć, zapisaliby tylko jedną instrukcję, chyba że ktoś użyłby jakiejś szalonej sztuczki programistycznej, w którym to przypadku mogą zapisać dwa [załadować R0 z parzystym lub nieparzystym adresem w zależności od tego, czy bit powinien zostać ustawiony, czy skasowany, i odpowiednio dostosować przesunięcie instrukcji przechowywania, aby skompensować]. BTW, masz pojęcie, dlaczego region pasma bitowego używa adresów słów?
supercat
@ superupat: Adresowanie słów umożliwia dostęp do regionów pasma bitów z C lub C ++ za pomocą wskaźnika indeksowania ( region_base[offset])
Ben Voigt
@BenVoigt A dlaczego nie można tego zrobić z adresowaniem bajtów? (Być może jednym z możliwych powodów byłoby usunięcie oczekiwań / nadziei, że obsługiwane będą operacje dwu- i czterobitowe.)
Paul A. Clayton
@BenVoigt: Konieczność skalowania liczby bitów czterokrotnie często kosztuje dodatkową instrukcję. Właściwie to, co chciałbym widzieć, zamiast obszaru pasma bitowego, byłby zestaw kilku obszarów, które miałyby ustalone przesunięcie względem „normalnych” dostępów do pamięci, ale określają, że zapisuje w jednym obszarze będzie, jeśli to możliwe, tylko „ustawi” bity, a zapisuje do drugiego, „wyczyści” bity. Gdyby magistrala miała osobne bity sterujące „zapis-włącz-włącz” i „zapis-zeruj-włącz”, można osiągnąć rzeczy, na które pozwala pasmowanie bitów, ale w wielu przypadkach unika się odczytu-modyfikacji-zapisu.
supercat
6

Największą praktyczną różnicą jest ilość dokumentacji, aby w pełni zrozumieć cały układ. Istnieje 8-bitowych mikrokontrolerów, które zawierają prawie 1000 stron dokumentacji. Porównaj to z około 200-300 stronami wartymi dla 8-bitowego procesora z 1980 roku i popularnych układów peryferyjnych, z którymi byłby używany. Bogate w urządzenia peryferyjne 32-bitowe urządzenie będzie wymagało przejrzenia 2000-10 000 stron dokumentacji, aby zrozumieć tę część. Części z nowoczesną grafiką 3D przewyższają 20 000 stron dokumentacji.

Z mojego doświadczenia wynika, że ​​wiedza o wszystkim, co należy wiedzieć o danym 32-bitowym kontrolerze, trwa około 10 razy dłużej niż w przypadku nowoczesnej 8-bitowej części. Przez „wszystko” rozumiem, że wiesz, jak korzystać ze wszystkich urządzeń peryferyjnych, nawet w niekonwencjonalny sposób, i znasz język maszynowy, asembler, z którego korzysta platforma, a także inne narzędzia, ABI (s) itp.

Wcale nie można sobie wyobrazić, że wiele projektów jest wykonywanych z częściowym zrozumieniem. Czasami jest to nieistotne, a czasem nie. Przełączanie platform musi odbywać się przy założeniu, że w perspektywie krótko- i średnioterminowej nastąpi wzrost wydajności, który zapłacisz za postrzegany wzrost wydajności dzięki bardziej wydajnej architekturze. Dokonaj należytej staranności.

Przywróć Monikę
źródło
3

Osobiście nie martwiłbym się zbytnio aktualizacją (8bit-> 32bit) uC tej samej rodziny, a ty zwiększasz specyfikacje. Ogólnie rzecz biorąc, nie robię nic poza normą z typami danych, ponieważ utrzymanie się na drodze może być trudne.

Obniżenie kodu urządzenia to inna historia.

Nick Tullos
źródło
3
Rozmiar typów danych zależy od kompilatora, a nie od architektury procesora. 8-bitowy procesor może mieć 32-bitowe wartości int., Mimo że manipulowanie nimi wymaga wielu instrukcji.
Joe Hass
dobry komentarz - usunąłem pierwszą linię z powodu poprawki.
Nick Tullos
@JoeHass: Kompilator dla 8-bitowego procesora może zdefiniować int32 bity, a nawet 64 bity, ale nie znam żadnych istniejących 8-bitowych kompilatorów, które faktycznie nie definiują intbyć większa niż 16 bitów, lub promować Wartości 16-bitowe na dowolne większe.
supercat,
-1

32-bitowe MCU zużyją o wiele więcej mocy. I wymagają więcej obwodów pomocniczych.

Tak naprawdę nie przechodzi się do 32-bitów z 8-bitów ... Będziesz nadal używać obu, często razem. Najważniejsze jest to, że powinieneś używać (i uczyć się) wszystkiego, co jest odpowiednie do pracy. Naucz się ARM, ponieważ dobrze kołysze teraz osadzony świat i nadal będzie to robić. Naucz się także AVR lub PIC, ponieważ są niesamowitymi kontrolerami kart.

Prawdopodobnie doświadczysz tyle samo niebezpieczeństw podczas przełączania z AVR na ARM, jak i tak z ARM na x86, rozmiar magistrali naprawdę nie robi tak dużej różnicy. Jednak robi to cały zaawansowany sprzęt. Przejście ze standardowych przerwań na wektoryzowaną macierz przerwań z 6 poziomami priorytetów będzie znacznie trudniejsze niż wymyślenie, jak liczyć do czterech miliardów.

Hugo
źródło
4
Nie wiem, czy słuszne jest twierdzenie, że 32-bitowe jednostki MCU są z natury bardziej energochłonne. Co najmniej jedna cała linia produktów ( mikro energetyczna ) to mikrokontrolery o ultraniskiej mocy i wszystkie one oparte są na 32-bitowym rdzeniu ARM.
Connor Wolf,
3
Właśnie opracowałem obwód STM32L1, który powinien działać przez 7 lat na CR2032
Scott Seidman
2
Czy możesz uzasadnić komentarz, że 32-bitowy MCU potrzebuje więcej „obwodów pomocniczych”? Myślę, że wyrażasz tutaj kilka nieuzasadnionych opinii.
Joe Hass
1
Również komentarz dotyczący przerwań wektorze nie ma większego sensu, ponieważ można uzyskać wiele poziomów priorytetów w 8-bitowych mikrokontrolerach (patrz MCU Atmela xmega, które mają 3 poziomy priorytetów), a udział przerwań w wektorze jest nieistotny, gdy każde urządzenie sprzętowe ma to i tak posiadają własne niezależne wektory.
Connor Wolf,
2
Używam 32-bitowego procesora Cortex-M0 do sterowania inteligentną ładowarką do pojazdu elektrycznego. Wykorzystuje pojedyncze zasilanie 3,3 V. Ma wewnętrzny oscylator i PLL, więc nawet nie potrzebuję kryształu. Korzystam z 28-pinowego pakietu DIP, ale mogę uzyskać Cortex-M0 w 8-pinowym DIP, jeśli chcę. Jak może to być bardziej złożone niż typowy PIC lub AVR?
Joe Hass