Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

STM32 <-> PC magistrala przemysłowa

r03c10 22 Nov 2017 11:21 750 16
SterControl
  • #1
    r03c10
    Level 11  
    Witam,

    chciałbym w moim urządzeniu połączyć płytkę opartą na mikrokontrolerze STM32 z komputerem. W normalnych warunkach nie zastanawiałbym się długo i podłączył tą płytkę za pomocą USB. Natomiast w tym wypadku chciałbym zastosować rozwiązanie powiedzmy bardziej przemysłowe (boję się zakłóceń wewnątrz urządzenia). Pomyślałem, że mógłbym wykorzystać interfejs RS-485 lub CAN, z którym już miałem do czynienia wcześniej.

    I teraz pojawia się moje pytanie. Czy dobrym rozwiązaniem będzie wyjście z PC przez USB, umieszczenie bezpośrednio przy nim płytki z mniejszym STM32, którego zadaniem będzie zamiana sygnałów na CAN/RS485 i doprowadzenie tym intefejsem sygnału do finalnego PCB, którym chcę sterować?

    A może w ogóle pozostać przy pomyśle samego USB? Czy ten interfejs nadaje się do takich rozwiązań i można go stosować w urządzeniach przemysłowych?

    Z góry dziękuję za wszystkie odpowiedzi.
  • SterControl
  • #2
    tmf
    Moderator of Microcontroller designs
    USB działa na określoną odległość. Przy dobrym kablu, nie ma siły, będzie działać ok. RS485 lub CAN rozważ jeśli urządzenia są daleko od siebie i w efekcie poza specyfikacją USB.
  • SterControl
  • #3
    r03c10
    Level 11  
    Dziękuję za odpowiedź. Długość przewodu będzie wynosiła około 2 metrów, a więc myślę że to nie powinno być problemem. Czyli rozumiem, że jest dopuszczalne stosowanie interfejsu USB w takich rozwiązaniach? Jeżeli tak to bardzo chętnie bym go wykorzystał ponieważ w bardzo prosty sposób można emulować wirtualny port COM w STM32 i będzie to najłatwiejsze rozwiązanie. Pytanie tylko jak z obsługą takiego portu szeregowego pod Linuxem, gdyż taki system (konkretnie Ubuntu) chcę zastosować. Ale to już inna kwestia.
  • Helpful post
    #4
    Freddie Chopin
    MCUs specialist
    USB może i w teorii działa na te 2 metry itd., ale z doświadczenia powiem, że ten interfejs _NIE_ jest odporny na zakłócenia. Rozwiązywanie problemów na jakie można się natknąć podczas badań EMC wymaga stosowania bardzo drogiego kabla, masy dodatkowych ferrytów i pewnie jeszcze odrobiny czarów - zwłaszcza, że w samym PC USB też nie jest całkowicie zabezpieczone. W końcu normy dopuszczają wystąpienie problemu - czyli w rzeczywistości zerwanie transmisji, zniknięcie urządzenia - jeśli tylko rozwiąże się on samoczynnie po ustąpieniu zakłócenia - czyli w rzeczywistości pojawienie się urządzenia po pewnym czasie, bez potrzeby fizycznego odłączania go od portu USB. Tak więc ze swojej strony szczerze NIE-polecam.

    Jeśli chcesz użyć RS-485, to wystarczy że użyjesz dowolnej przejściówki USB <=> RS-485, ewentualnie USB <=> UART + UART <=> RS-485. Jestem prawie pewny, że podobne przejściówki znajdziesz też dla CAN, wiec robienie swojej własnej jest raczej bezcelowe.

    r03c10 wrote:
    Pytanie tylko jak z obsługą takiego portu szeregowego pod Linuxem, gdyż taki system (konkretnie Ubuntu) chcę zastosować.

    Obsługa portu szeregowego w Linuxie jest mniej-więcej milion razy łatwiejsza niż w Windowsie, gdyż generalnie system ten mocno przewyższa Windowsa pod bardzo wieloma względami (żadnym z nich nie jest niestety popularność i najnowsze gry). Jako system do szeroko pojętego "developmentu" jest to rozwiązanie dużo lepsze od Windowsa (no chyba że chodzi o pisanie programów na Windowsa, to wtedy niekoniecznie). Tak więc o to zupełnie nie musisz się obawiać - wirtualny port szeregowy w Linuxie otwiera się jak normalny plik poprzez /dev/ttyUSBx lub /dev/ttyACMx, nie potrzeba do niego _ŻADNYCH_ sterowników, wszystko działa identycznie w każdej dystrybucji i jedyne co może Cię ewentualnie zaskoczyć to fakt, że często zwykły użytkownik nie ma prawa dostępu do portów szeregowych, ale to rozwiązujesz albo przez sudo (słaba opcja na dłuższą metę) albo przez dodanie się do odpowiedniej grupy (zwykle uucp). Jeśli chcesz zmieniać parametry transmisji (co dla komunikacji pomiędzy urządzeniami nie ma żadnego sensu - jest to przydatne tylko jeśli projektujesz fizyczna przejściówkę z USB na UART lub coś podobnego), to musisz zapoznać się z interfejsami termios i tyle.
  • #5
    tmf
    Moderator of Microcontroller designs
    @Freddie Chopin Oczywiście USB wymaga dobrego kabla, a to oznacza, że czasami drogiego. Lecz weźmy pod uwagę kontekst - czy nawet najdroższy kabel USB będzie droższy niż interfejs USB-magistrala + po drugiej stronie magistrala-urządzenie? IMHO nie i jeśli chodzi o dwa urządzenia w odległości 2m to śmiało bym zastosował USB. Zresztą sam przemysłowy konwerter USB będzie kosztował sporo. Druga sprawa to zabezpieczenia portu - są one różne. I tu należałoby sprawdzić płytę i co o użytych zabezpieczeniach pisze producent. Z drugiej strony też można dać świetne układy zabezpieczające. Zresztą przy CAN, czy RS485 też jeśli to miałoby być lepsze niż USB trzeba dać odpowiednie układy zabezpieczające, a i dobry transceiver dla tych magistrali nie kupisz za 2 zł.
    Wziąłbym pod uwagę jeszcze jeden aspekt - korzystając z protokołu USB, automatycznie na poziomie sprzętowym i softwarowym mamy realizowaną detekcję/korekcję błędów. To część specyfikacji tego interfejsu. Przy RS485 mamy gołe połączenie elektryczne, przy CAN niewiele lepiej. W efekcie to użytkownik będzie musiał zadbać o obsługę błędów, wątpię, aby zaplanował i zrealizował to lepiej niż w USB wytestowanym przez miliardy użytkowników.
  • #6
    r03c10
    Level 11  
    tmf wrote:
    Wziąłbym pod uwagę jeszcze jeden aspekt - korzystając z protokołu USB, automatycznie na poziomie sprzętowym i softwarowym mamy realizowaną detekcję/korekcję błędów.


    Szczerze mówiąc nie wiedziałem, że w przypadku USB mamy jakąkolwiek detekcję ewentualnych blędów. Cały czas żyłem w przekonaniu, że to CAN ma zaawansowany arbitraż ramek danych i to właśnie on najbardziej niezawodnie działa jeżeli chodzi o eliminację błędnych danych. Tutaj czuję się zaskoczony.

    W sumie ideałem byłby interfejs działający analogicznie do USB, posiadający dodatkowo linie różnicowe, czyli takie połączenie USB z CAN. Może jest coś takiego?

    Cały czas siedzi mi również w głowie zastosowanie w celu komunikacji ethernetu, ale tam bez jakiejś warstwy nadrzędnej (MODBUS, PROFIBUS) też nie ma chyba żadnego arbitrażu?
  • #7
    Freddie Chopin
    MCUs specialist
    r03c10 wrote:
    W sumie ideałem byłby interfejs działający analogicznie do USB, posiadający dodatkowo linie różnicowe, czyli takie połączenie USB z CAN. Może jest coś takiego?

    Jest - USB (; Przecież D+ i D- to właśnie jedna para różnicowa.

    r03c10 wrote:
    Cały czas siedzi mi również w głowie zastosowanie w celu komunikacji ethernetu, ale tam bez jakiejś warstwy nadrzędnej (MODBUS, PROFIBUS) też nie ma chyba żadnego arbitrażu?

    Kontrola błędów - całkiem zaawansowana - jest na warstwie TCP. Modbus czy Profibus (w tym przypadku Profinet) opierają się wtedy właśnie na TCP.
  • #8
    r03c10
    Level 11  
    Freddie Chopin wrote:
    Jest - USB (; Przecież D+ i D- to właśnie jedna para różnicowa.


    Kurczę, faktycznie. Jakoś mnie musiało zamulić :) W sumie nigdy nie myślałem o USB jako o interfejsie różnicowym.
  • #9
    simw
    Level 26  
    Freddie Chopin wrote:
    nie potrzeba do niego _ŻADNYCH_ sterowników

    Takie kategoryczne stwierdzenie jest oczywiście nieprawdziwe lub niepełne. Każdy sprzęt bez sterowników (czy też zwanych firmware) jest tylko zwykle przyciskiem do papieru.
    Od sterowników w Linuksie jest jądro zwane kernelem. Jeśli będzie nieodpowiednio skonfigurowane to sprzęt nie będzie działał. Dla bardzie egzotycznych urządzeń USB może tak właśnie się zdarzyć, że zabraknie wkompilowanego odpowiedniego modułu.
    Do tego dochodzi jeszcze pojęcie FIRMWARE, który dla wielu urządzeń, również USB, może być wymagane przez moduł jądra podczas ładowania modułu sterownika do pamięci, a nie zawsze taki firmware jest dostępny.

    Oczywiście od biedy stwierdzenie "_ŻADNYCH_ " może być przez zaawansowanego użytkownika Linuksa potraktowane obojętnie, ale niezaawansowanym tylko miesza w głowie i tworzy niepotrzebne mity o Linuksie.

    Podsumowując, pomimo że standardowe jądra są mocno obładowane różnymi modułami (sterownikami) może zdarzyć się, że dla konkretnego urządzenia takowego zabraknie.

    Freddie Chopin wrote:

    wszystko działa identycznie w każdej dystrybucji

    Przecież dystrybucje tworzą często zupełnie inni ludzie, kompilację jądra też każdy może sobie zrobić. Przecież wystarczy inny demon do zarządzania uruchamianiem i już inaczej będzie wyglądać katalog /dev inna renumeracja urządzeń i zamiast /dev/eth0 będzie /dev/enp3s0, przy zmianie nazwy urządzenia blokowego już można mówić, że następuje zmiana sposobu postępowania.

    Zresztą jak tam można powiedzieć "wszystko działa identycznie"? :) Dla mnie jest to niezgodne z technicznym myśleniem.

    W wypowiedzi Kolegi jest po prostu za dużo uogólnień, albo słaba znajomość tematu.
  • #10
    Freddie Chopin
    MCUs specialist
    simw wrote:
    Podsumowując, pomimo że standardowe jądra są mocno obładowane różnymi modułami (sterownikami) może zdarzyć się, że dla konkretnego urządzenia takowego zabraknie.

    Ale umówmy się, że w przypadku wirtualnego portu szeregowego szansa że zabraknie sterowników jest raczej pomijalnie mała dla każdej "typowej" dystrybucji.

    simw wrote:
    Przecież dystrybucje tworzą często zupełnie inni ludzie, kompilację jądra też każdy może sobie zrobić. Przecież wystarczy inny demon do zarządzania uruchamianiem i już inaczej będzie wyglądać katalog /dev inna renumeracja urządzeń i zamiast /dev/eth0 będzie /dev/enp3s0, przy zmianie nazwy urządzenia blokowego już można mówić, że następuje zmiana sposobu postępowania.

    Zresztą jak tam można powiedzieć "wszystko działa identycznie"? Dla mnie jest to niezgodne z technicznym myśleniem.

    Będę się trzymał swojego zdania. Czy to będzie /dev/ttyUSB0, czy /costam/0/agdfawe2345q34rsafa/dziwna-nazwa/jakies-identyfikatory/32423, jest bez znaczenia dla tematu - otwierasz to jak normalny plik i Twoja aplikacja działa identycznie. Poczytaj jakie cuda trzeba robić w Windowsie żeby sobie z poziomu kodu obsłużyć port szeregowy - nie ma w ogóle porównania do tego co jest w Linuxie/Unixie (każdym). Jeśli chcesz iść tym tropem, to w Windowsie jest co najmniej tak samo źle, bo przecież skąd wiesz czy akurat utworzy Ci się COM5 czy COM21?

    Przy okazji po poziomie pytań widać że raczej nie mówimy o osobie która miała w planie sobie zaraz konfigurować i kompilować swojego własnego kernela, a we wspomnianym Ubuntu to właśnie będzie działać tak jak to opisałem - bez żadnych dodatkowych sterowników które trzeba skądś pobierać i instalować, bez potrzeby czekania aż Windows Update stwierdzi, że faktycznie jednak nie ma tych sterowników na swoich serwerach, tylko właśnie "plug & play".
  • #11
    BlueDraco
    MCUs specialist
    Akurat Windows 10 ma już standardowe drivery do standardowych VCOM, a CubeMX aktualnie generuje dla STM32 kod ze standardowymi identyfikatorami klasy w deskryptorach, więc po wpięciu kabelka system od razu widzi VCOM, bez dociągania driverów.
  • #12
    Freddie Chopin
    MCUs specialist
    Wspaniale (; I pewnie jeszcze Windows 10 nie ma żadnych wad? Dzięki, jak będę chciał mieć system który robi za moimi plecami rzeczy o które go nie prosiłem, to z pewnością pomyślę o najnowszym dziele Microsoftu (;

    Zresztą - kwestia sterowników to tylko jedna z dwóch poruszonych przeze mnie rzeczy. Obsługa portów szeregowych z poziomu kodu wciąż jest skrajnie durna, a osobie która wymyśliła "\\\\.\\" należy się jakaś nagroda.
  • #13
    grko
    Level 33  
    @BlueDraco Nie sądzisz, że to trochę porażka, że te sterowniki są dopiero w windows 10?

    @Freddie Chopin Całe WinAPI wygląda jakby było robione po ostrych drugach. Zrozumienie tych wszystkich dziwnych typedefów PVOID oraz PPVOID oraz PPPVOID przyprawia o mdłości.

    BTW: całkiem niedawno windows ma możliwość zmiany wszystkich sterowników. Jest przez to możliwość przełożenia dysku z systemem z jednego komputera do drugiego i nawet system sie uruchamia;) Po 20 latach system driverów windowsa dogonił linuxa.
  • #14
    r03c10
    Level 11  
    Nie wiedziałem, że sprowokuję taką dyskusję :) To prawda, że póki co nie chcę tworzyć własnej dystrybucji Linuxa i będę korzystał z gotowego Ubuntu. Aczkolwiek w przyszłości byłoby warto przygotować swój własny, minimalny system. Czytam już sobie o Yocto project i będę się powoli przymierzał do własnej kompilacji.
  • #15
    grko
    Level 33  
    @r03c10 Ja mogę polecić Buildroota w całości opartego o make oraz kconfig jako prostszą alternatywę dla Yocto.
  • #16
    BlueDraco
    MCUs specialist
    grko wrote:
    @BlueDraco Nie sądzisz, że to trochę porażka, że te sterowniki są dopiero w windows 10?


    Oczywiście, że tak właśnie sądzę, ale większą porażką byłoby, gdyby w Win10 wyglądało to tak samo głupio jak w poprzednich wersjach. Zresztą wielbiciele Win 8.1 też mogą wyposażyć system w taką możliwość. Przez to, że wcześniej Windows nie obsługiwał CDC ACM standardowo, dostawcy układów VCOM projektowali je na ogół tak, żeby nie dały się obsługiwać standardowo (brak poprawnego ID klasy/podklasy w Device Desc.), skutkiem czego układy "wiodących marek" (np. FTDI, ale też CH340) nadal wymagają driverów, za to porządny DIY już nie wymaga - i całe szczęście.
  • #17
    grko
    Level 33  
    BlueDraco wrote:
    grko wrote:
    @BlueDraco Nie sądzisz, że to trochę porażka, że te sterowniki są dopiero w windows 10?


    Oczywiście, że tak właśnie sądzę, ale większą porażką byłoby, gdyby w Win10 wyglądało to tak samo głupio jak w poprzednich wersjach. Zresztą wielbiciele Win 8.1 też mogą wyposażyć system w taką możliwość. Przez to, że wcześniej Windows nie obsługiwał CDC ACM standardowo, dostawcy układów VCOM projektowali je na ogół tak, żeby nie dały się obsługiwać standardowo (brak poprawnego ID klasy/podklasy w Device Desc.), skutkiem czego układy "wiodących marek" (np. FTDI, ale też CH340) nadal wymagają driverów, za to porządny DIY już nie wymaga - i całe szczęście.


    Nadal uważam, że brak wsparcia jest winą drivera windowsowego. Pod linuxem dzaiła wszystko bez wyjątku. Nawet FTDI z "wyzerowanym" PID ;)