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

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?

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.

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.

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.

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.

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.

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ą:

• trzy bajt protokół Mini SSC
• format sieci

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

• vscp - bardzo prosty protokół sterowania
• Połączenia szeregowe IP

Istnieje długa lista protokołów na stronie

• popularne protokoły używane w systemach wbudowanych
• Programowanie szeregowe: tworzenie pakietów danych

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

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 ...