Ogólny protokół przesyłania danych z jednego systemu do drugiego?

18

Jaki jest ogólny protokół przesyłania informacji z jednego systemu do drugiego? Załóżmy na przykład, że przez pewien czas gromadzimy pewne informacje z mikrokontrolera, które chcemy przesłać do innego mikrokontrolera. Słyszałem o interfejsach SPI i I2C, ale nie jestem pewien, kiedy używasz jednej metody nad drugą i jak ją implementujesz. Czy istnieją inne metody oprócz SPI i I2C, które są wspólne? Czy proces wdrażania jest podobny dla różnych mikrokontrolerów? Czy to w zasadzie parsowanie bajtów danych, które wykonuję na mikrokontrolerze odbierającym?

O_O
źródło
4
Co konkretnie chcesz zrobić?
starblue
Wystarczy pomyśleć o tym, jak uzyskać różne elementy systemu, aby przesyłać dane do siebie w małym pudełku, aby można było założyć, że odległość jest bardzo mała. Powodem posiadania różnych elementów w pudełku jest uproszczenie funkcji, tak aby każdy element miał swoją funkcję (mam nadzieję, że ma to sens ..)
O_O
2
nie tak zwykle nazywają system. To więcej, co określiłbym jako podsystemy. Stanowią one część tego, co można uznać za pojedynczy system realizujący jeden zestaw zadań. Jest to semantyka, ale myślę, że wiele twoich odpowiedzi jest bardzo szerokich, ponieważ nie mają idealnego pojęcia o tym, czego szukasz w pytaniu.
Kortuk
1
zgodnie z tym, co powiedział Kortuk, pomaga zdefiniować problem. Jednym ważnym pytaniem, jakie należy sobie zadać, jest to, czy możesz zamienić poszczególne podsystemy na różne implementacje tej samej funkcji, czy też jest to jednorazowy projekt „jak jest”. Jeśli używasz prawdziwej magistrali i udostępniasz procesorowi szczegóły implementacji podsystemów, to zmiana podsystemu wymaga zmiany as / w dla twojego kontrolera, natomiast jeśli używasz interfejsu komunikacyjnego, nie ma znaczenia jak zaimplementujesz (zamiennik) ) podsystem, o ile spełnia ten sam protokół komunikatów.
JustJeff
Podział funkcji na wiele urządzeń nie jest prostszy z innego powodu niż rozdzielenie zadań. Komunikacja i synchronizacja są bardziej złożone niż dwa procesy w tej samej mikro. Teraz, jeśli procesy te mają szczególnie niekompatybilne profile opóźnień (jeden musi zostać zaktualizowany szybko, a drugi może zająć trochę czasu, aby ukończyć porcję), MOŻE istnieć uzasadniony powód, aby je podzielić. Nawet wtedy bardziej powszechnym rozwiązaniem jest użycie przerwań lub znalezienie sposobu na dalsze przerwanie dłuższego zadania. Z tym, co opisałeś, skłaniam się ku myśleniu, że powinieneś to przemyśleć.
darron

Odpowiedzi:

10

SPI i I2C są w pewnym sensie podobne, ponieważ w rzeczywistości są używane bardziej do podłączania urządzeń peryferyjnych do kontrolera lub procesora, niż do przesyłania danych między systemami. USB to kolejny interfejs, który ludzie chcą traktować jako system komunikacyjny, który w rzeczywistości jest peryferyjną magistralą przyłączeniową.

Komunikacja między systemami nie jest dokładnie taka jak podłączanie urządzenia do magistrali. Podłączenie magistrali pozwala procesorowi bezpośrednio uderzać w rejestry w urządzeniu, natomiast interfejs komunikacyjny umożliwia wysyłanie / odbieranie strumieni danych. Urządzenie podłączone do magistrali zazwyczaj wymaga sterownika urządzenia, podczas gdy w przypadku komunikacji naprawdę nie ma znaczenia, co jest podłączone na drugim końcu, jeśli chodzi o komputer hosta.

Oczywiście przez cały czas staje się to bardziej niebezpieczną granicą. Rzeczy takie jak PCI i ISA to bezdyskusyjnie autobusy; I2C, SPI, USB to prawdopodobnie szyny; podczas gdy RS232, RS485 i Ethernet to zdecydowanie interfejsy komunikacyjne. Ale są też takie rzeczy, jak magistrala CAN i 1553, które zdecydowanie dotyczą przenoszenia danych, ale w bardzo zaangażowany sposób.

JustJeff
źródło
CANbus jest bardzo zaangażowany, a Ethernet nie? CAN jest bardzo prosty w obsłudze dla prostych wysyłania wiadomości tam i z powrotem. Są to dedykowane układy scalone, a większość rodzin obsługuje wewnętrznie mikrokontrolery.
Kortuk
@Kortuk - o ile coś takiego jak 232 ma swoistą symetrię peer-to-peer, podczas gdy 1553 lub CAN narzuca relację master / slave, tak. Nie sądzę, że powiedziałem, że sieć Ethernet jest prosta, po prostu nie nakłada rozróżnienia między kontrolerem magistrali / urządzeniem magistrali na punkty końcowe.
JustJeff
również pełne ujawnienie - moja opinia o CAN pochodzi całkowicie z narażenia stycznego; było to nieużywane opcjonalne urządzenie peryferyjne na kilku systemach, nad którymi pracowałem, ale po setkach przejść przez dokumentację, wchłaniasz trochę informacji o nieużywanych opcjach tylko przez osmozę. Pracuję więc przy założeniu, że CAN jest architekturą typu kontroler / urządzenie sterowane.
JustJeff
Myślę, że autobus ma różne znaczenia w różnych kontekstach. Z poziomu schematu każdy interfejs z wieloma sygnałami można uznać za magistralę. W miarę przechodzenia na wyższe poziomy z większą abstrakcją autobus zmienia znaczenie. Nieco wyżej, magistrala zwykle oznacza, że ​​w grę wchodzi lub może być zaangażowanych wiele urządzeń. Na przykład wielopunkt RS485 to zdecydowanie autobus. Znacznie wyżej, z punktu widzenia urządzenia z Linuksem, RS485 ponownie staje się interfejsem komunikacyjnym i zostaje zdegradowany z bycia magistralą ... dopóki nie doda się na nim własnej warstwy protokołu, zamieniając ją z powrotem w magistralę. Na każdym poziomie ma inne znaczenie.
darron
11

Nie ma jednego sposobu wysyłania danych, istnieje wiele różnych sposobów komunikacji w zależności od odległości, szybkości transmisji danych, środowiska, aplikacji ...

Najniższa warstwa to warstwa fizyczna , która faktycznie przesuwa bity.

  • SPI i I²C są na krótkich odległościach wewnątrz urządzenia, gdzie nie ma dużo hałasu, który mógłby zakłócić transmisję.

  • Dla niezbyt szybkiej komunikacji na odległość do kilkudziesięciu metrów dobrym rozwiązaniem jest komunikacja szeregowa przez RS-232.

  • Jeśli jest więcej szumów lub używane są sygnały różnicowe o większej odległości, na przykład w RS-485. Dla szybszej transmisji danych istnieje Ethernet, który staje się coraz bardziej popularny.

  • Istnieją również różne standardy łączności bezprzewodowej.

Na wierzchu warstwy fizycznej znajduje się więcej warstw organizujących sposób przesyłania danych, służących do wykrywania i korygowania błędów w transmisji, routingu w sieci i wielu innych rzeczy. Na przykład protokół internetowy jest dość złożonym stosem kilku warstw, zwykle na szczycie protokołu Ethernet.

starblue
źródło
7

Można zastosować prosty szeregowy UART (jedną linię Tx i jedną linię Rx bez dyskretnego zegara) i można go łatwo dostosować do krzyżowania różnych potencjałów (nawet obwodów pierwotnych i wtórnych) za pomocą optoizolatorów lub izolatorów magnetycznych .

Jeśli chodzi o protokoły, wszystko ze zdefiniowanymi bajtami poleceń i jakimś schematem sum kontrolnych będzie działać dobrze. Tak naprawdę nie ma standardowego protokołu obejmującego wszystkie rodzaje komunikacji. I2C ma standardy sygnalizacyjne (definiowanie adresowania, zatrzymywania, uruchamiania itp.), Ale protokół tego, co jest faktycznie przesyłane, zależy wyłącznie od dewelopera.

Na przykład PMBus to protokół komunikacyjny zasilacza, który wykorzystuje I2C jako medium fizyczne.

Adam Lawrence
źródło
6

Naprawdę nie ma „ogólnego” protokołu, to, czego ostatecznie użyjesz, zależy w dużej mierze od aplikacji. Abyśmy mogli udzielić lepszej odpowiedzi, musimy lepiej zrozumieć Twoje wymagania. Wspominasz, że chciałbyś mieć oddzielne mikrokontrolery rozmawiające ze sobą jako podsystemy.

Niektóre pytania dotyczące tej aplikacji:

  1. Czy w tym projekcie będą więcej niż 2 mikrokontrolery?
  2. Jakie są twoje wymagania dotyczące prędkości i przepustowości? Jak szybko potrzebne są informacje i jak często wysyłasz / odbierasz dane?

Jeśli odpowiedziałeś NIE na pytanie 1:

Jeśli w tym projekcie są tylko 2 kontrolery mikrokontrolerów, możesz na pewno użyć między nimi UART. Jeśli oboje muszą zainicjować komunikację, użyj kontroli przepływu, w przeciwnym razie wysyłanie danych w jednym kierunku powinno być trywialne. W przeważającej części powinno to być „wystarczająco szybkie”, biorąc pod uwagę, że wybrałeś jedną z wyższych prędkości transmisji. I2C i SPI są zazwyczaj dobre tylko dla architektury master / slave.

Jeśli odpowiedziałeś TAK (więcej niż 2 kontrolery) na pytanie 1:

  • Jeśli w twoim projekcie są więcej niż 2 mikrokontrolery, który z nich inicjuje komunikację? Czy będzie to tylko jeden kontroler nadrzędny (tj. Architektura master-slave)? A może któryś z podsystemów będzie mógł mówić w dowolnym momencie?
  • Czy istnieje potrzeba, aby którykolwiek z podsystemów rozmawiał ze sobą? np .: dla urządzeń A, B i C: A może wysyłać do B i C, a B do A i C itp.

Teraz potrzebujesz czegoś bardziej skalowalnego, w którym możesz upuszczać urządzenia adresowalne na wspólną szynę. Odpowiedź na te pytania uzupełniające pomoże ci wybrać między I2C a SPI (master-slave) lub czymś w rodzaju CAN (multi-master).

Twój mikrokontroler najprawdopodobniej ma urządzenie peryferyjne UART, inne (szczególnie CAN) mogą być dostępne tylko na wyższych układach końcowych. W obu przypadkach powinna istnieć duża dokumentacja na temat używania tych urządzeń peryferyjnych do przenoszenia bajtów.

Jon L.
źródło
5

Jak zauważył @Jon, jednym z problemów przy wyborze interfejsu komunikacyjnego jest to, czy jeden podmiot zawsze będzie odpowiedzialny za zainicjowanie komunikacji, czy też więcej niż jeden podmiot może być tak odpowiedzialny. Powiązaną kwestią jest to, czy jeden podmiot zawsze będzie gotowy na otrzymywanie niechcianej komunikacji. SPI jest często używany w aplikacjach, w których jedna strona zawsze będzie gotowa na odbiór komunikacji. Na przykład rejestr przesuwny 74HC595 nigdy nie jest „zajęty”. Chociaż SPI jest dobry do komunikacji między mikrokontrolerem a sprzętem, który ma kontrolować mikro, tak naprawdę nie jest dobry do komunikacji między dwoma mikrokontrolerami. Kiedy dwa procesory ze sprzętem I2C używają go do komunikacji, oprogramowanie może zająć tyle czasu, ile chce (w ramach bardzo hojnych ograniczeń), aby poradzić sobie z tym, co się dzieje, bez powodowania utraty danych. Jeśli procesor przetworzyłby każdy przychodzący bajt na 100 mikrosekund, poważnie ograniczyłoby to przepustowość, ale nadawca spowolniłby wystarczająco, aby odbiorca nadążył. Jedynym sposobem, który ogólnie może się zdarzyć w przypadku SPI, jest posiadanie osobnego drutu do uzgadniania.

I2C to naprawdę wspaniały protokół. Największe ograniczenia, które uniemożliwiają mu bycie najdoskonalszym protokołem, jaki można sobie wyobrazić

  1. Jego prędkość jest nieco ograniczona; SPI może iść znacznie szybciej, a nawet UART mogą czasami iść trochę szybciej
  2. (2) Chociaż jest bardzo wygodne, że I2C potrzebuje tylko dwóch przewodów, oba przewody muszą być zdolne do dwukierunkowej komunikacji typu otwarty kolektor. Utrudnia to wysyłanie I2C przez repeatery.

Osobiście chciałbym, aby automaty kontrolerów obsługiwały trzyprzewodowy wariant SPI, który obejmował uzgadnianie. Nie znam jednak żadnego kontrolera, który to robi.

supercat
źródło
Zabawne, że powinieneś o tym wspomnieć ... Muszę przekształcić interfejs SPI w dwukierunkowy interfejs podobny do I2C (pierwszy bajt to adres), aby umożliwić wielu urządzeniom uczestnictwo w magistrali, niż mam wybór układów . Działa, jeśli wszystkie urządzenia podrzędne są FPGA. :) Ja również żałuję, że nie było czegoś pomiędzy tymi dwoma głównymi standardami synchronicznymi.
darron
Och, chyba powinienem wyjaśnić, że włączanie wyjścia na urządzeniach slave nie jest potwierdzane, dopóki nie zostanie odebrany bajt adresu, i pozostają włączone, dopóki wybór pojedynczego układu nie zostanie odznaczony ... więc jest to oczywiście nieco inne niż normalne SPI + wysoki poziom protokół. Jest jednak całkowicie kompatybilny ze standardowym SPI z punktu widzenia urządzenia głównego. (jak mikroprocesor)
darron
@darron: Cool. Zastanawiam się, co musiałoby się stać, aby przemysł zaczął używać trójprzewodowej magistrali komunikacyjnej o otwartym standardzie, w której przewody są aktywnie napędzane wysoko i nisko? Wydaje mi się, że istnieje niewielki konflikt między unikaniem pasywnego podciągania i zezwalaniem dowolnemu urządzeniu na sygnalizowanie przerwania, chociaż można temu zaradzić, dodając pin przerwania, który można podłączyć do urządzenia nadrzędnego lub nie dla wygody urządzeń podrzędnych (moja obecna implementacja protokół ma tylko jedno urządzenie podrzędne, więc może użyć przewodu powrotnego danych do asynchronicznego sygnalizowania, kiedy chce zostać serwisowany).
supercat
@darron: Aby uniknąć konieczności korzystania ze styku wyboru chipa, master sygnalizuje uruchomienie polecenia, wysyłając dwie rosnące krawędzie na przewodzie danych, gdy zegar jest niski; urządzenia podrzędne mogą wskazać, czy ich ostatni bajt danych był prawidłowy, wysyłając wartość statusu, gdy zegar i dane są na niskim poziomie (bezczynności); w przeciwnym razie wskazują, że chcą uwagi, gdy zegar jest niski, a dane są wysokie. Gdybym projektował sprzęt główny dla tego protokołu, dodałbym możliwość wysyłania 8 impulsów taktowania w miejscu, w którym zegar zwierciadlany zegar danych, a w sprzęcie podrzędnym zawiera asynchroniczną liczbę narastających zboczy podczas ...
supercat
@darron: ... bajt danych. Jeśli pięć lub więcej, bajt zostanie zignorowany (slave założyłby, że master jest zainteresowany otrzymywaniem bajtu danych, ale nie miał nic, co chciałby powiedzieć). Nie byłoby to jednak tak znaczące, jak to, że slave zgłasza stan ostatniego bajtu, gdy zegar był niski (co, gdyby urządzenie slave było procesorem, pozwoliłoby masterowi wiedzieć, że slave nie był gotowy i przegapił ostatnią „możliwość transakcji”.
supercat
3

W żadnej konkretnej kolejności najbardziej popularnymi instancjami warstwy fizycznej dla 2 procesorów w tym samym pudełku wydają się być:

  • łańcuch SPI (taki jak używany przez JTAG)
  • Interfejs SPI wyboru drutu na slave
  • „RS-232 na poziomie TTL”, inaczej „asynchroniczna komunikacja szeregowa start-stop” (bezpośrednie połączenie styku UART TX jednego procesora z pinem UART RX innego procesora)
  • I2C
  • 8-bitowe dane + strobe (takie jak port równoległy portu drukarki IEEE 1284)
  • pamięć współdzielona (tylko jeden procesor steruje jednocześnie adresem / danymi / magistralą sterującą)

Te instancje warstwy fizycznej (jak również inne instancje warstwy fizycznej dla 2 procesorów w osobnych skrzynkach) zazwyczaj zapewniają strumień bajtów do oprogramowania, które implementuje wyższe poziomy systemu komunikacyjnego.

Inteligentni programiści piszą oprogramowanie w taki sposób, że gdy facet od sprzętu postanawia oderwać jedno wystąpienie warstwy fizycznej i zastąpić je zupełnie innym wystąpieniem warstwy fizycznej, wystarczy przepisać kilka funkcji, aby podać strumień wyjściowy bajtów do sprzętu i odczytuje strumień bajtów ze sprzętu, a wszystkie rzeczy związane z protokołem wyższego poziomu nadal działają bez zmian.

Protokół wysyłania informacji z jednego procesora do drugiego procesora prawie zawsze wymaga interpretacji strumienia bajtów jako serii pakietów:

  1. preambuła
  2. nagłówek
  3. (ewentualnie uciekł) serializowane dane
  4. zwiastun filmu

Niektórzy ludzie lubią tworzyć zupełnie nowe, niestandardowe, niekompatybilne protokoły, łącząc i dopasowując (2) jeden z wielu rodzajów struktury nagłówka z (3a) jednym z wielu rodzajów serializacji danych z (3b) jednym z wielu rodzajów uciekając przed serializowanymi danymi za pomocą (4) jednego z wielu rodzajów zwiastunów.

Niektóre z najprostszych protokołów enkapsulacji danych w pakiecie obejmują:

Nieco bardziej skomplikowane protokoły kapsułkowania danych w pakiecie obejmują:

Istnieje długa lista protokołów na stronie

Możesz przeczytać „Protokół folkloru” Radii Perlman, który opisuje, w jaki sposób projektowanie protokołu może się nie udać.

Davidcary
źródło
3

Brak jednego „ogólnego” protokołu. Wybór może (na przykład) zależeć od:

  • dystans
  • wymagana przepustowość
  • dostępność specjalnych urządzeń peryferyjnych
  • poziom hałasu
  • potrzeba izolacji optycznej
  • krytyczność (dopuszczalny wskaźnik awaryjności)
  • dostępna moc procesora na obu końcach
  • dostępne styki we / wy na obu końcach

W wielu przypadkach musisz usunąć warstwę fizyczną (poziomy sygnału) z warstwy łącza danych (+/- sposób kodowania danych) (sprawdź model OSI, niższe warstwy 2 ..4). Możliwe warstwy fiskalne to na przykład:

  • proste 5 V lub 3,3 V lub nawet 1,8 V TTL
  • dowolny z powyższych, ale otwarty kolektor zamiast push-pull
  • zbalansowana sygnalizacja napięcia Lov (często używana z układami FPGA)
  • zrównoważone wyższe napięcie (RS485, RS432)
  • pojedyncze napięcie wyższe (RS232)
  • zbalansowane sprzężenie trafo (różne wersje ethernetowe, dźwięk PDIF)
  • optyczny (optyczny ethernet, toslink)

Możesz użyć jednej linii do przenoszenia danych i informacji o zegarze lub podzielić ją na wiele linii. Te ostatnie były popularne, ale obecnie większość nowych / szybkich protokołów używa jednej linii (lub pary linii działających jako jedna).

Istnieje wiele sposobów kodowania danych i zegara na linii. RS232 tradycyjnie używa NRZ, istnieje kodowanie Machester i różne formaty używane na dyskach twardych o ciekawych nazwach linii 2.7 RLL.

Podsumowując: istnieją miliardowe sposoby na komunikację między systeemami. Nie wspomniałem nawet o łącznikach ani aspektach wyższego poziomu, takich jak wykrywanie i odzyskiwanie błędów, kodowanie danych, kompresja i szyfrowanie ...

Wouter van Ooijen
źródło