Prosty szeregowy protokół komunikacyjny punkt-punkt

Protokoły RS232 są trudne. Sugestia użycia HDLC jest dobra, ale nie całe rozwiązanie. Są inne rzeczy, o których musisz zdecydować:

• Jak zostanie określona szybkość transmisji między tymi dwoma urządzeniami? Autobuad? Predefiniowane, czy ustawione?
Czy będziesz sterował przepływem w oprogramowaniu, sprzęcie czy obu? Uwaga, jeśli używasz sprzętowej kontroli przepływu, to musisz upewnić się, że kable są prawidłowo zbudowane. A propos kabli, to jest ogromny ból z RS233. W zależności od urządzenia może być konieczne użycie kabla przelotowego, kabla krzyżowego lub wariantu.
• Korzystanie z mechanizmu sterowania przepływem opartego na oprogramowaniu może być skuteczne, ponieważ pozwala na użycie najprostszego kabla-tylko trzech przewodowych (TX, RX i common).
• czy wybierasz 7 lub 8 bitowe słowo?
• parzystość sprzętowa lub Sprawdzanie błędów oprogramowania.

Proponuję wybrać 8 bitów danych, bez parzystości sprzętowej, 1 bit stopu i użyć przepływu opartego na oprogramowaniu Kontrola. Powinieneś używać autobaud, jeśli twój sprzęt go obsługuje. Jeśli nie, to autobaud jest diabelsko trudny do zrobienia w oprogramowaniu.

Jest tu kilka dobrych odpowiedzi, oto kilka przydatnych wskazówek:

Nawet jeśli pakiety nie są rozdzielone w czasie, bajt synchronizacji jest niezbędnym sposobem na zmniejszenie liczby miejsc, z których należy próbować zbudować pakiet. Twoje urządzenia często będą musiały radzić sobie z wieloma śmieciowymi danymi (np. końcem pakietu w locie po włączeniu lub wynikiem kolizji sprzętowej). Bez bajtu synchronizacji będziesz musiał spróbować utworzyć pakiet z każdego otrzymanego bajtu. The sync bajt oznacza, że tylko 1/255 bajtów losowego szumu może być pierwszym bajtem pakietu. Również fantastyczne, gdy chcesz węszyć na protokole.

Posiadanie adresu na swoich pakietach lub nawet odrobiny powiedzenia master / slave lub pc / device jest przydatne, gdy patrzysz na pakiety za pomocą snoop tool jakiegoś typu lub innego. Można to zrobić, mając inny bajt synchronizacji dla komputera niż urządzenie. Oznacza to również, że urządzenie nie zareaguje na własne echo.

Ty może warto zajrzeć do korekcji błędów (np. Hamming). Pakiet 8 bitów danych do 12-bitowego zabezpieczonego bajtu. Każdy z tych 12 bitów może zostać przerzucony na trasie, a oryginalne 8 bitów odzyskane. Przydatne do przechowywania danych (używane na płytach CD) lub tam, gdzie urządzenie nie może łatwo ponownie wysłać (łącza satelitarne, jednokierunkowe rf).

Numery pakietów ułatwiają życie. Przesyłany pakiet zawiera numer, odpowiedzi mają ten sam numer i flagę z napisem "response". Oznacza to, że pakiety, które nigdy arrived (Sync corrupted say) są łatwo wykrywane przez nadawcę, a w trybie full-duplex z powolnym łączem można wysłać dwa polecenia przed otrzymaniem pierwszej odpowiedzi. Ułatwia to również analizę protokołu (osoba trzecia może zrozumieć, które pakiety zostały odebrane bez wiedzy o protokole bazowym)

Posiadanie jednego mistrza to niesamowite uproszczenie. To powiedziawszy, w środowisku full-duplex nie ma to większego znaczenia. Wystarczy powiedzieć, że zawsze powinieneś to robić, chyba że próbujesz oszczędzać energię lub robisz coś wywołanego zdarzeniami na końcu urządzenia (stan wejściowy zmieniony, próbka gotowa).

Moja propozycja to modbus. Jest to wydajny i łatwy standardowy protokół komunikacji z urządzeniami posiadającymi Czujniki i parametry (np. PLC). Specyfikacje można uzyskać pod adresem http://www.modbus.org . istnieje od 1979 roku i zyskuje na popularności, nie będziesz miał problemu ze znalezieniem przykładów i bibliotek.

Czytałem to pytanie kilka miesięcy temu, mając dokładnie ten sam problem, i tak naprawdę nie znalazłem nic wystarczająco wydajnego dla małego 8-bitowego mikro z niewielką ilością pamięci RAM. Zainspirowany CAN I linem, zbudowałem coś, co zrobi to zadanie. Nazwałem go MIN (Microcontroller Interconnect Network) i wgrałem go na GitHub tutaj:

Https://github.com/min-protocol/min

Istnieją dwie implementacje: jedna w embedded C, druga w Pythonie dla PC. Plus małe " cześć świat " program testowy, w którym komputer wysyła polecenia, a oprogramowanie układowe zapala diodę LED. Pisałem na blogu o uruchomieniu tego na tablicy Arduino tutaj:

Https://kentindell.wordpress.com/2015/02/18/micrcontroller-interconnect-network-min-version-1-0/

MIN jest dość proste. Poprawiłem reprezentację warstwy 0 (8 bitów danych, 1 bit stopu, bez parzystości), ale pozostawiłem szybkość transmisji otwartą. Każda ramka zaczyna się od trzech bajtów 0xaa co w binarnym to 1010101010, fajny pulsetrain do zrobienia wykrywanie szybkości autobaud, jeśli jeden koniec chce dynamicznie dostosowywać się do drugiego. Ramki to 0-15 bajtów ładunku, z 16-bitową sumą kontrolną Fletchera, a także bajtem kontrolnym i 8-bitowym identyfikatorem (informującym aplikację o tym, co zawiera dane ładunku).

Protokół używa wypychania znaków tak, że 0xAA 0xaa 0xaa zawsze wskazuje początek ramki. Oznacza to, że jeśli urządzenie wyjdzie z resetu, zawsze synchronizuje się z początkiem następnej klatki (celem projektowym dla MIN nigdy nie było przepuszczenie niekompletna lub nieprawidłowa ramka). Oznacza to również, że nie ma potrzeby stosowania specyficznych ograniczeń czasowych między bajtami i między klatkami. Pełne informacje o protokole znajdują się w GitHub repo wiki.

Jest miejsce na przyszłe ulepszenia z MIN. Zostawiłem tam kilka hooków do przekazywania komunikatów blokowych (zarezerwowane są 4 bity bajtu sterującego) i do negocjacji wyższego poziomu możliwości (zarezerwowany jest identyfikator 0xFF), więc jest mnóstwo możliwości dodania wsparcia dla powszechnie wymaganych funkcjonalność.

Oto alternatywny protokół:

u8  Sync          // A constant value which always marks the start of a packet
u16 Length        // Number of bytes in payload
u8  Data[Length]  // The payload
u16 Crc           // CRC

Użyj RS232 / UART, ponieważ komputer (port szeregowy) i procesor (UART) mogą sobie z tym poradzić z minimalnym kłopotem (wystarczy chip MAX232 lub podobny do zmiany poziomu).

I używając RS232 / UART, nie musisz się martwić o master / slave, jeśli to nie ma znaczenia. W razie potrzeby dostępna jest kontrola przepływu.

Sugerowane Oprogramowanie PC: napisz własne, lub Docklight do prostego monitorowania i kontroli (wersja ewaluacyjna jest bezpłatna).

Dla większego sprawdzania błędów, najprostszym jest sprawdzanie parzystości, lub jeśli potrzebujesz czegoś bardziej wydajnego, może kodowanie konwolucyjne .

W każdym razie, cokolwiek robisz: trzymaj to prosto!

EDIT: Korzystanie z RS232 z komputerem jest jeszcze łatwiejsze niż kiedyś, ponieważ możesz teraz uzyskać konwertery USB na RS232/TTL. Jeden koniec wchodzi do gniazda USB komputera i pojawia się jako normalny port szeregowy; drugi wychodzi na 5 V lub 3,3 V sygnały, które mogą być podłączone bezpośrednio do procesora, bez konieczności zmiany poziomu.

Użyliśmy TTL-232R-3v3 z układu FDTI, który doskonale sprawdza się w tego typu aplikacjach.

Moja jedyna sugestia jest taka, że jeśli potrzebujesz ochrony przed hałasem, możesz użyć full-duplex RS-422/485. Możesz użyć układu scalonego podobnego do tego Po stronie AVR, a następnie konwertera RS-232->RS-422 po stronie PC, takiego jak 485ptbr tutaj. Jeśli znajdziesz lub wykonasz ekranowany kabel (dwie skręcone ekranowane pary), będziesz miał jeszcze większą ochronę. A wszystko to jest niewidoczne dla mikro i PC-bez zmian oprogramowania.

Cokolwiek robisz upewnij się, że używasz full-duplex system i upewnij się, że linie read/write enable są zapewnione na IC.

Możesz rzucić okiem na Telemetry i związane z nim implementacje desktopowe w Pythonie Pytelemetry

Główne cechy

Jest to protokół oparty na PubSub , ale w przeciwieństwie do MQTT jest to protokół point-to-point, nie jest brokerem .

Jak każdy protokół pubsub, możesz publikować z jednego końca na topic i być powiadamianym na drugim końcu w tym temacie.

Po stronie osadzonej publikowanie tematu jest tak proste, jak :

publish("someTopic","someMessage")

Dla liczb:

publish_f32("foo",1.23e-4)
publish_u32("bar",56789)

Ten sposób wysyłania zmiennych może wydawać się ograniczony, ale następnym krokiem milowym jest dodanie dodatkowego znaczenia do parsowania tematu, robiąc takie rzeczy:

// Add an indexing meaning to the topic
publish("foo:1",45) // foo with index = 1
publish("foo:2",56) // foo with index = 2

// Add a grouping meaning to the topic
publish("bar/foo",67) // foo is under group 'bar'

// Combine
publish("bar/foo:45",54)

Jest to dobre, jeśli trzeba wysłać tablice, złożone struktury danych, itp.

Również wzór PubSub jest świetny ze względu na swoją elastyczność. Możesz budować aplikacje master / slave, urządzenia do urządzenia itp.

Biblioteka C

C Biblioteka jest bardzo prosta do dodania na każdym nowym urządzeniu, o ile masz na niej przyzwoitą bibliotekę UART.

Wystarczy utworzyć instancję struktury danych o nazwie TM_transport (zdefiniowanej przez Telemetry) i przypisać 4 Wskaźniki funkcjiread readable write writeable.

// your device's uart library function signatures (usually you already have them)
int32_t read(void * buf, uint32_t sizeToRead);
int32_t readable();
int32_t write(void * buf, uint32_t sizeToWrite);
int32_t writeable();

Aby użyć telemetrii, wystarczy dodać następujący kod

// At the beginning of main function, this is the ONLY code you have to add to support a new device with telemetry
TM_transport transport;
transport.read = read;
transport.write = write;
transport.readable = readable;
transport.writeable = writeable;

// Init telemetry with the transport structure
init_telemetry(&transport);  

// and you're good to start publishing
publish_i32("foobar",...

Biblioteka Pythona

Po stronie pulpitu znajduje się moduł pytelemetry, który implementuje protokół.

Jeśli znam Pythona, poniższy kod łączy się z portem szeregowym, publikuje raz na temat foo, wypisuje wszystkie odebrane tematy w ciągu 3 sekund, a następnie kończy się.

import runner
import pytelemetry.pytelemetry as tm
import pytelemetry.transports.serialtransport as transports
import time

transport = transports.SerialTransport()
telemetry = tm.pytelemetry(transport)
app = runner.Runner(transport,telemetry)

def printer(topic, data):
    print(topic," : ", data)

options = dict()
options['port'] = "COM20"
options['baudrate'] = 9600

app.connect(options)

telemetry.subscribe(None, printer)
telemetry.publish('bar',1354,'int32')
time.sleep(3)

app.terminate()

Jeśli nie znasz Pythona, możesz użyć interfejsu wiersza poleceń

Pytelemetry CLI

Wiersz poleceń można uruchomić za pomocą

pytlm

Wtedy możesz connect, ls(lista) odebrane Tematy, print dane otrzymane w temacie, pub (opublikuj) w temacie, lub otwórz plot w temacie do wyświetlanie odebranych danych w czasie rzeczywistym

Odnośnie sprawdzania parzystości (jak już tu kilka razy padło):

Są w większości bezużyteczne. Jeśli obawiasz się, że pojedynczy bit może zostać zmieniony w wyniku błędu, jest bardzo prawdopodobne, że drugi bit może również ulec zmianie i otrzymasz fałszywy wynik dodatni z kontroli parzystości.

Użyj czegoś lekkiego, takiego jak CRC16 z tabelą Wyszukiwania - można ją obliczyć, ponieważ każdy bajt jest odbierany i jest w zasadzie tylko XOR. Sugestia Steve ' a Melnikoffa jest świetna dla małych mikrosów.

I would sugeruj również przesyłanie danych czytelnych dla człowieka, a nie surowych danych binarnych (jeśli wydajność nie jest twoim priorytetem). Sprawi to, że debugowanie i pliki dziennika będą o wiele przyjemniejsze.

Nie podajesz dokładnie, jak zachowuje się mikrokontroler, ale czy wszystko przesyłane z mikro będzie bezpośrednią odpowiedzią na polecenie z komputera? Jeśli do to wydaje się, że możesz użyć jakiegoś protokołu master / slave (Zazwyczaj będzie to najprostsze rozwiązanie). Jeśli obie strony mogą zainicjować komunikację, potrzebujesz bardziej ogólnego protokołu warstwy łącza danych. HDLC{[2] } jest klasycznym protokołem do tego celu. Chociaż pełny protokół prawdopodobnie jest przesadą dla Twoich potrzeb, możesz na przykład użyj przynajmniej tego samego formatu ramki. Możesz również zajrzeć do PPP , aby zobaczyć, czy są jakieś przydatne części.

Może to pytanie może być całkowicie głupie, ale czy ktoś rozważał użycie jednego z modemu X/Y/Z protokołów?

Główną zaletą korzystania z jednego z powyższych protokołów jest duża dostępność gotowych do użycia implementacji w różnych środowiskach programistycznych.

SLIP i UDP. Poważnie.

Wszystkie komputery PC i podobne urządzenia mówią tym.

Jest dobra książka i przykłady z TCP Lean

Jeremy Bentham podstępnie ma PIC robiący pracy TCP / IP. AVR jest tak dobry jak zdjęcie, prawda ?

Zamiast tego polecam UDP, to całkiem proste.