Nucleo i SBC

[karkul]

Czy integrowanie SBC np. Raspberry  z płytką typu nucleo ma sens? Chodzi mi o to czy używanie nucleo itp. jako pośrednika między czujnikami, sterownikami silników a raspberry lub innym SBC na którym znajduje się główny program odpowiadający za pracę robota  jest wydajne i czy ma sens ? 

Edytowano Luty 9, 2021 przez karkul

[H1M4W4R1]

Dla każdego rozwiązania znajdzie się sensowna sytuacja i na każdą sytuację znajdzie się sensowne rozwiązanie. Tutaj zaletą jest to, że Nucleo ma znacznie większą ilość portów nad Raspberry Pi.

Magistrale

Czy jest to wydajne? To zależy - od wielu czynników, w szczególności od implementacji. Przykładowo - UART w STM32 jest zwykle ograniczony do 115.2kbps. To dość śmieszna wartość, jednakowoż w wielu przypadkach wystarcza (np. sterowanie przekaźnikami). SPI zwykle potrafi rozbujać się do 18 Mbit/s czasem nawet do 50Mbit/s. To dość przyjemne wartości, ale należy pamiętać, że magistrala SPI jest mocno podatna na zakłócenia i bit-shift jeżeli nie implementujesz CRC. Trzecie rozwiązanie to USB - zwykle 12Mbit/s. Tutaj zaletą jest to, że możesz podłączyć całkiem sporo urządzeń.

Raspberry Pi - USB

Raspberry Pi 4B obsługuje dwa zestawy USB - USB2.0 jest kontrolowane przez SoC i działa z prędkością 480Mbit/s oraz USB3.0 obsługiwane przez kartę PCiE wbudowaną w płytkę i obsługującą do 4-5Gbit/s. Teoretyzując dalej - możesz podłączyć HUB USB i rozdzielić sobie tą przepustowość na kolejne urządzenia np. USB3 rozdzielić na USB2.0 poprzez HUB, tylko tutaj trzeba być ostrożnym, bo często lubi się coś zepsuć. (I2C z reguły nie używam to się nie wypowiadam)

Bezpośrednio do Raspberry

Z drugiej strony mamy obsługę Raspberry - posiada kilka złącz SPI i UART, jednakowoż musimy między nimi dość mocno wybierać. W moim odczuciu jeżeli obsługujesz kilka czujników lepiej to zrobić bezpośrednio na malince (o ile czujniki, gdzie występują wysokie napięcia są separowane od malinki).

Zaleta koprocesora

W przypadku jak podłączasz miliard czujników dość sensownym wydaje się zastosowanie oddzielnego ko-procesora do sterowania nimi i przekazywania informacji np. po USB. Dość ważną zaletą Twojego rozwiązania jest też to, że Raspberry może być uruchamiane tylko w przypadku potrzeby np. diagnostyki, a czujniki mogą przesyłać dane do ko-procesora, który by to zapisywał w pamięci np. W25N01 (1G-bit), lub na karcie SD.

Ale jednak zawsze spadnie wydajność przesyłu

Tylko pamiętaj, że stosowanie kolejnych ścieżek przesyłu danych zawsze wpłynie negatywnie na wydajność, bo zaczną występować opóźnienia. Stąd najlepiej krytyczne systemy podłączać bezpośrednio do RPi, a te mniej ważne np. jakiś przekaźnik sterujący oświetleniem do zewnętrznego koprocesora. Więc by było to opłacalne musisz zmniejszyć też ilość danych do przesłania (np. poprzez wstępne przetwarzanie).

Co doczytać i sprawdzić?

Poczytaj o poszczególnych magistralach i sprawdź sobie w STM32CubeMX jakie są limity danego MCU. Wtedy zobaczysz czy to będzie wydajne dla Twojego projektu. Oczywiście na MCU możesz też implementować część logiki, która będzie go kontrolowała, dzięki czemu zmniejszysz obciążenie Raspberry.

Podsumowanie

Wszystko zależy od implementacji, jak opiszesz projekt to może uda się to lepiej przeanalizować. Tutaj masz przykład płytki PCB z koprocesorem. Jeden CPU odpowiada za zarządzanie statkiem powietrznym, a drugi za nawigację. 

Krótko podsumowując - jeżeli tylko odczytujesz dane to nie ma to sensu, jeżeli je przetwarzasz i zwracasz w przetworzonej postaci do malinki (jak np. powyższy koprocesor nawigacyjny) to już jak najbardziej ma to sens. 

[FlyingDutch]

cześć,

poleciłbym w takiej sytuacji STM32MP1x - patrz linki:

https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html

Masz tam dwa rdzenie ARM Cortex-A7 na których możesz bez problemu uruchomić Linux'a i rdzeń Arm Cortex-M4 (do zadań czasu rzeczywistego). Dostępne są oczywiście zestawy uruchomieniowe np, taki:

https://pl.farnell.com/stmicroelectronics/stm32mp157a-dk1/discovery-kit-32bit-cortex-a7/dp/3014291?mckv=sJDWRRLv0_dc|pcrid|491302916579|plid||kword||match||slid||product|3014291|pgrid|115905808523|ptaid|pla-892525730827|&CMP=KNC-GPL-GEN-SHOPPING-EmbededComp-DoublePresence_13_01_2021

Oraz moduły SOM, które można osadzić we własnym PCB:

https://somlabs.com/product/visionsom-stm32mp1-stm32mp157/

Korzystając z takiego rozwiązania masz jakby "all in one" SBC i Cortex-M4 (jak na Nucleo) na jednej płytce. No i jest dostępnych wiele przykładów kodu w języku C. Do inicjacji układów peryferyjnych możesz generować kod w STM32CubeMX.

Pozdrawiam

Edytowano Luty 9, 2021 przez FlyingDutch
update

[Treker (Damian Szymański)]

W nawiązaniu do powyższego od razu podrzucę 2 linki do artykułów z bloga:

• Co warto wiedzieć o STM32MP1? Jak zacząć?
• Czym są moduły SOM? Przykład na bazie VisionSOM-6ULL

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[H1M4W4R1]

1 godzinę temu, FlyingDutch napisał:

poleciłbym w takiej sytuacji STM32MP1x - patrz linki:

https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html

Spojrzałem i pierwsze co mi przyszło na myśl, to ile mikrokomputerów wejdzie na jednego ATX'a 😄 Myślałem zbudować sobie mały klaster do obliczeń równoległych (wydajność nie jest istotna, liczy się ilość rdzeni procesora) do symulacji zachowania graczy w grach mobilnych (tutaj niestety odpadają obliczenia na GPU).

No i niestety te STMy są na BGA, więc lutowanie to tragedia... 😄 Chociaż cena całkiem fajna, bo tylko 30-40 PLN/szt. Ale nadal... ciężko nawet stwierdzić, czy da radę zamówić takie PCB u tanich dystrybutorów - zwykle minimum ścieżki to 4-5mil (nawet jak piszą, że mogą mniejsze to często odrzucają)...

No ale 3x USB2.0 (do tego jakiś HS8836A, CH340 i MAX232) i mamy całkiem przyjemny komputerek z obsługą kilku złącz RSA-232 oraz kilkunastu USB 😄 (wprawdzie prędkości nie będą piorunujące, no ale coś za coś..., plus jest taki, że złącza USB możemy też wykorzystać do wewnętrznej komunikacji z koprocesorami np. STM32L432KBU6)

Osobiście raczej bym obstawał przy używaniu Rasberry, chyba, że ktoś ma odrobinę doświadczenia w projektowaniu PCB (albo dostęp do zasobów uczelni wyższych, bo one często potrafią wynegocjować fajne ceny na komponenty (pozdrawiamy ceny złącz SODIMM200...))

W każdym razie dodane do listy "Maybe ToDo" 😄 Aktualnie zamówiłem płytki, na których ćwiczyłem sobie routing USB2.0 HS (hub usb) na HS8836A, zobaczymy jak pójdzie, jak będzie działać to można się pokusić o coś trudniejszego jak te SoC od STM...

EDIT:

chwilę pogrzebałem, by wyrobić sobie porównanie i patrząc na SOM oraz RPI dochodzę do wniosku, że raczej lepsze rozwiązanie to RPI z koprocesorem. RPI celowo było wybrane odrobinę tańsze, by zostawić margines na koszty koprocesora oraz komponentów pasywnych. Złącza Hirose są bardziej dostępne i tańsze niż SODIMM'y, a dodatkowo znacznie bardziej stabilne jeżeli chodzi o trzymanie płytki, chociaż tutaj niektóre SODIMMy też są twarde 😄 

Niestety Forbot nie ma tabelki w edytorze... Jak tak można?! Więc będzie to trochę brzydko sformatowane:

VisionSOM-6ULL

Cena: 188.20 PLN
CPU: 792MHz (x1)
NAND/eMMC/SD: 256MB NAND
Złącze: SODIMM200
RAM: 256MB
Łączność (high-grade): USB 2.0 (x2), Ethernet 10/100 (x2)
Łączność (low-grade): I2C (x4), SPI (x4), CAN (x2), UART (x8)

Raspberry Pi CM4

Cena: 169.00 PLN
CPU: 1.5GHz (x4)
NAND/eMMC/SD: 8GB eMMC
Złącze: 2x Hirose 100-pin
RAM: 2GB
Łączność (high-grade): USB 2.0 (x1), Ethernet 10/100/1000 (x1), PCIE 2.0 (x1)
Łączność (low-grade): I2C (x6), SPI (x5), UART (x6)

Jedyna wada Raspberry pokazuje się odrobinę mniejsza ilość portów i złącza Hirose, które jednak są znacznym ułatwieniem np. przy routingu, ale zajmują ogromną przestrzeń na płytce (SODIMM może być ustawiony również wertykalnie), aczkolwiek są już PCB, które pozwalają wpiąć CM4 do SODIMM'ów, więc to też raczej kwestia gustu.

Jakbym miał robić jakiś projekt to głównym kryterium raczej byłaby przestrzeń niż możliwości modułu, wtedy SOM ma znaczną przewagę na CM. W innym przypadku zwykle wybór padłby na CM4 i koprocesory np. STM32L432KBU6.
 

Edytowano Luty 9, 2021 przez H1M4W4R1

[karkul]

@H1M4W4R1 Polecał byś jakieś alternatywy dla rpi ? Bardziej wydajniejsze / praktyczniejsze...

Bardziej przystosowane do niekorzystnych warunków.

Edytowano Luty 9, 2021 przez karkul

[H1M4W4R1]

11 minut temu, karkul napisał:

Polecał byś jakieś alternatywy dla rpi ?

Zależy czego potrzebujesz. Postaram się to opisać w przejrzysty sposób.

Jeżeli coś ma działać w niekorzystnych warunkach to polecam silikon lub żywicę epoksydową (w zależności od preferencji, tylko uwaga na żywice z wysokim skurczem, bo mogą zniszczyć PCB) 😄 

Raspberry Pi 4B

To będzie punkt odniesienia - zwykłe Raspberry, malinka jak każda inna - 2GB RAM, WiFi, Internet 1Gbit/s, dobra do zastosowań typu domowy serwer danych np. MQTT czy NAS (robiony tanim kosztem).

Rockchip

Rockchipy (Pine64) z reguły są wydajniejsze od Raspberry (a zarazem też potrzebują lepszego chłodzenia) - polecam przejrzeć wersje z RK3399.

Lattepanda

Big power comes with a great price (on your electricity bill) - cytując klasyka. Bardzo wydajne komputerki, aczkolwiek dość drogie. Ich główna zaleta to bezproblemowe wsparcie dla Windowsa 🙂 

Banana Pi M3

Cena: przesadzona, ilość rdzeni? Też... 8 rdzeni procesora z niedużą ilością RAMu - najlepiej stosować głównie w miejscach, gdzie liczy się szybkie wykonywanie obliczeń równoległych, które nie mają dużego zapotrzebowania na RAM 😄 

Orange Pi Zero

Cena: niska, możliwości: ogromne (kupowałem jak stało 74PLN/szt) 4-rdzeniowy procesor 1.2GHz plus 512MB RAM (niestety tylko DDR3), złącze ethernet 10/100. Bardzo dobry wybór w miejscach, gdzie nie potrzeba dużo RAM'u, a liczy się ilość rdzeni. Wadą jest też dość wolne połączenie internetowe, aczkolwiek za tą cenę to nadal dość interesujący wybór. Uprzedzam: jest problem z włączeniem SSH, bo trzeba się łączyć po COM 😄 

Ogólnie to tylko kilka przykładów, Rockchip, Lattepanda i Banana PI na bazie informacji od kumpli. Osobiście posiadam RPi 0, RPi 4B oraz OPi 0. W kwestii wyboru między OPi/RPi0 to raczej preferuję OPi0.

Płytkę / narzędzia zawsze wybierasz względem tego co mają wykonywać - przecież nie będziesz wkładał komputera obliczeniowego do przełączania jednego przekaźnika 😉 

A tutaj podręczna lista.

[karkul]

@H1M4W4R1 Dzięki za fajne zestawienie. Rozglądam się już od jakiegoś czasu za różnymi płytkami oraz technologiami w kontekście przyszłych projektów.

Edytowano Luty 10, 2021 przez karkul

[Harnas]

2 godziny temu, H1M4W4R1 napisał:

Uprzedzam: jest problem z włączeniem SSH, bo trzeba się łączyć po COM

Swego czasu bawiłem się Orangepi Zero i nie kojarzę abym musiał się łączyć po porcie szeregowym.

Minus tego Orangepi Zero jest taki że strasznie się grzeje, i nawet z małym radiatorem przy pełnym obciążeniu dość szybko nagrzewa się chyba do 75 stopni gdzie następuje throttling rdzeni do 500Mhz. Więc na dłużej niż 5 minut mamy tak naprawdę mniej niż połowę deklarowanej mocy obliczeniowej.

[H1M4W4R1]

1 godzinę temu, Harnas napisał:

Swego czasu bawiłem się Orangepi Zero i nie kojarzę abym musiał się łączyć po porcie szeregowym.

Zależy pewnie jaki system stawiałeś - u mnie był to Armbian, nawet sshd nie było zainstalowane 😄 Co do grzania to nie jest aż tak źle, ale jestem człowiekiem wentylatorów... praktycznie wszędzie gdzie jest >45*C ląduje wentylator 😄 Zwykle 60*C nie przekracza 😉 

[FlyingDutch]

Cześć,

moduły z STM32MP1x nie mają konkurować z SBC, zostały wymyślone w trochę innym celu ;). Jeśli potrzebujemy MCU czasu rzeczywistego (rdzeń Cortex-M4) i na dodatek coś żeby zrobić np. wizualizację, czy rejestrowanie danych wtedy idealne są STM32MP1x. Te dwa rdzenie Cortex-A7 są jakby "na dokładkę" aby można na nich np. odpalić Linux'a i zrobić na nim np. GUI aplikacja w QT czy GTK. Zaleta jest taka, że do obsługi rdzenia Cortex-M4 i rdzeni Cortex-A7 (inicjalizacja peryferiów) możemy użyć jednego narzędzia STM32CubeMX (STM32CubeIDE nie obsługiwał tych MCU, nie wiem jak to wygląda na dzień dzisiejszy).

Jest gotowa biblioteka do synchronizacji (przesyłania danych między rdzeniami). No i najważniejsze mnóstwo peryferiów - dla mnie bardzo istotne były kontrolery CAN'a (co prawda na STM32MP1 mamy CAN'a FD, ale bardzo dobrze działa on w trybie zgodności z CAN'em "klasycznym"). Linux też jest dużo bardziej zoptymalizowany (OpenSTLinux), możemy używać też meta-dystrybucji Yocto i zbudować sobie Linux'a na miarę potrzeb. Poza tym płytkę z modułem SOM możemy obudować własnym PCB też "szytym na miarę potrzeb" (z podzbiorem potrzebnych układów peryferyjnych). Co ważne jest sporo przykładów obsługi różnych układów peryferyjnych na stronach i forum STM (a takż w repo CubeMX).

Pozdrawiam

18 godzin temu, Harnas napisał:

Swego czasu bawiłem się Orangepi Zero i nie kojarzę abym musiał się łączyć po porcie szeregowym.

Minus tego Orangepi Zero jest taki że strasznie się grzeje, i nawet z małym radiatorem przy pełnym obciążeniu dość szybko nagrzewa się chyba do 75 stopni gdzie następuje throttling rdzeni do 500Mhz. Więc na dłużej niż 5 minut mamy tak naprawdę mniej niż połowę deklarowanej mocy obliczeniowej.

Miałem dokładnie te same problemy (u mnie ze sporym radiatorem+wentyl mocno się grzał i pracował niestabilnie). Nie polecam tych SBC (nie wiem może w nowszych wersjach wygląda to lepiej, ale ja się zawiodłem na tych SBC).

Pozdrawiam

[kaworu]

Dnia 9.02.2021 o 18:54, H1M4W4R1 napisał:

UART w STM32 jest zwykle ograniczony do 115.2kbps

A to przepraszam bardzo, co za dziwny pomysł? Głupie F0 mają maks 6Mbit.

Edytowano Luty 11, 2021 przez kaworu

[H1M4W4R1]

2 godziny temu, kaworu napisał:

A to przepraszam bardzo, co za dziwny pomysł? Głupie F0 mają maks 6Mbit.

Okej, mój błąd - nigdy nie używałem UARTa (zwykle wolę USB, bo potrafi poprawić błędy transferu), więc bazowałem na danych z CubeMX. Stąd padło tam słowo zwykle.