Porównanie 21 mikrokontrolerów kosztujących poniżej jednego dolara - część 2

Druga część artykułu o najtańszych nowych mikrokontrolerach z roku 2017.

Ekosystem developerski

Środowisko developerskie mikrokontrolera ma ogromny wpływ na jakość pracy z nim i w konsekwencji - na produktywność. Na to składają się różne czynniki – jakość IDE, dostępne biblioteki, płytki rozwojowe, debuggery, kompilatory, etc. Wiele z tych czynników jest subiektywnych. Autor tego zestawienia porównuje do siebie poszczególne środowiska pracy, kompilatory i debuggery – dedykowane do konkretnych układów jak i te ogólnego przeznaczenia. Przyjrzyjmy się części najpopularniejszych z nich.

Jednym z popularniejszych IDE jest Eclipse. Środowisko to zostało napisane w Javie w firmie IBM, oryginalnie dedykowane było do tworzenia aplikacji w Javie, ale od 2001 roku jest otwarte i jego utrzymaniem i rozwojem zajmuje się Eclipse Foundation. Środowisko to dostarcza narzędzi do kodowania w C i C++. W świecie systemów wbudowanych bardzo szybko się przyjęło – najpierw na 32-bitowe ARMy, a następnie dla układów 16- i 8-bitowych. Niemalże każdy układ ma jakieś IDE dla siebie, które stworzono w oparciu na Eclipse:

* Dla NXP Kinetis KE04 - Kinetis Design Studio
* Dla NXP Kinetis KL03 – MCUXpresso lub Kinetis Design Studio
* Dla Infineon XMC1100 - DAVE
* Dla Nuvoton M051 - CooCox CoIDE
* Dla NXP LPC811 - MCUXpresso
* Dla Renesas RL-78 - e2studio
* Dla Silicon Labs EFM8 - Simplicity Studio
* Dla ST STM32F0 -- System Workbench for STM32
* Dla Texas Instruments MSP430 - Code Composer Studio.

Oprócz DAVE, CooCox oraz e2 studio, które pracują tylko pod Windowsem, wszystkie te narzędzia są dostępne w wersji na każdy system operacyjny – Windows, OS X i Linux.

Najnowsza wersja Eclipse – 4.6.3 – posiada wiele ciekawych dodatków, wsparcie dla ciemnego tła, wyświetlanie informacji o funkcjach po najechaniu na nie kursorem etc. Korzysta z niej np. System Workbench dla układów STM32. Główną zaletą Eclipse jest jednak bardzo wygodny system organizacji przestrzeni pracy i projektu, a także wsparcie dla edycji kilku projektów naraz. Dodatkowo silnik ten posiada bardzo dobre podświetlenie składni w swoim edytorze tekstowym oraz rozbudowany system autouzupełniania.

Eclipse wyróżnia się na tle innych IDE głównie faktem możliwości daleko idącej edycji środowiska. Wielkość okienek, ich rozkład etc. – wszystko może zostać dopasowane do własnych potrzeb przez programistę. Oczywiście, część tych modyfikacji wprowadzają firmy, do których mikrokontrolerów programowania dane środowisko ma służyć. Niektóre IDE wzbogacono tylko o ładny ekran startowy, a inne poddano głębokim modyfikacjom. Do tej pierwszej klasy z pewnością zaliczyć można Kinetis Design Studio, MCUXpresso czy System Workbench.

Z drugiej natomiast strony środowisko oferowane przez Silicon Labs musiało zostać mocno zmodyfikowane, by mogło zarówno porozumiewać się z danym układem, jak i korzystać z binarek dla Keila C51. Zwłaszcza ten ostatni aspekt był nietrywialny – wymagał dodatku wine, by móc odpalać to IDE pod macOSem czy Linuxem.

Innym przykładem głębokich modyfikacji Eclipse jest CoIDE, które przypomina bardziej Keila (o którym za chwilę) niż Eclipse. Środowisko to zostało stworzone przez CooCox na samym szkielecie Eclipse z wieloma modyfikacjami.

Jeśli chodzi o wydajność, to Eclipse poprawiło się w ostatnich wydaniach (do wersji Mars w górę) po katastrofalnie powolnej edycji Juno. Tak więc Ci, którzy próbowali kiedyś korzystać z tego środowiska, mogą zechcieć ponownie sprawdzić, czy nowe wersje przypadną im do gustu.

Jedną z zalet Eclipse jest system debuggowania – zunifikowany dla wszystkich platform. Jedyne, co różni się pomiędzy poszczególnymi IDE, to dodatkowe okienka do debuggowania peryferiów itp. Każdy producent rozwiązał to odrobinę inaczej, ale pozostałe funkcje w tych programach są niemalże identyczne.

Niektóre z opartych na Eclipse IDE wzbogacono w kolejne funkcje, takie jak wskazywanie na żywo zajętości pamięci Flash czy RAM przez program itp.

Kolejnym dużym pakietem oprogramowania jest Atmel Studio, wcześniej znane jako AVR Studio. Atmel, odpowiedzialny za to oprogramowanie, oparł je na Visual Studio Isolated Shell, a nie bardzo popularnym obecnie Eclipse (opisane powyżej). Można by spodziewać się dużego podobieństwa do .NET i C++ na desktopy, ale niestety – nazwa nie kłamie i środowisko to rzeczywiście jest wyizolowanym shellem Visual Studio – bez najważniejszych komponentów. Znany z produktów Microsoftu IntelliSense zastąpiony został zewnętrznym oprogramowaniem Virtual Assist, które nie radzi sobie tak dobrze w identyfikacji zmiennych globalnych, interpretacji dyrektyw preprocesora etc.

Atmel Studio znane jest ze sporej ilości błędów i niestabilnej pracy. Autor podsumowuje swoją pracę z tym IDE przez ostatnie dwa lata i wymienia chociażby regularne problemy ze sterownikami do AVR Dragon, uszkodzonymi plikami DLL instalatora, problemami z firmware programatora etc. Wiadomo, że tworzenie oprogramowania dla systemów wbudowanych jest dosyć wąskim profilem, co sprawia, że ciężko może być stworzyć naprawdę niezawodne narzędzia, ale w porównaniu z innymi środowiskami Atmel Studio ma naprawdę poważny problem ze stabilnością.

Kolejnym dużym IDE, wartym wspomnienia, jest MPLAB X Microchipa. Środowisko to oparte jest o NetBeans, co sprawia, że posiada funkcje podobne do Eclipse. Mimo wszystko pod wieloma względami NetBeans jest znacznie różne od Eclipse. Oba środowiska są otwarte i wieloplatformowe, ale NetBeans oparte jest na zupełnie innych paradygmatach programowania.

MPLAB X ma bardzo dobre narzędzia do autouzupełniania tekstu. Wydaje się być prostsze w obsłudze niż Eclipse, głównie z uwagi na prostszy interfejs użytkownika. Głównie, dlatego, że oferowane przez NetBeans środowisko nie jest tak przeładowane przyciskami i okienkami jak IDE na Eclipse. Ta prostota może być bardzo kusząca dla hobbystów, ale też wielu profesjonalistów preferuje tego rodzaju interfejs użytkownika.

Kolejną zaletą MPLABa jest ilość zmian wprowadzonych przez Micropchipa w NetBeans, by dostosować IDE do pracy nad systemami wbudowanymi. Na przykład już na poziomie ustawień projektu jesteśmy w stanie wybrać dokładnie, z jakich narzędzi chcemy korzystać podczas programowania i debuggowania systemu (spośród tych produkowanych przez Microchipa). Zintegrowanie wyboru i konfiguracji narzędzi do programowania MCU jest bardzo użyteczne dla programistów, którzy często przesiadają się pomiędzy urządzeniami, ale z drugiej strony męczące dla tych, którzy korzystają tylko z jednego konkretnego zestawu i konfiguracji.

Jednym z problemów MPLABa jest redundancja interfejsu – przyciski „Run Project” dubluje „Make and Program Device”, aczkolwiek patrząc na niektóre implementacje Eclipse, użytkownicy czasami przyzwyczajać się muszą do jeszcze bardziej udziwnionego rozkładu środowiska pracy.

Debugowanie w środowisku Microchipa jest istotnie wolniejsze niż w większości innych IDE, aczkolwiek wydaje się, że jest to ograniczenie wynikające z samych MCU lub programatora (PicKit3). Jest tutaj także szereg innych problemów – np. MPLAB X domyślnie resetuje połączenie z debuggerem za każdym razem, gdy uruchamia się nową sesję debuggowania MCU. Można skonfigurować środowisko tak, żeby połączenie z debuggerem włączone było cały czas, dzięki czemu oszczędzimy kilka sekund podczas używania IDE. Innym problemem podczas debuggowania jest fakt, że czasami program myli rejestry, co jest czasami problematyczne, zwłaszcza w największych, 32-bitowych układach (z rodziny PIC32). Z uwagi na to środowisko to wydaje się dosyć antyczne – mamy 2017 rok i większość IDE ma wbudowane zaawansowane systemy tłumaczenia rejestrów etc., nie ma potrzeby siedzieć z otwartą kartą katalogową na kolanach, jak wymaga tego debugger MPLABa X.

Z kolei Holtekowe HT-IDE3000 jakkolwiek wygląda jak brzydszy kuzyn Office 2003 to działa bardzo sprawnie. Mimo starego wyglądu środowisko to oferuje kontekstowe autouzupełnianie kodu i doskonałą integrację z wieloma narzędziami do programowania tych układów. To IDE dostępne jest na stronie Holteka – jedyne 90 MB do pobrania. Nie trzeba się rejestrować ani nic – jedynie, gdy podpinamy debugger eLink, to musimy w ustawieniach HT-IDE3000 wpisać jego numer seryjny.

Oprócz niewielkich wymagań sprzętowych i szybkiej, i stabilnej pracy IDE Holteka pochwalić może się jeszcze czymś innym: ogromną specyfiką. Dzięki temu, że układ jest dopasowany do jednego rodzaju MCU, to mógł zostać on bardzo zintegrowany z całym ekosystemem. I tak w HT-IDE3000 dostępne są takie narzędzia, jak bezpośredni edytor pamięci EEPROM w układzie, programowy generator bootloadera USB, a także system generowania dokumentacji dla jednorazowo (fabrycznie) programowanych układów – Holtek może zaprogramować je fabrycznie, tak z resztą sprzedaje większość swoich układów.

Kolejnym IDE jest ST Visual Develop (STVD) dedykowane dla układów STM8. Wygląd tego środowiska sprawia, że wydaje się jeszcze starsze niż IDE3000. Mimo to IDE to posiada wiele nowoczesnych funkcji, takich jak autouzupełnianie kodu itp. Niestety to oprogramowanie nie jest zbyt szybkie, zwłaszcza przy większych projektach, itp. potrafi irytująco zwolnić.

Debugowanie w STVD także nie jest zbyt płynne, a dodatkowo program ma kilka mało wygodnych rozwiązań – breakpointy nie mogą być ustawiane, gdy program jest uruchomiony. IDE nie wyświetla pojedynczych bitów rejestrów ani nie tłumaczy, za co odpowiadają.

PSoC Creator to oprogramowanie firmy Cypress dedykowane do generacji projektów na układy PSoC – pozwala to nie tylko na pisanie programów na te mikrokontrolery, ale także konfigurowanie innych modułów w układzie PSoC – sekcji analogowej, układu programowalnego etc.

Interfejs tego środowiska także nie jest zbyt nowoczesny. IDE napisano w .NET, przez co nie działa pod macOSem i Linuxem – sam Cypress przyznaje, że mało prawdopodobne jest, by ukazały się wersje na inne systemy niż Windows. Jeśli chodzi o samo działanie, to środowisko wydaje się być bardzo sprawne – dużo lepiej niż Eclipse czy NetBeans. IDE wspiera działanie z kilkoma projektami naraz, podobnie jak Eclipse. Interfejs programu pozwala na łatwe przeglądanie zawartości projektu – wystarczy jedno kliknięcie, by przeglądać definicje zmiennych, funkcji etc. Zaawansowane funkcje autouzupełniania doskonale radzą sobie z kodem, makrami itp. Jedyne, czego brakuje temu IDE jest kontekstowa pomoc, która wyświetlałaby się po najechaniu na funkcję czy jej parametry, jak zrealizowano to w Eclipse czy IDE3000.

Jako że w omawianych układach PSoC znajduje się CPU oparte na ARM, to w zasadzie do pisania programu można by wykorzystać jakiekolwiek środowisko oparte np. o GCC. Niestety z uwagi na bardzo wiele ustawień koniecznych w PSoC-u w związku z konfiguracją sekcji analogowej, itd. – nie jest to takie proste. Z drugiej strony, jeśli musimy pracować pod innym systemem niż Windows, możliwe jest eksportowanie projektów stworzonych w PSoC Creatorze do programów, takich jak Keil czy IAR, będących de facto standardem w branży. Jednakże pod Windowsem – o ile to możliwe, to nie jest wskazane. Środowisko Cypressa całkiem dobrze się sprawdza.

Finalnie, środowiskiem programistycznym, które koniecznie trzeba omówić jest Keil firmy µVision. Pierwszy Keil – dla układów z rdzeniem 8051; z kompilatorem C51 – wprowadzony został do sprzedaży w 1988 roku, ale jako-takie IDE pojawiło się dopiero w 1997 roku. Obecnie w handlu dostępna jest wersja piąta. Oprócz kompilatora dla 8051, µVision sprzedaje także IDE dla układów z rdzeniem ARM Cortex, C166 i 251. To środowisko jest obecnie kompatybilne z niemalże każdym układem z rdzeniem ARM, dostępnym na rynku i jakkolwiek ich producenci tworzą własne IDE, to zamiast dowolnego z nich, stosować można Keila. Odmiennie jest z 8051 – większość producentów MCU (wszyscy oprócz Silicon Labs) nie produkują własnego środowiska, natomiast zapewniają wsparcie dla Keila.

Edytor tekstowy w Keilu jest dosyć toporny i mało wygodny. Pierwsze, co rzuca się w oczy jest brak automatycznego wcinania pisanych bloków kodu, a także brak dedykowanych skrótów klawiszowych do zakomentowania kodu. Jeszcze bardziej problematyczne jest przełączanie się pomiędzy projektami dla C51 a ARM. Podczas pisania kodu dla ARMów, np. autouzupełnianie tekstu jakoś działa, a gdy jesteśmy w świeci 8051, to po prostu znika.

Podobnie jak wyżej dzieje się w wypadku debugowania. Keil dobrze sprawdza się z ARMami, ale z 8051 ma już pewne problemy – system działa topornie i nie każda marka mikrokontrolerów jest poprawnie wspierana. Dodatkowo w momencie debugowania programu dla ’51 pojawia się wiele okienek do analizy rejestrów peryferiów, itp. To o wiele bardziej męczące niż interfejs do debuggowania w układach z ARMami.

Mimo swojej popularności IDE to nie jest wcale lepsze od Eclipse. Wyróżnia się jedynie dosyć dużą wydajnością i niewielkim zapotrzebowaniem na procesor czy RAM w komputerze.

Oprócz środowisk programistycznych warto także zwrócić uwagę na narzędzia do generacji kodu. Tego rodzaju narzędzie bardzo przyspiesza tworzenie projektów, szczególnie, jeżeli realizujemy jakieś dosyć niewielkie urządzenie. Większość IDE posiada takiego typu element, który pozwala nam wygenerować projekt z pewnymi elementami kodu. Takie narzędzia znajdziemy między innymi w Microchip Code Configurator, Simplicity Configurator, Infineon DAVE, PSoC Creator, Processor Expert. Część firm, z drugiej strony, dostarcza samodzielne narzędzia do generowania projektów, takie jak STM32CubeMX, Atmel START, STC-ISP, MCUXpresso Config Tools, które umożliwiają proste wyklikanie podstawowych elementów kodu programu, dodając na przykład biblioteki do obsługi poszczególnych peryferiów (tak robi STM32CubeMX) lub po prostu konfigurując odpowiednio rejestry (tak robi z kolei Simplicity Configurator od Silicon Labs). Narzędzia te działają różnie – niektóre, jak Atmel Start, mają problemy z np. ustawianiem zegara czy innymi opcjami, gdzie samodzielnie chcemy skonfigurować wartość. Mimo wprowadzenia odpowiednich danych może okazać się, że układ zostanie skonfigurowany inaczej niż chcemy.

Jeśli chodzi o wykorzystanie Atmel Start do ośmiobitowych AVRów, to sprawa jest prosta. Program generuje inicjalizacyjny kod, dostarcza odpowiednie sterowniki etc. Kod ten jest bardzo przejrzysty, dobrze napisany i doskonale zadokumentowany. Pozwala to łatwo przejść do poważniejszego programowania tych MCU niż robi się to wykorzystując takie amatorskie środowiska jak Arduino.

Dużo gorzej jest, gdy chcemy wykorzystać Atmel Start do stworzenia kodu na mikrokontrolery SAM D. Jest tam dużo konfigurowania, szczególnie systemu zegarowego. Niestety konfigurator nie zapewnia żadnego sprawdzania poprawności konfiguracji. Powoduje to, że łatwo się pomylić lub coś przeoczyć. Poprawianie projektu nie jest takie proste. Projekty te generuje się w przeglądarce i pobiera jako paczki ZIP. Atmel Studio, następnie rozpakowuje te paczki i konfiguruje nowy projekt. Na szczęście z poziomu IDE można zmienić elementy konfiguracji MCU i nie trzeba ponownie generować nowego projektu.

Ostatnim problemem Atmel Start jest słaba jakość generowanego kodu, zwłaszcza brak komentarzy w kodzie, które mogłyby oznaczać, które części plików źródłowych można edytować, a które nie.

Kolejnym omawianym narzędziem jest Processor Expert stworzony przez Freescale. Program ten wyróżnia się ogromną elastycznością opcji konfiguracji, generuje niezły – chociaż wolny – kod dla MCU. Generowane są nie tylko kody inicjalizacji, ale także obsługa przerwań, pliki linkera etc. Niestety ceną za to jest bardzo powolne działanie samego narzędzia. Processor Expert ma ogromne wymagania co do komputera, na którym go uruchamiamy.

Narzędzie to działa w bardzo obiektowo zorientowany sposób, na bardzo wysokim poziomie. Generowane wysokopoziomowe moduły – np. timery – nie są bezpośrednio zależnie od ich sprzętowych odpowiedników. Na przykład dwa moduły mogą współdzielić jeden fizyczny timer w MCU. Wyobraźmy sobie, że np. chcemy skonfigurować mikrokontroler tak, by uruchamiał on jakąś funkcję co 25 ms. Skonfigurować musimy Timer, który co 25 ms będzie realizował nasze zadanie. Processor Expert zajmie się kompleksową implementacją – wybierze, jaki timer jest nam potrzebny, skonfiguruje odpowiednio zegar, policzy stałe i rejestry, skonfiguruje przerwania i ustawi naprawdę wszystko, co może być nam potrzebne automatycznie. Jeśli chcemy, to oczywiście możemy zmienić tą konfigurację. Niezależnie od tego, co zrobimy, to program upewni się, że wygenerowana przez nas konfiguracja na pewno działa.

Kolejnym generatorem kodu jest ten wbudowany w IDE Dave, który korzysta z biblioteki XMClib. Biblioteka ta jest całkiem zoptymalizowana i pozwala na osiągnięcie dużej sprawności i prędkości działania MCU. W Dave wbudowano także wysokopoziomowe funkcje i moduły, takie jak na przykład odbiornik DMX-512, generacja grafiki, obsługa silników (np. algorytmy sterowania FOC dla silników ACIM i PMSM).

Simplicity Studio od Silicon Labs jest na drugiej stronie skali – generator ten pozwala jedynie na automatyczne stworzenie podstawowego kodu inicjalizującego, który nie zapewnia bibliotek i sterowników dla peryferiów – konfigurator po prostu ustawia odpowiednie wartości rejestrów.

Silicon Labs zapewnia dla układów EFM8 biblioteki do obsługi peryferiów, jednakże generator kodu w ogóle z nich nie korzysta. Oczywiście po wygenerowaniu podstawowego projektu w Simplicity Studio nic nie stoi na przeszkodzie, by projekt dokończyć korzystając z bibliotek producenta. Takie podejście daje bardzo dużą elastyczność i pozwala pilnować wielkości generowanego kodu. Simplicity Studio jest także najszybszym generatorem spośród testowanych. Jest na tyle szybkie, że kod jest odświeżany za każdym razem, gdy projekt jest zapisywany.

Stworzony przez Renesasa e2studio generator kody wbudowany jest w opracowane przez nich IDE. Narzędzie to wykorzystuje graficzny konfigurator MCU do wygenerowania ładnie zadokumentowanego i opisanego kodu. Szczególnie dobrze generator ten radzi sobie z przerwaniami i generowaniem funkcji, które je obsługują. Dzięki temu, że funkcje obsługi przerwań są statycznie deklarowane to mają one bezpośredni dostęp do buforów danych, nie ma konieczności kopiowania/buforowania danych do funkcji przerwania.
Niestety narzędzie Renesasa ma też swoje wady. Nie do końca dobrze radzi sobie z timerami, jak i innymi peryferiami – generowane jest sporo kodu inicjalizującego, ale brak jest jakiegoś rodzaju wysokopoziomowego API do obsługi peryferiów. Na przykład, gdy chcemy korzystać z PWMa, to i tak będziemy musieli finalnie zmieniać rejestry timera w programie, aby z niego korzystać. Lepiej, gdyby e2studio Code Configurator generował funkcje do obsługi tego PWMa, takie jak np. setDutyCycle(); jakie generuje wiele narzędzi – ułatwia to pracę wielu użytkownikom, którzy nie umieją lub nie chcą modyfikować wartości rejestrów manualnie.

Kolejnym narzędziem jest Nutool Pinconfig od Nuvotona. W teorii powinien on stworzyć kody inicjalizacyjne dla ich MCU z rdzeniem M0, ale w praktyce nie ma on żadnego praktycznego znaczenia. Program ma pełno błędów, używa starych i zabugowanych bibliotek peryferiów, nie potrafi odtworzyć dobrze konfiguracji etc. Ktokolwiek zadał sobie te 15 minut trudu, by stworzyć ten soft, powinien spędzić co najmniej kilka dni, by wyprodukować cokolwiek, co działa.

Podobnie sprawuje się MCUXpresso Config Tool dla układów NXP. Wykorzystywany jest zamiast Processor Experta i w teorii służy do konfiguracji zegara w układzie i multipleksowania pinów, ale w praktyce wygenerować on potrafi jedynie bramkowanie zegara i nic więcej. Podobno da się w ten sposób wygenerować projekty dla MCUXpresso, ale program potem i tak informuje, że wcale tego nie potrafi. Program potrafi zapisać swoje ustawienia w pliku konfiguracyjnym, ale jeżeli chce się cokolwiek w nich zmienić, to de facto trzeba i tak od nowa konfigurować wszystko. Wygenerowane pliki projektu trzeba i tak poprawić ręcznie już w środowisku deweloperskim, ale to nie jest coś, z czym nuworysz niedoświadczony z Eclipse może sobie poradzić na początku.

W STC-ISC także wbudowany jest moduł do generacji kodu. Podczas konfiguracji 8051 trzy największe problemy, z jakimi ludzie mają do czynienia to UART, timer i funkcja do opóźnienia. Wynika to z faktu, że aby skonfigurować i zrealizować te funkcje konieczne są – czasami bardzo złożone – obliczenia taktowań etc. Rzeczony generator kodu doskonale radzi sobie z tymi właśnie zadaniami. Tworzy on kod do inicjalizacji UARTu, timerów i generuje funkcje do opóźnień. Generować może tak kod w C, jak i w assemblerze, a dodatkowo, niezależnie od wersji, jest on bardzo ładnie skomentowany, więc nie ma żadnego problemu z jego zrozumieniem – tak od razu, jak i po np. pół roku.

Z kolei Code Configurator od Microchipa (MCC) przoduje w multipleksowaniu pinów. Narzędzie to dedykowane jest dla wszystkich PICów – 8-, 16- i 32-bitowych. Program zawiera menedżer pinów, który wypisuje nam, jakie funkcje przypisać można do poszczególnych fizycznych wyjść z układów. Każde z peryferiów posiada tak system do prostego generowania kodu do inicjalizacji i konfiguracji, jak i bardziej zaawansowany system, który umożliwia nam analizowanie i konfigurowanie rejestrów MCU, jeśli chcemy zrobić coś na niższym poziomie.

MCC generuje kompaktową, dedykowaną do naszych potrzeb, bibliotekę, która jest doskonała na początek. Problemem jest jednak generacji funkcji do obsługi przerwań. Same funkcje generują się dobrze, ale nie są po prostu zbyt optymalnie napisane, a niestety nie da się w MCC wyłączyć tej funkcji.

Oprócz problemu z szybkością funkcji do obsługi przerwań generowanych przez MCC, przyznać trzeba, że kod napisany jest z jednej strony kompaktowo i wydajnie, a z drugiej, w bardzo przystępny dla programisty sposób.

Kolejnym narzędziem do generacji kodu jest moduł wbudowany w PSoC Creator. Jest on o tyle nietypowy, że oprócz generacji samego kodu dla MCU, pozwala także na wygenerowanie bitów konfiguracyjnych do zaawansowanych peryferii PSoCów. Z uwagi na to jednakże, nie da się nie skorzystać z generatora kodu – bez niego nie skonfigurujemy tych modułów, które są poza MCU w naszym układzie.

W generatorze Cypressa korzystamy z graficznego interfejsu, w którym konfigurujemy poszczególne bloki funkcyjne – moduły PWM, interfejs(y) SPI, piny ADC, czy (w mocniejszych PSoCach) – rekonfigurowalne bloki analogowe i cyfrowe. Każdy blok ma swoje okienko parametrów, co pozwala na doskonałe i pełne skonfigurowanie bloku. Takie podejście wydaje się być bliższe elektronikom, a nie programistom, jednakże z punktu widzenia inżyniera, który zajmował się głównie projektowaniem PCB, sam interfejs PSoC Creatora jest raczej toporny. Wszystkie elementy trzeba koniecznie i mozolnie układać na generowanym schemacie i manualnie połączyć – nawet zegary. Natomiast, jeżeli chcemy zdefiniować przerwanie, to je także połączyć musimy wirtualnym ‘kabelkiem’ pomiędzy źródłem a wejściem w procesorze.

Z jednej strony takie podejście sprawia, że od razu dostajemy piękną dokumentację, która pokazuje nam, jak poszczególne komponenty są ze sobą połączone i jak wszystko ze sobą działa, ale z drugiej strony – czy naprawdę system musi być tak drobiazgowy? Np. gdy podłączamy zegar do timera, to aby podzielić częstotliwość musimy wstawić osobny blok – dzielnik zegara – a nie zdefiniować to w timerze, ponieważ takowy nie ma w ogóle wbudowanego dzielnika na wejściu zegarowym. Oczywiście – to wszystko kwestia preferencji, a ta ocena jest wyjątkowo subiektywna.

Ostatnim omawianym narzędziem jest STM32CubeMX dla układów z rdzeniem ARM od STMicro. To bardzo lekkie i przyjemne w wykorzystaniu narzędzie, które skupia się na inicjalizacji peryferiów i generacji kodu bibliotek do ich obsługi. CubeMX korzysta ze standardowych bibliotek dla STM32, które są identyczne w zasadzie dla całej rodziny tych mikrokontrolerów. Jest to zaskakująco bardzo problematyczne, gdyż biblioteki te znane są ze swojej opasłości. I taki też jest kod generowany przez ten program – w zasadzie większe udało się wygenerować tylko przy wykorzystaniu STARTa Atmela oraz oprogramowania Nuvotona. Jest to szczególnie problematyczne w przypadku najmniejszych mikrokontrolerów, które nie mają zbyt wielkiej pamięci programu. Wadą generowanego kodu jest też fakt, że funkcje wykorzystywanej biblioteki, są bardzo podstawowe, ale na szczęście możliwa jest ich daleko idąca edycja w wygenerowanym projekcie. Do zalet CubeMXa należy zaliczyć to, że potrafi generować projekty nie tylko dla własnego IDE STMa dla STM32 (System Workbench), ale także dla innych środowisk programistycznych (np. dla Keila czy IARa).
 




Narzędzia deweloperskie

W ostatnich latach wszelkie narzędzia deweloperskie stają się coraz prostsze i mniejsze, dzięki czemu ich ceny są coraz niższe. Nie trzeba wydać już kilkuset dolarów na ogromną płytkę uruchomieniową dla MCU, posiadającą na pokładzie ogromną ilość peryferiów etc. Obecnie moduły te produkowane są raczej w formie kompatybilnej z płytkami stykowymi itp. W ten sposób bez problemu można zestawiać dowolne konfiguracje urządzeń.

Jeśli chodzi o preferencje autora zestawienia, to jego ulubionymi modułami są te, na których znajdziemy tylko MCU, debugger i wyprowadzenia poszczególnych pinów układu. Dodatkowo, dobrze, jeżeli debugger można odłączyć od układu, na przykład z pomocą zworek.

Niezależnie, co myślą działy marketingu poszczególnych firm, to na płytce drukowanej modułu uruchomieniowego nie powinno być żadnych sensorów itp. Nic, co da się łatwo zestawić na płytce stykowej, nie powinno integrować się na płytce deweloperskiej. Można integrować np. pola sensorów pojemnościowych, ale nie ma potrzeby integrować dużej ilości elementów pasywnych czy dodatkowych układów scalonych.

Z uwagi na powyższe wymagania bardzo dobrze prezentują się płytki LaunchPad dla MSP430 (w tym formacie dostępne są także inne moduły dla MCU TI). W module zintegrowano tylko podstawowe składniki systemu, debugger oraz miernik zużycia prądu przez MCU. Podobnie dobrze wyglądają płytki Microchip Curiosity, jednakże autorowi nie udało się ich osobiście przetestować.

Oprócz wyposażenia jest jeszcze kilka innych ciekawych funkcjonalności, na które warto zwrócić uwagę podczas wyboru płytki deweloperskiej i/lub MCU.

Odrywalny debugger

W szeregu płytek – m.in. dla Nuvoton N76, M051, XMC1100 oraz w modułach STNM32Discovery – część z debuggerem na płytce uruchomieniowej może zostać oderwana od reszty. Można je potem spiąć kablem albo zworkami – większość wyprowadzeń tego rodzaju ma standardowy raster 2,54 mm.

Format Arduino UNO

Jednym z ciekawych rozwiązań w kwestii format płytki jest skorzystanie ze standardowego formatu Arduino UNO. Nie jest to per se przemysłowy standard żadnego rodzaju, ale stał się standardem de facto w sektorze płytek uruchomieniowych dla amatorów i hobbystów. Ta kwestia jest jednak o tyle złożona, że oprócz formatu mechanicznego istnieje format elektryczny i programowy. Szereg producentów wspiera standard Wiring, który pozwala na podłączanie peryferiów Arduino. Nuvoton w ten sposób rozwiązał swoje płytki dla serii M0, podobnie NuMaker Uno, który posiada układ ARM Cortex-M0. Obie płytki mają wsparcie także dla IDE Arduino.

Niestety, duża część projektantów modułów uruchomieniowych nie rozumie, że sama forma kompatybilna z Arduino UNO niewiele tutaj znaczy. Bez wsparcia zarówno dla bibliotek Arduino, jak i środowiska Wiring, takie rozwiązanie jest nic nie warte. Szczególnie kiepsko w tym zakresie wypada NXP, ale nie jest to jedyny producent MCU winny tego grzechu.

Płytki LCPXpresso MAX od NXP produkowane są w formacie Arduino UNO, ale jest to wyjątkowo bez sensu w przypadku płytek z układami z serii LPC81x, które mają np. po 11 pinów GPIO i nie mają nawet ADC. Co robi w tej sytuacji NXP? Losowo podłącza te piny do MCU, a dodatkowo nie oferuje żadnego wsparcia programowego dla tego rozwiązania. Co nam to daje? Niewiele – oszczędzimy 30 sekund podłączając shielda, ale nie wiemy nawet, czy ten konkretny będzie kompatybilny, bo NXP nie publikuje listy kompatybilnych układów, nie mówiąc już o jakimkolwiek wsparciu.

Finalnie, zaznaczyć trzeba, że moduły do Arduino nie są raczej dedykowane do zastosowań profesjonalnych – korzystają z nich głównie amatorzy i hobbyści.

Modyfikacje na płytce uruchomieniowej

Jeśli chcemy zminimalizować pobór prądu przez płytkę uruchomieniową, w przypadku szeregu modułów konieczne są sprzętowe przeróbki. Autor zestawienia przerabiał moduły sTC8, Nuvoton oraz Atmel Xplainer Mini dla tinyAVR, megaAVR i SAMD10. Przeróbki te to głównie usuwanie diod LED czy separowanie linii zasilania. Schematy tych płytek uruchomieniowych są dostępne i dobrze opisane, więc taka modyfikacja nie jest wielkim problemem.

Na drugim biegunie są płytki, takie jak Cypress PSoC 4000S czy Moduł Infineona, które zadokumentowane są gorzej - zarówno pomiar, jak i redukcja prądu zasilania jest bardziej problematyczna.

Najgorzej w poruszanej kwestii wypadły płytki FRDM od Freescale. Przeróbki w module były bardzo trudne, a wiele elementów obecnych na płytce dla Kinetis KL03 nie było w ogóle obecnych w dokumentacji. Ciężko było też w tym układzie mierzyć prąd pobierany przez MCU z zasilania, jako że na płytce obecnych jest wiele LEDów, sensorów i podciągnięć dla przycisków, których zasilania nie da się odseparować od zasilania mikrokontrolera. Ogólnie mówiąc ta płytka wydaje się być najgorszą ze wszystkich.

Wbudowany debugger i inne dodatkowe funkcje

Wszystkie płytki deweloperskie posiadają wbudowane debuggery, ale istotnie różnią się one możliwościami. Najbogatszym wyposażeniem pochwalić się może moduł SLSTK od Silicon Labs. Moduł ten integruje w sobie Debugger J-Link z interfejsem USB 2.0, posiadający precyzyjny system do pomiaru prądu zasilania. Biorąc pod uwagę niską cenę modułu (30 dolarów) to naprawdę dobre wyposażenia. Podobnie wyposażony dla LaunchPad dla MSP430, ale w ogólności to rzadkie wyposażenie pośród modułów w tej cenie.

Moduły dla KL03 i XMC1100 także posiadają J-Linka, ale z wolniejszym interfejsem USB. Z kolei w modułach Cypressa i dla Microchipowego SAM D10 zintegrowano debugger CMSIS-DAP. Nuvoton stosuje z kolei swoje własne rozwiązanie – NuLink, tak w modułach dla ARM, jak i 8051.

Moduł Freescale i ST programować można bezpośrednio oprogramowaniem Seggera, co chyba każdy uzna za zaletę – J-Link tej firmy wydaje się być obecnie chyba standardem, a na pewno najlepszym debuggerem dla układów ARM. Dodatkowo, dzięki pracy z USB 2.0 ładowanie flashu jest superszybkie.

Duża część płytek ma oczywiście możliwość podłączenia zewnętrznego debuggera. W niektórych może być dedykowane do tego gniazdo (często nieobsadzone), w innych konieczne mogą być różne zmiany na PCB.

Jeśli chcemy poważnie zająć się daną rodziną MCU koniecznie posiadać musimy jakiś dedykowany samodzielny debugger dla danej architektury. W ekosystemie Microchipa mamy szeroki wybór: PicKit3 (48 dolarów), ISCD4 (249 dolarów) lub RealICE (499 dolarów). Wszystkie one wspierają każde MCU tego producenta, ale różnią się możliwościami – np. PicKit3 wspiera tylko dwa breakpointy.

Jeśli chodzi natomiast o rodziny układów AVR I SAM, to naszą jedyną opcją jest kosztujący 130 dolarów Atmel-ICE, jeśli chcemy wspierać wszystkie nowe układy. Dla starszych megaAVR i tinyAVR wystarczyć może nam AVR Dragon za 49 dolarów.

Ekosystem układów EFM8 posiada jedne z najszybszych i najtańszych debuggerów. Wykorzystać możemy jakiś układ z rodziny Segger J-Link (od 60 do nawet 1000 dolarów), dedykowany USB Debug Adapter (35 dolarów) oraz ToolTick Base Adapter (19 dolarów). Idąc dalej, można zarówno skorzystać z klonów tych układów (już od 10 dolarów), jak i zestawić super prosty układ samemu już za niecałe 2 dolary.

W zasadzie, jeśli chodzi o ekosystem układów z rdzeniem ARM, to nieważne, jaki jest producent układu, wybierz J-Linka od Seggera. Debugger ten działa z każdym środowiskiem, jest szybki, ma nieograniczoną liczbę breakpointów i działa z każdym napięciem zasilania układu. Jako student możesz kupić sobie J-Link Edu Mini za już od 18 dolarów albo pełną edukacyjną wersję układu za 60 dolarów. Jeśli już zakończyłeś edukację i pracujesz zawodowo, to za 600 dolarów kupisz komercyjną wersję pełnego debuggera. Może wydać się to wysoką ceną, ale jeśli podzielimy to przez ilość godzin, którą przez to oszczędzimy używając tego narzędzia, to koszt wyda się o wiele bardziej akceptowalny. No i oczywiście – zawsze pozostają klony, dostępne w handlu.

Poszczególne debuggery różnią się parametrami – głównie prędkością. Podobnie jest z samymi układami. Najwolniej pamięć programu ładowała się do PIC16, PIS32MM i SAM D10 - ponad 20 sekund na całą pamięć. Układy te jednakże nie zachowywały się tak cały czas, np. po restarcie komputera prędkość ładowania była większa.

Z kolei najszybszym pod tym względem układem był Infineon XMC1100 – całe 8 KB pamięci Flash zapisał (poprzez J-Link) w 2,47 sekundy. To szczególnie godne podziwu, jako że operacja kontrolowana była przez środowisko Eclipse, które wśród narzędzi do debugowania nie jest znane z oszałamiających prędkości.

Jeszcze lepszy wynik, ale poza swoim IDE, osiągnął LC87 – 1,87 sekundy. Jednakże, aby skorzystać z programu RD87 do ładowania programu konieczne jest po pierwsze wyjście z IDE, a po drugie szereg manualnych kroków, takich jak wybranie pliku etc., co sprawia, że sama szybkość ładowania staje się jakby mniej wartościowa.

Pozostałe układy, takie jak EFM8, STM8 czy STC8 osiągały czasy ładowania poniżej 5 sekund. Żaden pozostały układ nie wgrywał pamięci programu dłużej niż przez 6,2 sekundy.

Wydajność układów



W zakresie przełączania stanu wyjścia – pojedynczego pinu – układy z rdzeniem Cortex-M0+, tinyAVR i PIC32MM były w stanie zejść do zaledwie trzech cykli na zmianę stanu. Wszystko dzięki dedykowanej operacji odwracania GPIO i zajmującej dwa cykle procesora operacji skoku.

Układy z rdzeniem Cortex-M0 powinny teoretycznie osiągnąć 5 cykli zegara w tym teście, ale wiele układów z rdzeniami ARM potrzebowało więcej – nawet do 11. Jedynie XMC1100 udało się osiągnąć 5 cykli podczas pracy z programem załadowanym do RAMu.

Układy tinyAVR są odrobinę wolniejsze niż megaAVR z uwagi na 16-bitową przestrzeń adresową dla peryferiów, ale możliwe jest remapowanie portów GPIO do przestrzeni 64-bitowej, co daje takie same możliwości jak ma megaAVR, kosztem dostępu do tylko jednego portu GPIO.

Na dole stawki uplasowały się układy z architekturą 4T i 3T – Holtek HT66, Microchip PIC16 oraz Sanyo LC87. Układy te mają 8-bitową architekturę i ładują cały rejestr naraz, wykonując operację XOR z zatrzaskami portu. Być może da się to zrobić szybciej, jednakże autor zestawienia na moment jego pisania nie dysponował wiedzą jak.

Jeśli chodzi o filtr cyfrowy, to koniecznym jest omówienie osobno architektur ośmiobitowych i 16/32-bitowych.

Układy 8-bitowe

W porównaniu do większych konkurentów plasują się one gdzieś pomiędzy ‘średnio’ a ‘bardzo kiepsko’ w tym zadaniu. Układy PiC16 i HT-66 ze swoją architekturą 4T i pojedynczymi rejestrami, plasują się na samym dole stawki – układy te po prostu nie są stworzone do liczenia, nie mówiąc już o zadaniach, takich jak 16-bitowe mnożenie z akumulacją.

Ponieważ wolne mikrokontrolery długo obrabiają dane, to układy takie jak HT-66, LC87 czy PIC16, pobierać będą też dużo energii. MCU et pobierają do 500 nJ na próbkę danych, co sprawia, że są daleko w tyle za wszystkimi pozostałymi.

Na drugiej stronie skali znajdują się układy tinyAVR oraz megaAVR, które poradziły sobie w tym zadaniu całkiem nieźle. Układy te podczas testów nie pracowały przy maksymalnej częstotliwości zegara, która wynosi 20 MHz, co głównie wynika z chęci zasilenia ich napięciem 3,3 V.

To porównanie finalnie rozstrzyga odwieczny konflikt PICów z AVRami – tak, MCU ze stajni Microchipa są taktowane wyższymi zegarami, ale dopóki nie jesteś w stanie taktować układu PIC16 zegarem 176 MHz, to w zakresie obliczeń matematycznych 8 MHz AVR bije na głowę PIC167.

Układy 16- i 32-bitowej

Oprócz MSP430, który nie ma sprzętowego mnożnika, wszystkie pozostałe element miały podobne osiągi. MCU z rdzeniem ARM osiągnęły odrobinę lepsze wyniki niż pozostałe, ale nie były to różnice dramatyczne. Odrobinę wybił się Atmel SAM D10, ale wynikać to mogło z faktu, że jego pętla PLL lekko przyspieszyła i układ taktowany był minimalnie wyżej niż 48 MHz.

Jeśli chodzi o wydajność w cyklach zegarowych, to różnice wynikają raczej z prędkości dostępu do pamięci flash. Układy, które dobrze radzą sobie z dostępem do pamięci podręcznej osiągały niemalże 27 cykli na pętlę filtra. Wartość tą osiągnęły układy PSoC, jako że taktowane są 24 MHz i nie wymagają pamięci podręcznej – korzystają bezpośrednio z pamięci flash, bez przestojów.

Z kolei Infineon XMC1100, jakkolwiek też potrafi czytać flash bez przestojów, to dopiero z zegarem poniżej 8 MHz. Układ ten nie ma akceleratora flash, co odbija się na wyniku, ale gdy program uruchomi się z RAMu, a nie flashu, to od razu układ osiąga ‘graniczne’ 27 cykli, jednocześnie pobierając mało prądu.

Oparty o architekturę MIPS 32-bitowy PIC32MM trzyma się na liście nieźle – jedynie o trzy cykle gorzej niż ARM Cortex-M0+. Podobnie jak PSoC 4000S układ ten jest też na tyle wolny, że nie potrzebuje pamięci podręcznej do akceleracji odczytu z pamięci flash. W przypadku większych układów z rodziny PIC32MX, może to być już jednak problemem.

Fenomenem w tym sektorze MCU okazał się być jednak 16-bitowiec od Renesasa. RL-78 okazał się być tylko o 6 cykli zegara wolniejszy od ‘mocarnego’ Cortex-M0+ i o 7 cykli szybszy niż PIC24, który całą architekturę ma 16-bitową (RL-78 ma ośmiobitowe ścieżki danych). Gdyby tylko mógł pracować z większym zegarem…

Wnioski

Poniżej postaram się krótko podsumować informacje na temat każdego z prezentowanych układów.

Silcon Labs EFM8: Układy ośmiobitowe o bardzo dobrych możliwościach i darmowym środowisku deweloperskim, które działać może na dowolnym systemie. Same układy są bardzo mocne i dobrze wyposażone – zegar MCU taktowany może być do 72 MHz, a układy wyposażone mogą być w 14-bitowy ADC, 12-bitowy DAC i ogromna ilość timerów itp. nadrabia wszelkie niedostatki samej architektury układu. Także IDE sprawdza się bardzo dobrze – pracuje jako Eclipse’owa nakładka na kompilator Keil C51, ale to bardzo dobrze zestawiony system, w dodatku generator kodu produkuje bardzo wysokiej klasy kod inicjalizujący sam układ i jego peryferia.

Układy z rodziny AVR – megaAVR i tinyAVR – to dwa zupełnie różne światy, dla zupełnie różnych osób, a jednocześnie układy, które mają najlepsze IDE dla ośmiobitowców. Układy megaAVR prezentują się dosyć kiepsko, ale nowe tinyAVR-y wydają się być bardzo wartościowymi MCU z szerokim wachlarzem peryferiów: ADC, DAC itp. a także nowy, 20 MHz wbudowany oscylator. Jednocześnie, te tinyAVR są tańsze niż mikrokontrolery z rodziny megaAVR o około 20..40%. Kolejnym problemem megaAVR jest także debuggowanie układu, wymagające z równoległego korzystania z dwóch interfejsów; nowe tinyAVR nie mają takiego problemu dzięki implementacji nowego interfejsu UPDI. Nowy tinyAVR może być doskonałym wyborem dla hobbystów, niezależnych developerów itp., z uwagi na swoją niską cenę i otwarte programatory. Nie jest to idealny MCU – nie jest zbyt szybki i jest mało wydajny, ale nadal dobrze radzi sobie w obliczeniach.

Atmel–Microchip wydaje się dywersyfikować swoją ofertę na część adresowaną do profesjonalnych deweloperów i tą dla hobbystów. Układy Atmela są niezwykle popularne wśród tych drugich, ale mimo to sama firma bezpośrednio nie angażowała się w kwestie promocji czy rozwoju sprzętu dla tych platform. Zamiast tego opierali się na zespołach pracujących nad otwartymi rozwiązaniami w tym zakresie, co było bardzo owocne w zakresie megaAVR. Niestety, trzeba powiedzieć to sobie szczerze – narzędzia stworzone w ten sposób są o rząd wielkości gorsze od tych, jakie dostarcza Atmel i nie wspierają np. nowych MCU z rodziny tinyAVR.

Oczywiście, jeśli kochacie debuggowanie poprzez printf() na port szeregowy, nie chcecie dotykać dedykowanych IDE itp., to układy takie jak megaAVR i tinyAVR są właśnie dla Was. Niektóre z nich dostępne są nawet jeszcze w obudowach DIP, a najtańsze programatory kupić bądź złożyć można za grosze. Środowisko programistów tych układów jest ogromne, więc wejście w tą architekturę jest bardzo przyjemne; trzeba przyznać, że w zakresie ośmiobitowych MCU nastawionych na otwarte środowisko to megaAVR po prostu wygrywa.

Do pełnego sukcesu AVRów brakuje jedynie ruchu ich producenta, który mógłby wypuścić niedrogi debugger z interfejsem UPDI i umożliwił debuggowanie z modułów uruchomieniowych, jak można to robić modułach w PIC Curiosity Board.

STM32F0 to bardzo sensowna rodzina układów z rdzeniem ARM, z chyba najlepszym ekosystemem deweloperskim wśród przetestowanych tutaj. Na szczególną uwagę zasługuje STM32CubeMX – nie generuje on może najlżejszego i kompaktowego kodu (w tym zakresie pierwsza pozycja okupowana jest przez PSoC Creatror i Infineon DAVE), ale jest tak intuicyjny, że korzystanie z niego jest niesamowicie proste. Uzupełnione to jest bardzo sprawnie działającym środowiskiem System Workbench i szeroką linią modułów uruchomieniowych z linii Discovery oraz Nucleo. Większość zawodowych deweloperów przynajmniej raz w życiu miała do czynienia z tymi układami.

Atmel SAM D10: Superwydajny mikrokontroler ze świetnymi peryferiami, ale niestety wyposażony w bardzo problematyczną bibliotekę. Układ D10, a w zasadzie cały ekosystem D10/D11/D20/D21 oferuje bardzo przyzwoitą wartość, szczególnie dobrą w zakresie modułów analogowych – ADC i DAC, a w dodatku SAM D10 był najwydajniejszym obliczeniowo układem w tym zestawieniu. Niestety dopóki producent nie upora się z powolnymi i ogromnymi bibliotekami dla peryferiów i średniej jakości narzędziami do generacji kodu.

Infineon XMC1100: Z pewnością najciekawszy układ z rdzeniem ARM Cortex-M0, głównie z uwagi na bogate i ciekawe peryferia. W szczególności developerzy dotychczasowo pracujący na układach ARM ze stajni STMicro, NXP czy Atmela mogą być zainteresowani układami z rodziny XMC1000 czy XMC4000. Doskonałe moduły analogowe uzupełniają elastyczne timery, itp. zawarte w module USIC. Układ ten może przypaść do gustu zarówno hobbystom, jak i zawodowcom, konstruującym systemy sterowania silnikami oraz oświetleniem – oprócz doskonałych konfiguratorów do inicjalizacji tych peryferiów, sam układ prościej będzie zastosować w urządzeniu, dzięki dostępności w obudowach TSSOP, a nie typowych QFN i QFP. W przypadku hobbystów jedynym czynnikiem ograniczającym może być niewielkie środowisko osób skupionych wokół tych układów. Warto jednak się nie bać i podjąć wyzwanie.

PIC16: Tona peryferiów z powolnym, ale energooszczędnym rdzeniem. To układy dedykowane do zastosowań w środowisku, gdzie pobór prądu jest istotny, przez co MCU nie zostało zoptymalizowane pod kątem wydajności obliczeniowej. Jeśli chodzi o środowisko deweloperskie, to to dostarczane przez Microchipa jest całkiem użyteczne, ale daleko mu do ideału. Pamiętać też trzeba o dosyć drogich debuggerach. PIC16 mają też całkiem bogaty zestaw peryferiów: od timerów po układy logiki programowalnej, które pozwalają odciążyć dosyć powolny CPU.

Żeby dolać oliwy go ognia sporu PIC vs AVR: 32 MHz PIC16 działa równie wydajnie, co AVR taktowany 1,4 MHz (w zakresie arytmetyki) lub 9 MHz (w zakresie przerzucania bitów na GPIO).

PIC24: droga alternatywa udająca MSP430, która nie osiągnęła sukcesu na rynku. Układ ten jest marginalnie szybszy od RL-78 Renesasa, ale zużywa trzy razy tyle mocy. Rodzina ta jest dosyć droga – układ przedstawiany w tym zestawieniu nie ma prawie w ogóle żadnych peryferiów aby mieć takie peryferia jak w lepiej wyposażonych układach w tym zestawieniu, trzeba wydać dużo więcej pieniędzy na MCU. Na to nakładają się typowe dla PICów problemy – średnie IDE i drogie debuggery, ale też i zalety – doskonałe wsparcie on-line, gwarancja stabilnej produkcji układów i obudowy: układ ten dostępny jest nawet w obudowach DIP.

PIC32 to doskonały układ, zachowujący równowagę pomiędzy mocą i wydajnością a zużyciem prądu. PIC32MM jest jednym z najciekawszych układów w tym zestawieniu, który pochwalić się może najmniejszym poborem mocy pośród 32-bitowych MCU. Niestety, jest to też najsłabszy numerycznie układ 32-bitowy, który w dodatku ma dosyć słabe portfolio peryferiów, ale nadrabia to trochę sporą ilością pamięci flash i RAM, a także charakteryzuje się prostą konfiguracją zegarów i peryferiów. Dodatkowo, ma sporo większych kuzynów – omawianych tutaj PIC32MM to tylko część rodziny OIC32, na przykład takie układy jak PIC32MZ DA to już bardzo mocne mikrokontrolery, na których można uruchomić Linuxa lub podobne zaawansowane funkcje etc. Oczywiście, układ ten ma takie same wady i zalety jak inne układy Microchipa – doskonałe wsparcie on-line, elementy dostępne w obudowach DIP, ale i ciężkie i mało wygodne IDE oraz drogie kompilatory i debuggery.

Renesas RL-78 to kolejny wartościowy układ w tym artykule. Nie jest on zbyt popularny w przemyśle, a szkoda, ponieważ warto chociażby spróbować się z nim zaznajomić, szczególnie, że oferowane są niedrogie (25 dolarów) moduły uruchomieniowe z tym MCU. Sam układ także jest niedrogi, szczególnie w porównaniu do MSP430 czy PIC24, z którymi bez problemu może konkurować dzięki wykorzystaniu całkiem mocnego rdzenia (ARM) i niewielkiemu poborowi mocy. Narzędzia deweloperskie, w tym oparte o Eclipse IDE tylko zachęca do wejścia w świat układów Renesasa.

Układy N76, HT66 oraz STM8 formują grupę tanich, ale całkiem ciekawych MCU. Te tanie ośmiobitowce (STM8S103F2P6 kosztuje zaledwie 38 centów) mają szereg ciekawych zastosowań, chociażby z uwagi na ekstremalnie niską cenę. Niestety układy te mają też szereg wad, między innymi bardzo archaicznie wyglądające i działające IDE oraz dosyć wysokie zużycie prądu. Z drugiej strony, darmowe IDE i inne narzędzia, oraz tanie debuggery sprawiają, że może być warto chociażby przyjrzeć się im bliżej.

Przy zastosowaniach profesjonalnych może zaboleć jedynie cena licencji Keil C51 dla N76, ale hobbyści i amatorzy mogą doskonale poradzić sobie w wersji darmowej z ograniczeniem do 2K kodu – w układ za 23 centy ciężko i tak ‘włożyć’ więcej programu.

STC8 to fajny element, ale raczej dla zaawansowanych hobbystów. Ma całkiem sporą wydajność, bogaty zestaw peryferiów i dosyć dużo pamięci, więc warto rozejrzeć się na AliExpress za tanimi (od 10 dolarów) płytkami uruchomieniowymi zarówno dla tego układu, jak i jego większego brata – STC15. Układy te są debuggowane po UART, więc nie wymagają nawet żadnego dodatkowego debuggera. Ich głównym problemem jest powolna obsługa przerwań – skok do funkcji to 10 cykli zegara, ponad 300 nanosekund.
ON Semiconductor LC-87: Pomiń. Po prostu pomiń. Obecnie układ ten spotykany jest jedynie w Japonii i tam wcale nie jest jest popularny. Nie ma co się dziwić: ogromne zużycie prądu, ubogie peryferia i najgorsze środowisko developerskie, jakie można sobie wyobrazić.

Układy Kinetisa: KL03 oraz KE04 są bardzo ciekawe, ale niełatwe w ujarzmieniu. KL03 oferuje superniski pobór prądu w uśpieniu, a KE04 szeroki wybór peryferiów. Z drugiej strony, układy te korzystają z dosyć trudnego w obsłudze IDE, płytki uruchomieniowe są dosyć toporne i słabo zadokumentowane, a narzędzia do generacji kodu także pozostawiają sporo do życzenia. Dodatkowo – układy te są w stanie współpracować z napięciem 5 V i są dostępne w obudowach SOIC z sensownym rastrem 1,27 mm, co czyni je bardzo proste do wykorzystania przez hobbystów.

LPC811: Układ ten ma kilka zalet, ale nie powtórzy fenomenu nieprodukowanego już LPC810, który przyciągnął ludzi swoim nietypowym formatem – ośmiopinowego DIPa. Niestety LPC811 jest bardzo ubogo wyposażony, nie posiada nawet ADC; nie jest też zbyt wydajny, ale nie oznacza to, że nie warto w ogóle wchodzić w linię tych układów od NXP – mocniejsze LPC wyposażone są nawet w dwa rdzenie ARM – Cortex-M4 oraz Cortex-M0 – a środowisko programistyczne – MCUXpresso – jest bardzo udaną implementacją na Eclipse.

Prezentowane w zestawieniu układy PSoC 4000S oraz [/b]MSP430[/b] mają jedną wspólna cechę – to najmniejsze z elementów z bardzo ciekawego i bogatego ekosystemu. Znajdziemy tam zaledwie kilka układów poniżej jednego dolara, ale wiele droższych i istotnie mocniejszych. Dla układów tych istnieje szereg bardzo fajnych i niedrogich płytek deweloperskich, a środowiska programistyczne są całkiem wygodne w obsłudze: PSoC Creator Cypressa pozwala na prostą konfigurację peryferiów analogowych i cyfrowych układu, a Code Composer Studio Texas Instruments, oprócz tego, że jest darmowy to pozwala na łatwą przesiadkę z Arduino – IDE to potrafi nawet importować niektóre szkice *.ino.

Ostatni element w tym podsumowaniu – M051 od Nuvotona to MCU wypełniony ciekawymi peryferiami, który jednak boryka się z dosyć problematycznym ekosystemem i środowiskiem deweloperskim. Dedykowany CooCox jest trudny, dosyć gęsto naszpikowany błędami, ale pozostaje jeszcze Keil, który błędów jest pozbawiony, ale ma tyle wrogów, co zwolenników. Sam mikrokontroler charakteryzuje się dosyć dużym poborem prądu, ale nadrabia to łatwymi w komunikacji timerami, bogatym portfolio modułów komunikacyjnych. Dopóki Nuvoton nie poprawi usterek w obecnym IDE, to nie warto zaprzątać sobie głowy tym MCU, jednakże wiele wskazuje, że ten bardzo tani układ z rdzeniem ARM doczeka się lepszego IDE.

Podsumowanie

Jak twierdzi autor zestawienia, podstawową obserwacją, jaką poczynił, jest to, że istnieje ogromna liczba nowych architektur, z których nigdy jeszcze nie korzystał, a które są obecnie bardzo łatwo dostępne. Dookoła nas powstaje wiele nowych ekosystemów dla MCU – jedne lepsze, drugie gorsze…

Każdy może wybrać coś dla siebie i nie ma w zasadzie jednej, dobrej opcji dla wszystkich. Czego innego poszukiwać będzie hobbysta, który dotychczasowo pracował tylko w ekosystemie Arduino i teraz pragnie „pójść dalej”, a czego innego profesjonalny deweloper, który może poszukiwać jakiejś dziwnej i rzadkiej architektury, która właśnie spełni jego wyrafinowane potrzeby. Zestawienie, wraz z komentarzem autora, jaki znajdziemy na jego stronie, powinno pomóc tak profesjonalistom, jak i amatorom w dokonaniu takiego wyboru.

Niezależnie jednak od tego, co wybierzemy i jakie są nasze potrzeby, przyznać trzeba, że żyjemy w doskonałych czasach dla systemów wbudowanych. Szeroki wybór różnych, niedrogich układów pozwala każdemu wybrać swoją drogę. Końcówka roku też jest dobrym momentem – może nauka nowej architektury MCU będzie postanowieniem noworocznym? Jeśli tak, to, który z powyższych układów przypadł Wam do gustu? Zachęcam do komentowania, dyskutowania, a także przedstawienia swoich opinii na temat przedstawionych powyżej MCU.

Źródło: https://jaycarlson.net/microcontrollers/#1509922081005-f6dc4fcd-547d