Układy wbudowane są wszechobecne w dzisiejszym świecie napędzanym technologią. Niezależnie od tego, czy jest to internetowo połączona maszynka do golenia, czy skomplikowany samochód, urządzenia wbudowane stanowią serce większości urządzeń elektronicznych, których dzisiaj używamy. Składające się z jednego lub wielu mikroprocesorów, systemy wbudowane mogą upraszczać elektronikę, przenosząc złożoność do obsługi przez oprogramowanie. W miarę jak urządzenia wbudowane stają się większe i bardziej skomplikowane, tak samo rosną płytki drukowane (PCB). Często urządzenia te rozrastają się do wielu płyt i stają się większymi zespołami niż pierwotnie zakładano.
W tym artykule przyjrzymy się kompromisom architektonicznym i rozważaniom dotyczącym systemów wbudowanych składających się z wielu PCB. Omówimy korzyści, rozważania projektowe i wyzwania związane z systemami wielopłytowymi.
Chociaż utrzymanie urządzenia na jednej płycie PCB jest idealną opcją (zarówno pod względem prostoty, jak i kosztów), czasami musimy podjąć decyzję o podzieleniu naszego projektu na dwie lub nawet więcej płyt PCB, aby osiągnąć nasze cele projektowe. Niektóre powody, dla których chcielibyśmy podzielić nasz produkt na wiele płyt, to:
Z tych (i innych) powodów rozważamy projektowanie zespołu składającego się z wielu PCB, ale wyzwania związane ze stroną wbudowanego oprogramowania nie są pozbawione swoich złożoności.
Teraz, gdy ustaliliśmy przypadek użycia wielu PCB (tam, gdzie to możliwe), ważne jest zrozumienie rozważań projektowych przy architekturze systemu wbudowanego. Zarówno z perspektywy sprzętowej, jak i programowej istnieją niuanse, które nie zawsze są tak starannie ważone, gdy umieszczamy wszystko na jednej płycie.
Pierwszą kwestią, która powinna przyjść nam do głowy, jest komunikacja między płytami. Jak każda płyta będzie komunikować się z innymi? Jaką moc obliczeniową (jeśli w ogóle) posiada każda z nich? Może jedna płyta składa się z "mózgu", a inne z czujników? Dokładnie wybierając nasze protokoły transmisji, czy to I2C, SPI, UART, Ethernet itp., musimy również zważyć linie transmisyjne, integralność sygnału i co najważniejsze, transfer sygnału przez złącza między płytami. Najgorszą rzeczą, która może przytrafić się projektantowi (i uwierzcie mi, byłem w tej sytuacji), jest zaprojektowanie całego systemu i otrzymanie PCB od producenta, tylko po to, by zdać sobie sprawę, że zabrakło sygnału zegarowego lub dwóch. Również często zapominamy o zostawieniu zapasowych pinów na naszych złączach między płytami, próbując maksymalnie wykorzystać każdy pin. To coś, co naprawdę może nas ugryźć na końcu. Projektowanie z myślą o projekcie wielopłytowym, takim jak funkcja montażu wielopłytowego w Altium Designer, jest koniecznością przy trasowaniu tak wielu linii komunikacyjnych między PCB.
Musimy również pomyśleć o tym, jak planujemy dystrybuować zasilanie, szczególnie jeśli będziemy monitorować magistrale zasilające za pomocą naszego mikroprocesora. Chcemy mieć dostęp do "mózgu", aby mógł on monitorować wszelkie katastrofalne zdarzenia, ale musimy również wziąć pod uwagę szumy zasilacza impulsowego, dystrybucję mocy dla dużych obciążeń i czy nasze piny złącza między płytami są przystosowane do tego rodzaju mocy.
Na koniec, choć nie jest to bezpośrednio związane z samym oprogramowaniem wbudowanego systemu, projekt mechaniczny również odgrywa ważną rolę. Przyciski, ekrany dotykowe i inne fizyczne interfejsy użytkownika nadal łączą się z mikroprocesorem i muszą być brane pod uwagę. Czy okablowanie można poprowadzić w taki sposób, aby mikroprocesor mógł uzyskać dostęp do swoich wejść? Czy wzięliśmy pod uwagę integralność sygnału cyfrowego o wysokiej prędkości, gdy przesyłamy go z jednej płyty na drugą? To są rzeczy, o których musimy pomyśleć, projektując nasze urządzenie wbudowane.
Jednym z najbardziej niedocenianych wyzwań, z którymi spotkałem się raz za razem w rozwijających się startupach (a nawet dużych firmach), była plaga schematów wersji między oprogramowaniem a sprzętem. Zarządzanie wydaniami oprogramowania w stosunku do rewizji PCB stało się niekończącą bitwą, która często prowadzi do zamieszania, opóźnień, a nawet niepowodzeń produktów.
Na przykład, w jednym ze startupów, z którymi pracowałem, drobna modyfikacja PCB wymagała ponownego opracowania i tym samym aktualizacji firmware (choć minimalnej). Z powodu słabej kontroli wersji zespół inżynieryjny wdrożył nowe oprogramowanie sprzętowe na starszych wersjach PCB, powodując nieoczekiwane zaniki napięcia i okresowe kłęby dymu. Na szczęście złapaliśmy to przed wysyłką produktu, ale to były absolutne koszmary przez długie dni.
Aby uniknąć tych pułapek, kluczowe jest ustanowienie solidnego schematu wersjonowania i zapewnienie jasnej komunikacji między zespołami sprzętowymi i oprogramowania. Nawet prosty schemat wersjonowania, taki jak hash Git (lub wersja semantyczna) dla firmware, wraz z podstawową tabelą wsparcia dla rewizji sprzętu, może być wystarczający na początek. W miarę upływu czasu bardziej zaawansowane mechanizmy, takie jak wykrywanie rewizji sprzętu w firmware (sprawdzając tym samym kompatybilność), również znacznie redukują pomyłki.
Oprócz wersjonowania oprogramowania ważne jest również myślenie o modularności kodu. W przypadku kodu spaghetti, wymiana płytki sensorowej na nowe chipy lub sensory może stać się koszmarem refaktoryzacji. Modularizacja sterowników urządzeń i tworzenie warstw abstrakcji sprzętu umożliwia łatwą wymianę komponentów na lata. Jest to coś, co stało się znacznie bardziej popularne, ponieważ systemy wbudowane z czasem stały się bardziej skomplikowane.
Kiedy myślimy o architekturze systemów wbudowanych, nie zawsze musimy myśleć mało. Statki kosmiczne i samochody to niezwykle skomplikowane systemy wbudowane, ale takie są również smartfony. Niezależnie od tego, czy projektujemy łyżkę podłączoną do internetu, czy kolejnego satelitę, zrozumienie kompromisów dla architektury systemów wbudowanych jest niezwykle ważne podczas projektowania dla wielu PCB. W tym artykule zbadaliśmy wiele koncepcji, ale jest jeszcze wiele więcej, które niewątpliwie znajdziesz na swojej drodze.