Pracuję nad projektem, który wymaga dobrej komunikacji danych między zdalnym Arduino a komputerem. Połączenie bezprzewodowe odbywa się za pomocą pary XBees, więc mamy połączenie RS232 między Arduino i komputerem. W przypadku małych ilości danych łatwo jest połączyć prosty protokół komunikacyjny. W przypadku większych projektów, jakie są dobre proste protokoły komunikacyjne?
Patrzyłem na MODBUS, który wydaje się realną opcją, ale chciałem sprawdzić, czy istnieją inne lepsze opcje.
serial
communication
xbee
protocol
Komputerowy
źródło
źródło
Odpowiedzi:
OP prosi o protokół szeregowy w sytuacji, gdy „ nie ma dużo [danych], a szybkość nie jest wielkim problemem ”. MODBUS jest wspomniany w OP MODBUS przez RS-485 nie jest szybkim protokołem. Chociaż nie jest to specyfikacja, daje to wyobrażenie o niszy.
Mogę wymyślić tylko dwa wspólne standardowe protokoły dla tej niszy:
Bardzo często, gdy wbudowani programiści znajdują się w takiej sytuacji jak OP, projektują od zera własne protokoły komunikacji szeregowej.
źródło
Niektóre protokoły systemów wbudowanych, niektóre z nich niezwykle proste, są wymienione na stronie Embedded Systems: Common Protocols , w tym:
Być może jeden z tych protokołów byłby odpowiedni dla obecnej aplikacji lub z drobnymi poprawkami.
źródło
Głosowałbym, żeby rzucić własne i uprościć to tak prosto, jak to możliwe.
Mam do czynienia z dużą ilością protokołów szeregowych do różnych zastosowań sterowania, a kilka rzeczy, które można polecić dołączyć to:
Jako bardzo prosty przykład możesz przekonwertować swoje dane na znaki ASCII i umieścić je w znakach start / stop w następujący sposób:
Aby wysłać wartość bajtu 0x7A, przesyłane dane to (7A), gdzie () to wybrane znaki start / stop, a 7 i A to dwa znaki ascii. OK, to dodaje dużo narzutu, ale oznacza to, że możesz debugować za pomocą podstawowego oprogramowania terminala.
źródło
Jeśli twoje dane przechodzą przez XBees, powinieneś przełączyć moduły w tryb API ze znakami zmiany znaczenia, podzielić dane na pakiety logiczne i skorzystać z faktu, że w trybie API pakiet, który jest przekazywany do XBee, albo dotrze nienaruszony, albo Ani trochę. Zaprojektuj swój protokół wokół transmisji fragmentów 1-255 bajtów i pozwól modułom XBee martwić się o sposób dostarczania danych w ramach każdego fragmentu. Nie martw się o utrzymanie integralności poszczególnych pakietów lub podziałów między nimi. Moduły Digi dobrze sobie z tym poradzą. Najważniejszą rzeczą, o którą musisz się martwić, jest fakt, że nawet jeśli węzeł, który przesyła pakiet, uważa, że nie został dostarczony i wysyła zamiennik, odbiorca może i tak go otrzymać - być może nawet po otrzymaniu zastępstwa. Sprawy mogą być najłatwiejsze, jeśli zaprojektujesz swój protokół tak, aby jedna strona była „wzorcem”; jeśli master poprosi o kawałek danych, slave powinien wysłać go raz i nie martwić się o to, czy master go otrzyma. Jeśli master nie otrzyma potrzebnych danych, może zażądać ich ponownie.
Jednostka podporządkowana powinna przypisać dane do numerów sekwencji, a jednostka nadrzędna powinna przypisać numery sekwencji do żądań zmiany stanu urządzenia podrzędnego. Jeśli żądanie kapitana ma postać „wyślij pierwszy element, którego numer kolejny jest większy niż XXX”, a każdy element danych przez urządzenie slave zawiera swój własny numer kolejny i numer poprzedniego elementu (jeśli nie są ponumerowane kolejno ), późno przybywające pakiety mogą powodować, że niewolnik nadmiarowo wysyła dane do mastera, ale master nie będzie miał trudności zignorowaniem wynikających z tego opóźnionych odpowiedzi. Jeśli slave otrzyma żądanie zmiany stanu, którego numer sekwencji jest niższy niż numer wcześniejszego żądania, powinien zignorować to żądanie, ponieważ zostało ono zastąpione jeszcze przed jego otrzymaniem.
źródło
A co z Firmatą ? Obsługuje różne systemy operacyjne i języki programowania. Obsługiwane są Arduino i PICduino po stronie kontrolera, ale nie powinno to być zbyt trudne do przeniesienia do czystego mikrokontrolera.
źródło
Miałem podobne pytanie i nigdy nie znalazłem nic prostego i wystarczająco małego dla małych AVR itp. Więc stworzyłem coś zainspirowanego CAN. Nazywa się MIN (Microcontroller Interconnect Network):
https://github.com/min-protocol/min
Napisałem o tym tutaj blog:
https://kentindell.wordpress.com/2015/02/18/micrcontroller-interconnect-network-min-version-1-0/
Są tam haki na dane blokowe, ale są one głównie ukierunkowane na sygnały dla czujników / urządzeń wykonawczych. Zdefiniowałem format JSON do opisywania sygnałów i ich upakowania w ramkach MIN i mam nadzieję, że otrzymam sekretarz Wireshark, który go używa.
źródło