Zaloguj
Najnowsze, najszybsze, najpotężniejsze mikroprocesory i układy SoC
Firmy takie jak Qualcomm i Broadcom (ale nie tylko) oferują najpotężniejsze układy mikroprocesorowe do smartfonów, tabletów i innych gadżetów. Każdy chciałby okiełznać tę moc dla swoich celów i zaoferować klientom najpotężniejszy produkt w swojej klasie. Układy te często też mają potężne peryferia, każdy możliwy interfejs, akcelerator grafiki czy enkoder/dekoder różnych formatów, a nawet wsparcie dla sieci neuronowych i AI. Dlatego trafiają one do najnowszych smartfonów od czołowych producentów na rynku. Jeśli jednak nie pracujesz dla jednej z tych firm, tylko dla mniejszego biznesu, którego nazwa zaczyna się od imienia lub nazwiska właściciela, a kończy się na „-ex” lub „-eks”, to Qualcomm, Broadcom czy inni nawet nie dadzą Ci dostępu do dokumentacji technicznej poza skróconą broszurą informacyjną, zachwalającą ich produkt. Każda nota katalogowa wymaga podpisania umowy NDA (Non-Disclosure Agreement – umowa o zachowaniu poufności), co samo w sobie może zająć miesiące, bo mała firma z Polski jest na końcu listy potencjalnych klientów, gdzieś między klientami z Kambodży i RPA. Potem trzeba zapoznać się z wyjątkowo skomplikowanym układem, pobawić się sterownikami, które mogą być niepełnosprawne (w końcu to coś nowego) przy braku wsparcia technicznego (ponownie, w kolejce między firmami z Peru i Łotwy). Na koniec nadejdzie czas zamówienia układów i padnie pytanie ze strony producenta:
– Sto tysięcy układów wam wystarczy na początek?
– Myśleliśmy o dwóch tysiącach – odpowiecie.
– Dla dwóch tysięcy to nam się nie opłaca umowy drukować. Minimum 25 tysięcy, albo spadajcie.
No i tak umierają sny o technologicznej supremacji małej firmy z Polski. Megakorporacje mają o wiele łatwiej, bo zwykle składają zamówienia idące w dziesiątki milionów na kolejne, coraz potężniejsze modele układów i inne komponenty, od modułów radiowych po kontrolery USB. Dlaczego? Proste: kupując u jednego producenta oszczędza się na wysyłce. Nawet kilka centów na sztuce robi różnicę, gdy potrzeba miliona komponentów.
Co zatem powinien robić mądry projektant w małej firmie o nazwie kończącej się na „-ex”? Zamówić najmniejszy, najtańszy i najprostszy mikroprocesor, mikrokontroler czy SoC, który wykona potrzebne zadania. Microchip czy ST Microelectronics nie robią problemów, gdy chce się zamówić nawet kilka sztuk układów, mają bogatą ofertę mikrokontrolerów na każdą kieszeń i na każdą potrzebę, a i większość not jest dostępna do pobrania ze strony WWW. Razem z IDE. Tanio, prosto i bez NDA. Zastanówmy się poważnie, czy najnowszy element automatyki domowej albo miś-szumiś potrzebuje ośmiordzeniowego Snapdragona, czy może wystarczy jakaś prymitywna ATMega albo czy mizerny PIC16F? No w ostateczności STM32 albo moduł z ESP8266.
Układy ASIC
Możliwość zaprojektowania układu „szytego na miarę” to kusząca perspektywa. Układy takie potrafią robić rzeczy normalnie wymagające dziesiątek scalaków i setek elementów dyskretnych, a do tego oferują to wszystko w małym, tanim opakowaniu. W końcu bijącym serduszkiem każdego współczesnego oscyloskopu cyfrowego jest zazwyczaj układ ASIC, szczególnie w tych lepszych modelach. Sinclair w latach 80. zoptymalizował koszty produkcji swoich tanich, ośmiobitowych komputerów przez użycie układu ULA (Uncommitted Logic Array – nieprzypisana tablica logiczna), w którym producent najpierw wykonuje dużą liczbę identycznych bramek logicznych, jedna koło drugiej, a potem nanosi metalowe połączenia według zlecenia klienta. W ten sposób można wyprodukować jeden układ scalony w dziesiątkach milionów, a potem dostosować go do potrzeb wielu różnych klientów. Układy ULA były formą układów ASIC do zadań cyfrowych. Ich produkcja była skomplikowana, dlatego w klonach komputerów Sinclair zastępowano je wieloma układami logicznymi.
Obecnie te same funkcje realizują układy FPGA i CPLD, zaś nowoczesne układy ASIC mogą zawierać nie tylko elementy logiczne, ale też bloki analogowe, super-szybkie układy ADC i DAC, własne, dedykowane i zaprogramowane na poziomie fizycznym kontrolery i wiele innych. Układ ASIC może realizować szybką konwersję sygnałów analogowych na postać cyfrową, dalsze ich przetwarzanie, akumulację i analizę, a także przesyłanie obrobionych danych jakimś szybkim interfejsem. Dodajmy do tego możliwość integracji modułu RF dowolnego typu albo dodatkowego mikroprocesora czy mikrokontrolera i mamy przepotężne narzędzie do realizacji dowolnych zadań.
Skoro zatem układy ASIC są tak potężne i stosowane od szeregu lat, to dlaczego odradzam ich stosowanie? Pierwszym problemem jest konieczność zaprojektowania takiego układu i jego przetestowania. Często oznacza to kilka iteracji, jeszcze zanim powstanie gotowy układ. Kto za to zapłaci? Oczywiście klient. Koszty idą w dziesiątki milionów dolarów, jak nie więcej. Część użytkowników tych układów tnie koszty projektując je we własnym zakresie, opierając się o symulacje i własne doświadczenie, zanim zlecą wykonanie próbnej partii. Nawet jeśli układ nie do końca spełnia oczekiwania, to i tak może być wdrożony, bo wykonywanie masek do fotolitografii układów scalonych jest najdroższą częścią procesu produkcji półprzewodników. Potem pojawia się problem wolumenu, omówiony w poprzednim punkcie. Minimalne zamówienie układów ASIC liczy się w dziesiątkach tysięcy, a im mniejsza partia, tym droższa pojedyncza sztuka. Małej firmy nie będzie na to stać.
Co pozostaje zamiast ASIC-ów? Droga klonów ZX Spectrum: wszystko robić „na piechotę”. Logikę zastąpi pojedynczy układ FPGA lub CPLD, bloki analogowe i przetworniki już trzeba robić na pojedynczych układach scalonych czy nawet tranzystorach. Można też wybrać jakiś mikrokontroler, który ma potrzebne elementy składowe pośród peryferiów i iść tą drogą. Wszystko zależy od rodzaju problemu do rozwiązania. Na rynku dostępnych jest wiele układów przeznaczonych do specyficznych zadań, więc nasz niezintegrowany ASIC można z nich składać, jak z klocków LEGO, korzystając z projektów referencyjnych i not aplikacyjnych. Całość będzie duża i droga, ale i tak tańsza i mniej bolesna w realizacji, niż zamawianie jednego układu do wszystkiego.
AI i uczenie maszynowe
Bądźmy szczerzy, AI od kilku lat jest tematem numer jeden wszędzie tam, gdzie mówi się o zaawansowanych technologiach, a istniejące algorytmy – jak Gemini czy ChatGPT – odmieniają świat od momentu pojawienia się ich pierwszych wersji. Tysiące ludzi straciło też pracę przez różne algorytmy, które miały ich zastąpić, a największym beneficjentem zaawansowanych modeli stali się oszuści i przestępcy. A także twórcy zbyt leniwi, by robić własne treści – więc je w stu procentach generują i wrzucają na platformy społecznościowe. W tej chwili „próg wejścia” jest relatywnie niski i każdy może pobawić się modelem LLM albo nauczyć sieć neuronową, aby grała w różne gry komputerowe – i nie potrzebuje do tego superkomputera, wystarczy kilkuletni pecet. Ba, do zabawy w uczenie maszynowe wystarczy nawet Raspberry Pi, a projekty w rodzaju OpenCV pozwalają tworzyć automatyczne wieżyczki strzelające wodą do obcych kotów próbujących zbezcześcić czyjś ogródek (tak, jakiś hobbysta wykonał taki projekt). Nic dziwnego, że każdego kusi dodanie odrobiny sztucznej inteligencji do swojego projektu. Ale czy jest sens inwestować w to czas i pieniądze? Jeśli nie budujesz nowego, lepszego robota sprzątającego albo wojskowego drona do obrony polskich granic czy autonomicznego samochodu, to nie potrzebujesz AI. Sieć neuronowa nie usprawni termostatu ani nie polepszy ściemniacza światła. Nie sprawi, że smartwatch będzie bardziej „smart”. Nawet w przypadku robotów sprzątających ich „inteligencja” opiera się na szeregu czujników i maszynie stanów skończonych, a „mapowanie przestrzeni” to inna nazwa na algorytm mierzący przejechaną drogę i miejsca, gdzie czujniki dały znać, że nie da się wjechać. System nawigacji, gdzie zna się punkt początkowy i zapamiętuje pokonaną trasę, jest znany od drugiej wojny światowej, jeśli nie dłużej. I był stosowany przez różne wojska zanim powstał GPS czy jego przodek, system nawigacji satelitarnej amerykańskiej marynarki wojennej (dokładny opis jest dostępny tutaj: https://www.youtube.com/watch?v=VDUiI_MmvL4). Wracając do problemu odkurzacza autonomicznego: wszystkie jego funkcje da się zrealizować używając odrobiny naturalnej inteligencji w planowaniu rodzaju i rozmieszczenia czujników oraz innych elementów. Dodanie sieci neuronowej (wymagającej sporej mocy obliczeniowej lub dedykowanego akceleratora) nie da tu żadnej przewagi nad prostym wykrywaniem przeszkód i zapamiętaniem pokonanej trasy albo rozpoznawaniem stacji bazowej po podczerwonych światłach nawigacyjnych, nadających specyficzny kod. Poziom naładowania baterii oraz zapełnienia pojemnika na kurz i inne śmieci też nie wymaga niczego bardziej rozbudowanego, niż proste komparatory (zapchany pojemnik zmienia pobór prądu silnika turbiny ssącej). Zatem Czytelniku, zanim wpadniesz na pomysł dodania do projektu sztucznej inteligencji, zastanów się, czy można to samo zrobić na układach analogowych lub na prostym mikrokontrolerze.
Chmura
Kilka lat temu tysiące Amerykanów niemal zamarzło na śmierć (przynajmniej tak o tym donosiły media), gdy termostaty Google Nest straciły kontakt z chmurą. Inny start-up oferował własny system domowej automatyki z dożywotnim dostępem do swojej chmury, opłaconym częścią marży za urządzenia. Klientom nikt nie powiedział, że chodziło o żywot samej firmy, więc jak ta splajtowała, ich kosztowe urządzenia stały się tonami elektrośmieci. Jeszcze inna firma w podobnej sytuacji była uprzejma udostępnić użytkownikom aktualizację firmware i narzędzia pozwalające automatyce działać bez chmury. Jeśli coś wymaga chmury do działania, unikam tego – i to samo radzę innym. Z punktu widzenia użytkownika końcowego „chmura” trzyma jego dane i jego urządzenia jako zakładników, a jej właściciel może w każdej chwili odciąć dostęp albo wprowadzić opłaty abonamentowe za coś, co kiedyś było darmowe lub za co płaciło się tylko raz. Od strony właściciela chmura oznacza koszt utrzymania infrastruktury, wyższy niż w przypadku produktów wymagających jednorazowej aktywacji online. Chmura częściej dotyka oprogramowania niż sprzętu, ale i sprzęt też bywa ofiarą „zachmurzenia”. Szczególnie automatyka domowa i elektronika dla sportowców padają ofiarami tego rozwiązania. Dla przykładu: moja opaska sportowa zapisuje moje wyniki do pamięci smartfona gdy jestem offline, ale jeśli chcę przenieść te dane do nowego urządzenia, to już potrzebuję przejść do trybu online, by zsynchronizować moje konto w chmurze producenta. Na szczęście właściciel owej chmury raczej prędko nie zbankrutuje.
Poza problemami finansowymi korporacji i ofiar… ekhm, użytkowników ich usług, mamy jeszcze trzy potencjalne problemy z chmurą. Pierwszy to problem z infrastrukturą po stronie producenta. Za mała liczba lub moc serwerów albo błędy konfiguracji mogą doprowadzić do przeciążenia ilością zapytań. Drugi problem to błąd w oprogramowaniu serwerowym, który przy wgraniu na serwer produkcyjny może spowodować awarię. Takie rzeczy zdarzały się wielkim korporacjom z najróżniejszym oprogramowaniem serwerowym. Trzecim problemem może być błąd w projekcie urządzenia. Dla przykładu opaska lokalizacyjna, którą kupiłem córce, nie była w stanie złapać sygnału sieci przez nawet jedną ścianę. Oprogramowanie klienckie na smartfonie też ledwo działało, bo było byle jak napisane. Dlatego nie polecam chmur w ogóle, a dla domowej elektroniki szczególnie. Jeśli jednak dział marketingu nie odpuszcza, to proszę: dodawajcie możliwość sterowania urządzeniem offline. Nie narażajmy biednych Amerykanów na zamarzanie, bo termostat przestał działać z powodu braku dostępu do sieci.
Interfejsy dotykowe
Nie lubię interfejsów dotykowych w urządzeniach domowych. Nie dlatego, że same w sobie są jakoś szczególnie złe, lecz dlatego, że często bywają źle zrealizowane. Projektanci decydują się na to rozwiązanie, bo wykonywanie panelu kontrolnego jest nieco prostsze: zamiast przycisków, pól stykowych i gumek czy membran wystarczy dać płytkę z gołymi polami i prostym układem interfejsowym. I to doprawdy nie jest problem. Sam projektowałem tego typu interfejsy oparte o metodę CVD (Capacitive Voltage Divider – pojemnościowy dzielnik napięcia). Problemem jest fizyczna implementacja takiego panelu. Czytelniku, zastanów się teraz, jak wiele urządzeń w Twoim życiu kontrolujesz bez patrzenia na fizyczne manipulatory: przełączniki, przyciski, pokrętła czy dźwignie. Już? Dobrze, to teraz pomyśl sobie, że musisz bez patrzenia dotknąć konkretnego pola lub ikony na płaskiej powierzchni. Jest to na tyle trudne, że niewidomi i niedowidzący, korzystając ze smartfonów, mają do dyspozycji specjalną funkcję, która mówi na głos, co właśnie zostało dotknięte na ekranie, a żeby daną ikonę czy funkcję „kliknąć”, trzeba stuknąć palcem dwa razy. Smartfon z ekranem dotykowym jest zatem użyteczny nawet bez zmysłu wzroku. Ale czy można dodać taką funkcjonalność do, na przykład, maszynki do produkcji lodów w domu? Albo do popularnego ostatnio air fryera? Teoretycznie nie, bo istnieje przynajmniej jedna, otwarta biblioteka dla Arduino, która implementuje prosty sposób syntezy mowy oparty o architekturę Linear Predictive Coding, opracowaną dekady temu przez Texas Instruments.
Biblioteka ta nazywa się Talkie i jest do odnalezienia na Githubie. Projektant może pomyśleć: „O, sam podsunąłeś rozwiązanie tego problemu”, ale o ile rozwiązanie istnieje, to nie jest ono do końca praktyczne. Jak wielu użytkowników niepotrzebujących takiej funkcjonalności zirytowałoby się, gdyby ich maszyna do lodów czy smażenia na gorącym powietrzu cały czas do nich gadała i wymagała dwukliku, by zarejestrować dotknięcie pola dotykowego? Ponadto może być potrzebny nieco większy mikrokontroler, a i trzeba dostosować algorytm interfejsu do współpracy z syntezą mowy i dodać jakiś sensowny głośniczek, bo membrana piezo może, delikatnie rzecz ujmując, nie dać rady.
Jest prostsze, tańsze rozwiązanie niewymagające zmiany w elektronice urządzenia: dajcie wypukłe krawędzie wokół pól dotykowych! Wtedy nawet bez patrzenia można wyczuć, gdzie jest krawędź pola, a przesuwając palcem wzdłuż niej dojść do pożądanego pola i je dotknąć. Ta jedna, prosta zmiana ułatwiłaby życie nie tylko niewidomym i niedowidzącym, ale też i innym ludziom. Sam planuję zaprojektować i wydrukować na drukarce 3D nakładkę z otworami na pola dotykowe osuszacza powietrza, bo mam z nim dwa problemy: gdy chcę go włączyć lub wyłączyć, to macam cały panel z jednej strony, aż trafię na pierwsze pole dotykowe. Drugim problemem jest fakt, że kotka, przebiegając po osuszaczu, sama go włącza bądź wyłącza albo zmienia inną funkcję swoją łapą. Zresztą niektórzy już praktykują tego typu rozwiązania od lat, a przykładem są dotykowe przyciski na przejściach dla pieszych, gdzie właściwe pole jest celowo zagłębione, by przypadkiem go nie aktywować, a jednocześnie by dało się je odnaleźć. Podobne rozwiązanie, tylko z polem na wypukłym krążku odcinającym się od podłoża, spotyka się niekiedy w komunikacji miejskiej i w pociągach. Często z wypukłą ikoną albo napisem brajlem. To są proste rozwiązania, które kosztują tyle co dodatkowa porcja tworzywa w formie. Dlaczego projektanci tego nie robią?
I tak dalej...
Technologii, których bym nie polecał zwłaszcza małym graczom. Przykładem mogą być akumulatory zamawiane „na wymiar”, szczególnie w urządzeniach przenośnych. Kosztują znacznie więcej, niż standardowe rozmiary, a nie oferują nic więcej niż kilka(-dziesiąt) dodatkowych mAh. Podobnie projektowanie własnych obwodów RF do układów scalonych oferujących jakąkolwiek łączność radiową – te z kolei wymagają certyfikacji, a im wyższa częstotliwość, tym bardziej złożony jest problem projektowania obwodów radiowych, nawet jeżeli to tylko antena mikropaskowa i obwód dopasowujący impedancję. Lepiej i taniej kupić gotowy moduł ze wszystkimi certyfikatami, z opcjonalną zewnętrzną anteną. Generalnie z wieloma technologiami mały gracz ma dwa problemy: wysokie koszty początkowe i koszty stałe oraz brak doświadczenia w implementacji. Na tym drugim problemie duzi gracze też się potykają, vide niedziałające termostaty czy osuszacz sterowany kotem. Dlatego pamiętaj, Czytelniku, by nie mnożyć bytów bez potrzeby, a ponadto, że lepsze jest wrogiem dobrego.
Paweł Kowalczyk, EP
