System inteligentnego domu w oparciu o RS485/multi-master

Choć na chwilę obecną to w zasadzie inteligentne oświetlenie + zestawy różnej maści czujników, acz pełznie we właściwą stronę.

1. Wstęp i motywacja

Jakiś czas temu stworzyłem dwa projekty. Pierwszy - stacja meteo -> https://www.elektroda.pl/rtvforum/topic3165735.html, który w ciągu miesiąca albo dwóch będzie miał już chyba 11 inkarnację elektroniki (do tej pory poza zbieraniem danych ze stacji, posłużył także do dodania funkcji sieciowych do SmartUPS SC620). Drugi -> https://www.elektroda.pl/rtvforum/topic3255866.html - sterownik do kuchennych LEDów, czy w ogóle LEDów mający port RS485. Port do tej pory nie był wykorzystywany, ale w zasadzie co stoi na przeszkodzie aby usunąć czujnik oświetlenia zewnętrznego i karmić sterownik danymi oświetlenia ze stacji meteo na balkonie?



2. Stare problemy i nowe moduły

Sterownik w zasadzie działa poprawnie, jedyny mankament projektowy jaki się ujawnił to wzbudzający się losowo (a tak na prawdę wraz z uruchomieniem agregatu lodówki) czujniki PIR, ot ktoś pomyślał sobie, że jak nie da przy zmieniaczu poziomów (?) (level shifter), od strony czujnika PIR rezystorów ustalających stan/podciągających do zasilania to nic się nie stanie... stało się, PIR działający w oparciu o przerwania był straszliwie podatny na wszystkie zakłócenia, ale to nic czego nie dało by się rozwiązać zmianami w sofcie.
Gdzieś po drodze zachciało mi się bawić STM32F030, a że jakoś nie pałam miłością do zestawów prototypowych/startowych to zrobiłem sobie coś, co jest oparte o w/w a ma jakieś konkretne zastosowanie - zbiera dane. Moduły nie są jakoś szczególnie ciekawe, ani skomplikowane, projekt PCB (jak zawsze) wykonany "z palca", nie ma schematu. Każdy ma wyprowadzone 4 porty analogowe, TIM3 (PWM), I2C, SPI, 1-Wire, kilka luźnych GPIO i właśnie port RS485 oparty o ST3485. A, że ja najwyraźniej nie mogę żyć bez przeprojektowania czegoś, a w szafie leżą Si4455 (które kiedyś dostałem od kolegi, bo mieli wolne), powstał projekt bardzo zbliżonych funkcjonalnie modułów z usuniętym wyprowadzeniem SPI i luźnymi GPIO, ale za to z komunikacją radiową @868MHz i EEPROMem, ale to myślę jest temat na osobny temat, jak już powstaną i zadziałają.



Moduły składają się z 2 części, właściwej i dodatkowej, zawierającej dwa gniazda RJ45, dwa ledy, mostek prostowniczy i złączki.



Idea była taka, aby właściwa część była na ile to możliwe kompaktowa, co by się dało ją upchnąć w małej przestrzeni (nie wiem czemu wyszła większa niż puszka elektryczna). A w razie dostępności większej ilości przestrzeni można skorzystać z pełnej wersji dla łatwiejszej zabawy nimi. Elektrycznie moduły nie używają pary numer 1, zostanie do wykorzystania w przyszłości. Para numer dwa obsługuje komunikację po wspomnianym wcześniej RS485, para 3 i 4 przesyła zasilanie o dowolnej polaryzacji i napięciu 12V. Schemat połączeń jest kompatybilny z dość popularnym pasywnym PoE, dzięki czemu do zasilania wszystkiego (poza modułem LEDów) nadaje się "wstrzykiwacz", który został zaprojektowany dla stacji meteo:



A który przy okazji umożliwił zasilanie jednym zasilaczem laptopowym dużej części drobnicy elektronicznej, jaka się po domu pałęta (switch, access point, ładowarki telefonów, czujniki różne). Oszczędność na gniazdkach, poza tym wygodniej.

3. Topologia sieci

Ale to wszystko musi jakoś ze sobą rozmawiać. Magistrala RS485 jest rozpięta na konkretne pomieszczenie. Każde, które używa tego schematu czujników ma swoją własną magistralę, także jak jakieś urządzenie widzi inne bezpośrednio to wie, że jest w jego pomieszczeniu, mniej konfiguracji. Wspomniana wyżej 11 inkarnacja elektroniki stacji ma także inne zastosowania, bo poza tym że obsługuje czujniki i wymienia dane z serwerem to ma też transciver RS485, co pozwala jej na zachowywanie się jak bramka dla danego pomieszczenia. Urządzenia wpięte do RS485 na ogół bawią się we własnym sosie, w większości wypadków nie muszą wiedzieć co się dzieje na zewnątrz pomieszczenia. Dla wszystkich innych wypadków albo bramka przyśle im jakieś zdarzenie albo same mogą ją odpytać o jakiś czujnik poza ich bezpośrednim polem widzenia.


Bramka, duże to, ale w sumie mam na szczęście opcje ukrywania ich chociażby za lodówką.

4. Protokół

Protokół, czyli coś dla czego głównie stworzyłem wpis, ot może ktoś zauważy coś co udało mi się w nim przegapić.
Większość protokołów rozmawiających po RS485 ma naturę master-slave. Moim zdaniem w tego typu zastosowaniach to mało wygodne. Jeśli zniknie z jakiegoś powodu master, wszystko przestanie działać. A tak mogę sobie odpiąć z magistrali bramkę, czy dowolny inny element, a reszta na ile to możliwe dalej funkcjonować.

Każdy moduł ma swój 32bit adres, przypadkiem pokrywa się to z wielkością crc32. (STM ma sprzętowy moduł, można sobie tak wygenerować unikalne adresy z UID mikrokontrolera).
Urządzenia komunikują się za pomocą pakietów, pakiety są skonstruowane podobnie do ramek ethernetu w połączeniu z elementami UDP.
Każda ramka poprzedzona jest preambułą (4 znaki) 0x55 i pole oznaczającym start ramki. Potem idzie nagłówek:



to/from - wiadomo. Adresy 00000000 i FFFFFFFF są zarezerwowane, drugi oznacza "broadcast". Długość ramki ograniczona jest w protokole do 64k, ale praktycznie wartością ograniczającą jest wielkość bufora do którego trzeba upchnąć odbierane dane, a ta jest różna w zależności od sprzętu i trybu. Przykładowo aplikacja główna ma RX: 128, TX: 512 a bootloader: RX:786 TX:128. Bramka z racji na spory zapas pamięci mogłaby spokojnie wymieniać pełne ramki ethernetu razem z siecią RS.
protoType - protokół jaki został opakowany w ramkę. Zastosowanie mają obecnie dwa, jeden identyczny z tym, jakiego używa stacja meteo, a drugi to TFTP (o czym za chwilę). Dało by się nawet zrobic routing IP, na ile to ma sens.
flags - na przyszłość
seq - jeśli to pole ma wartość zero, pakiet nie wymaga potwierdzenia. Zaraz po wysłaniu jest kasowany z kolejki, nie ma tutaj znaczenia czy gdzieś dotarł czy nie, ot nie jest to aż tak ważna informacja. Jeśli jest ustawione, nadawca czeka ~20ms na potwierdzenie dostarczenia, jeśli go nie otrzyma ponawia kilkukrotnie transmisje. Jeśli je dostanie kasuje ramkę z bufora, jeśli nie - zgłasza "timeout". Broadcasty z zasady nie są potwierdzane.
len - raczej wiadome.
Następnie idą dane i 32bit suma kontrolna, crc32.

Po co taka przestrzeń adresowa - bo adresy są stałe, niekonfigurowalne i unikalne. Wystarczy wpiąć, wysłać broadcast, który zainteresuje wszystkich i mamy listę tego co jest wpięte. Całość działa z prędkością nieco poniżej 1Mbps.

Każdy moduł ma uruchomiony timer pracujący z częstotliwością 100Hz, raczej nie ma opcji aby zegary były w nich zsynchronizowane, więc mamy jako taką losowość czasu podjęcia transmisji zapewnioną na tym etapie. Ponadto transmisja nie zostanie rozpoczęta jeśli właśnie trwa odbiór jakiejś ramki i nie został zakończony, a także jeśli sprzęt wykryje bit startu na linii (plus dla F030 za taką informację*). F103 nie ma takiego sprytnego USARTa, więc sprawdzenie stanu linii przed wysyłką odbywa się przez sprawdzenie stanu pinu TX (porty pracują w half-dupleksie) jeśli jest wysoki - można coś nadać, jeśli nie - transmisja czeka 10ms na kolejny slot. Metoda wykrywania zajętości linii w wypadku F103 nie jest idealna, a z braku lepszej alternatywy (flagi BUSY), ale na ogół działa. Testy pokazały, że przynajmniej ST3485 dobrze tolerują kolizje, żaden się przy ich celowym, cyklicznym wywoływaniu nie spalił, także myślę że przy w/w metodach ich unikania wszystko powinno działać sprawnie przez długi czas.

* z drugiej strony, jak wspomniałem w F103 można sobie sprawdzić stan GPIO podłączonego do USARTu, co nie jest idealne bo możemy trafić akurat między bity, ale w F030 IDR takiego GPIO zawsze pokazuje zero.

Po co ten TFTP - każdy moduł ma złącze SWD, raczej wiadomo po co. Ale poza złączem ma także 7kB bootloader obsługujący programowanie protokołem TFTP. Akurat tym, bo stacja meteo ma taki. Także jeśli w danej sieci istnieje bramka ethernetowa, to istnieje możliwość aktualizacji firmware o ile znany jest adres modułu i bramki**:



** - A adres modułu w sieci RS485 jest częścią niektórych UIDów czujników.

Operacja trwa kilka sekund. Minus jest taki, że jak się załaduje niewłaściwy firmware to trzeba się pofatygować z programatorem do modułu, bo bootloader sam z siebie się nie włącza. Dla kompatybilności (i wygody) bramka od strony sieci eth zachowuje się jak typowy moduł swojej klasy, tj po uruchomieniu wykrywa co ma podłączone po stronie RS'a i o ile tamtejsze moduły mają na sobie jakieś czujniki, to dodaje je do listy swoich czujników, każdy czujnik ma 64bit unikalny ID, akurat taki długi bo 1-Wire/DS18B20 mają tego typu adresy.



Całość działa w tej konfiguracji od paru dni i współczynnik kolizji/zgubionych pakietów/błędów CRC nie przekracza 0.5%. Przy czym czujniki odpytywane sa o nowe dane co 5s (przez bramkę eth i sterownik led), a moduł podłączony do PIR (HC-SR501) wysyła zdarzenia jak tylko się pojawią, czyli natychmiast po wykryciu ruchu. Wszystkie zdarzenia przekazywane są przez bramkę do serwera, na którym siedzi sobie software logujący co bardziej interesujące rzeczy. I tak oto LEDy w kuchni (a później w przedpokoju) mogą korzystać z danych z czujnika wystawionego za oknem, a jakby się uprzeć, to czujki ruchu sterujące oświetleniem można spiąć w system alarmowy.

A do tego prawie działająca (bo poza odpytaniem czujników to za wiele nie potrafi) aplikacja androidowa:

WoW. Świetne wykonanie. Sam zacząłem zabawę z inteligentnym domem, ale opieram się na gotowym arduino i uważam że mój projekt robi się do d*py jak ktoś taki jak Ty robi takie rzeczy od podstaw.
Gratsy !

mati_323 napisał:

WoW. Świetne wykonanie. Sam zacząłem zabawę z inteligentnym domem, ale opieram się na gotowym arduino i uważam że mój projekt robi się do d*py

A to musi od razu tyłki urywać czy coś?
Patrz, jak zrobisz coś prostego, ale własnego to się czegoś nauczysz, poprawisz, znów się czegoś nauczysz i potem masz projekt, który wpasowuje się akurat w to co jest potrzebne, a przy okazji wiedza w gratisie.

mati_323 napisał:

jak ktoś taki jak Ty robi takie rzeczy od podstaw.

Tak po prawdzie, to robienie rzeczy od podstaw wcale nie jest takie skomplikowane. A od czegoś trzeba zacząć, patrz:


Takie wspaniałe rzeczy się tworzyło. Ten moduł USB to nie moje, tak dla jasności, mój jest ten pająk.

mati_323 napisał:

Gratsy !

Dzięki!

"Szacun" za ogrom włożonej pracy.

Sareph napisał:

Większość protokołów rozmawiających po RS485 ma naturę master-slave. Moim zdaniem w tego typu zastosowaniach to mało wygodne. Jeśli zniknie z jakiegoś powodu master, wszystko przestanie działać.

Nie do końca mało wygodne. Warstwa RS485 na której pracuje przemysłowy PROFIBUS, MODBUS, Fieldbus i wiele innych jest wykonana jako master-slave i nie ze względu na wygodę tylko na możliwość szybkiej naprawy ewentualnej awarii oraz łatwiejszą konfiguracyjność. Wydaje mi się że lepiej zastosować coś jak "token ring". Każdy może być masterem przez chwilę jak nadejdzie jego kolej. Jestem na etapie wykonywania automatyki domowej i nie wyobrażam sobie biegania z programatorem po pokojach i konfiguracji każdego modułu z osobna. Mam jeden PLC + moduł RS485 , kilkanaście "slave'ów" i wszystkie modyfikacje robię w jednym programie do jednego urządzenia i z jednego miejsca.

markosik20 napisał:

Nie do końca mało wygodne. Warstwa RS485 na której pracuje przemysłowy PROFIBUS, MODBUS, Fieldbus i wiele innych jest wykonana jako master-slave i nie ze względu na wygodę tylko na możliwość szybkiej naprawy

Hm, hm, szybkiej naprawy w jakim sensie? / jakiego typu awarii?

markosik20 napisał:

oraz łatwiejszą konfiguracyjność.

Ponownie moim zdaniem - im mniej konfiguracji w warstwie komunikacji tym lepiej. Z mojej perspektywy najlepiej jak się wszystko skonfiguruje samo po wpięciu w magistralę. I do tego właśnie dążę.

markosik20 napisał:

Wydaje mi się że lepiej zastosować coś jak "token ring". Każdy może być masterem przez chwilę jak nadejdzie jego kolej.

Z drugiej strony tego typu sieć ma "single point of failure", jak token gdzieś zawiśnie to wszystko przestanie działać. W (tym konkretnym) wypadku RS485, póki nie jest za długa to nawet jak się przerwie to przynajmniej jej część będzie funkcjonować (działa bez terminatorów, sprawdzone, nie idealnie ale działa).

markosik20 napisał:

Jestem na etapie wykonywania automatyki domowej i nie wyobrażam sobie biegania z programatorem po pokojach i konfiguracji każdego modułu z osobna.

I dlatego wszystkie dają się aktualizować zdalnie. Tylko nie pamiętam czemu zrobiłem aby bootloader oddawał kontrolę aplikacji natychmiast po starcie, ale miałem jakiś powód...

markosik20 napisał:

Mam jeden PLC + moduł RS485 , kilkanaście "slave'ów" i wszystkie modyfikacje robię w jednym programie do jednego urządzenia i z jednego miejsca.

Co kto lubi, prawda? Tylko ponownie, jak master zamarudzi, nic nie będzie funkcjonować.

Witam
Zainteresował mnie jeden szczegół w projekcie.... : Czym kolega mierzy stężenia PM 1.0 - 10 ?? Jakiś dedykowany czujnik , czy są to tylko pobrane skąś dane ??

Pozdrawiam

SIEKIERA_666 napisał:

Witam
Zainteresował mnie jeden szczegół w projekcie.... : Czym kolega mierzy stężenia PM 1.0 - 10 ?? Jakiś dedykowany czujnik , czy są to tylko pobrane skąś dane ??

Czujnik, PMS3003.

Dodano po 17 [minuty]:

R-MIK napisał:

To, że 64 bit jest unikalne to fakt, ale adres ma 56-bitów a jak spojrzeć na niego inaczej to "tylko" 48. To tak dla uściślenia.

A tak, w sumie wiem. Ale tutaj bardziej chodziło o rozmiar całości i to że nawet jak tylko 24 bity są unikalne, to całość też będzie siłą rzeczy, choćby reszta była "const".

R-MIK napisał:

Gdy transmisja jest wolna można do wykrywania rozpoczęcia transmisji wykorzystać przerwanie od opadającego zbocza linii odbiorczej. [...]

O, nie przyszło mi to na myśl, ciekawa idea.

R-MIK napisał:

Wszystkie muszą. Tak jak w RS232x, tak i w 485/422 wymaga tego norma.

A, czyli tym bardziej problemu nie ma.

R-MIK napisał:

Nie mozna wykluczyć, że dwa nadajniki przyłączą się równocześnie do magistrali, która była wolna. Wtedy "echo" wykaże błędy. Oczywiste, że mamy doczynienia z kolizją, odłączamy się sie od magistrali i co dalej? Jeśli znów sie przyłączymy gdy magistrala będzie wolna może ponownie wystąpić ta sama sytuacja. W IIC rozwiązano to na zasadzie arbitrażu a Ty jak to rozwiązałeś? Losowy czas po, którym przyłączasz sie do magistrali? Jak tak, to w jaki sposób inicjalizujesz generator pseudolosu aby w każdym urządzeniu był inny?

Najbliższe będzie chyba CSMA/CA. Odstęp czasu w przypadku nadawania jest stały (10ms), zegary CPU nie są przecież ani zsynchronizowane ani nie pracują z idealnie taką samą częstotliwością, ot po prostu niedokładność wykonania oscylatora i różne warunki środowiskowe zapewniają odpowiednią losowość dla tych warunków pracy. Ot mało danych jest wymienianych, niskie ryzyko kolizji. Ale nawet jak idzie znacznie większa wymiana (programowanie firmware) to się do tej pory raz zdarzyło, żeby się pakiet zgubił, także - w danych warunkach działa poprawnie.

R-MIK napisał:

Gdy transmisja jest wolna można do wykrywania rozpoczęcia transmisji wykorzystać przerwanie od opadającego zbocza linii odbiorczej. Można pokombinować też tak. Zbocze ustawia flagę przerwania ale go nie generuje (tak mozna zrobić w większości mikrokontrolerów). Jeśli odebrano całą ramkę kasujemy flagę, przed rozpoczęciem transmisji sprawdzamy ją no i oczywiście dalsza logika (jak ustawiona to skasowanie i ponowny test za jakiś określony czas).

Bardzo dobry pomysł.

R-MIK napisał:

Nie mozna wykluczyć, że dwa nadajniki przyłączą się równocześnie do magistrali, która była wolna. Wtedy "echo" wykaże błędy.

To właśnie lekki minus interfejsów, które natywnie nie mają kontroli kolizji, że trzeba przetwarzać dodatkowo "echo". Warto chyba zrobić kontrolę na bazie pojedynczych wracających bajtów, a nie jako porównanie całej ramki. Wtedy kolizja wykryta jest szybciej, no i przestajemy nadawać dalszą część ramki.

R-MIK napisał:

Jeśli znów sie przyłączymy gdy magistrala będzie wolna może ponownie wystąpić ta sama sytuacja. W IIC rozwiązano to na zasadzie arbitrażu a Ty jak to rozwiązałeś? Losowy czas po, którym przyłączasz sie do magistrali? Jak tak, to w jaki sposób inicjalizujesz generator pseudolosu aby w każdym urządzeniu był inny?

Ja kiedyś zrobiłem właśnie losowy czas czas odpowiedzi. Start generatora robiłem bodajże na bazie UID.

Ogólnie projekt bardzo ciekawy. W czym robiłeś apkę na androida?

krisRaba napisał:

Ogólnie projekt bardzo ciekawy. W czym robiłeś apkę na androida?

W oficjalnym googlowym IDE, https://developer.android.com/studio/index.html

R-MIK napisał:

Nie mozna wykluczyć, że dwa nadajniki przyłączą się równocześnie do magistrali, która była wolna. Wtedy "echo" wykaże błędy.

To jeden z największych mitów dotyczacych RS485. Lokalne echo z nadajnika prawie nigdy nie wykaże błędów w przypadku kolizji. Proste prawo Ohma temu zapobiegnie. Kolizję na RS485 w sposób pewny można wykryć tylko w wyższych warstwach OSI, nie w warstwie fizycznej.

R-MIK napisał:

tmf napisał:

R-MIK napisał:

Nie mozna wykluczyć, że dwa nadajniki przyłączą się równocześnie do magistrali, która była wolna. Wtedy "echo" wykaże błędy.

To jeden z największych mitów dotyczacych RS485. Lokalne echo z nadajnika prawie nigdy nie wykaże błędów w przypadku kolizji.

Czyli prawie nigdy gdy jeden wysyła 00 a drugi FF to w żadnym echo nie będzie złe? Pełne echo, czyli także w echu nie ma błędu ramki. Oczywiście magistrala sprawna a nie brak jednej żyły gdzie bywa tak (zależy której brak), że zwiększa sie tylko stopa błędów.

Odbiornik widzi lokalny stan magistrali. Także na odbiornik największy wpływ na lokalny nadajnik, stąd echo zazwyczaj jest poprawne i odpowiada temu co nadaliśmy. W innym miejscu na magistrali jest tak samo. Stąd jeśli układy nie są naprawdę blisko siebie to może nawet dojść do sytuacji w któej na jednej magistrali idą jednocześnie dwie transmisje i lokalne odbiorniki widzą każdą z nich poprawnie.

R-MIK napisał:

To zależy od prędkości transmisji, długości i topologii sieci.

Jestem tego świadom. Ot po prostu - istnieje szansa, że nie wszystko padnie.

@tmf: Ciekawe informacje. Udało Ci się doświadczalnie stwierdzić takie przypadki?

@Sareph dobra robota. Sam wiele razy siadałem do podobnego projektu (multimaster na 485). Wpadłem na pomysł dodatkowej linii podciągniętej do VCC którą nadajnik "ściągałby" do masy. Inne klocki miałyby pełna detekcję czy rzeczywiście magistrala jest wolna.
Jestem ciekaw Waszej opinii w tej sprawie.
Wracając do tematu : jeszcze raz - świetna robota!

ditomek napisał:

Wpadłem na pomysł dodatkowej linii podciągniętej do VCC którą nadajnik "ściągałby" do masy. Inne klocki miałyby pełna detekcję czy rzeczywiście magistrala jest wolna.

Przeszło mi to przez myśl, ale wtedy wszystko musiało by mieć wspólną masę. A w w/w nie wszystko ma.

ditomek napisał:

Wracając do tematu : jeszcze raz - świetna robota!

A dzięki.

R-MIK napisał:

Jak bym robił multidostęp to oparłbym sie o IIC.

PCA9615?

Raz mi się zdarzyło zrobić I2C na odległość > metra i stwierdziłem, że to zły pomysł. Pewnie jakiś problem w projekcie, ale > 10kHz pojawia się tyle błędów transmisji, że łoho, trzeba było dodać do protokołu sumy kontrolne. No i o ile nie ma transcivera jak tego PCA, to łączenie mas mi się nie podoba.

R-MIK napisał:

W każdym razie mozna zostawić protokół i sposób wykrywania kolizji a fizycznie 0..12V zamiast 0.5V.

Można. Z drugiej strony prędkość, im wyższe napięcie tym bardziej ogranicza maksymalną prędkość. Ta w miarę wysoka jest użyteczna, nie ze względu na samą szybkość przesyłu a bardziej dlatego, że im szybciej dane lecą tym krócej zajmują magistralę.

R-MIK napisał:

Z drugiej strony 1-Wire działa na ok 300m przy 0..5V przy 15,5kb/s. Idąc tym tropem IIC powinno działać na te odległości przy podobnej przepływności. Zabezpieczenia nadajników odbiorników można oprzeć o układ stosowany w USB i ISDN (USB6 cos tam).

O ile pamiętam poprawnie, do RS485 można używać transformatorów ethernetowych.

R-MIK napisał:

Mozna i do IIC ale w jaki sposób, nie spotkałem się z takim rozwiązaniem, chyba, że mowa o izolacji galwanicznej np NE485 (około 200zł).

Tak po prawdzie, to nie sprawdzałem. Gdzieś mi mignęła taka informacja, ale że mi to nigdy nie było potrzebne (izolacja galwaniczna) nie sprawdzałem dokładnie. Ale po szybkim zgłębieniu tematu mózg mi mówi że to nie zadziała poprawnie, także cofam.

R-MIK napisał:

tmf napisał:

Stąd jeśli układy nie są naprawdę blisko siebie to może nawet dojść do sytuacji w któej na jednej magistrali idą jednocześnie dwie transmisje i lokalne odbiorniki widzą każdą z nich poprawnie.

Teoria czy praktyka? Przy ok 40m magistrali gdy nadajniki nadawały równocześnie a były na końcach magistrali to miałem błędne echo.

A testowałeś na 1200m? ja nie, ale myślę że byłoby dokładnie tak jak napisał tmf.
Wypisujecie tu dziwne rzeczy o magistralach które się do tego w ogóle nie nadają (I2C, 1-wire), a nikt nie wspomni tu o CAN, który ze wszystkich wymienionych tu magistral najlepiej się do tego nadaje i na dodatek jest najprostszy w implementacji.

vayo napisał:

a nikt nie wspomni tu o CAN, który ze wszystkich wymienionych tu magistral najlepiej się do tego nadaje i na dodatek jest najprostszy w implementacji.

No ja akurat nie wspomniałem, bo odrzuciłem. CAN ma od razu zdefiniowany protokół, który mi po prostu wcale nie pasował, ni w ząb kompatybilny z tym już istniejącym a działającym na UDP/IP.

CAN ma zdefiniowany protokół transmisji, ale nie komunikacji. Zobacz jak w projekcie HAPCAN ładnie rozwiązano transmisję UDP<>CAN

vayo napisał:

CAN ma zdefiniowany protokół transmisji, ale nie komunikacji. Zobacz jak w projekcie HAPCAN ładnie rozwiązano transmisję UDP<>CAN

Ja nie mówię, że się nie da, różne rzeczy można upchnąć w ramkę CAN tak aby to działało. Ale czyni to wszystko bardziej skomplikowanym. Bo w sumie, poza arbitracją, to jaką CAN ma przewagę? Bo ja to raczej głównie wady widzę.

Zrobiłem kilkanaście projektów na RS485, a wśród nich kilka komercyjnych, więc jakieś tam doświadczenie z walką z tą magistralą mam. Robiłem próby z kilkoma masterami, ale to kręcenie bicza z piasku, bo to co na biurku działało idealnie w wersji produkcyjnej już tak idealnie nie działało. Po przesiadce na CAN na pewno nie wrócę do magistrali RS485.
CAN ma taką przewagę, że to nie my się martwimy o kolizję, tylko kontroler CAN. Z punktu programisty poza ustawieniem prędkości transmisji nic nie musimy innego robić. Kontrolery CAN mają swoje bufory nadawcze i odbiorcze. My wysyłamy tylko dane do buforu, a kontroler robi za nas całą resztę, tj. wysyła dane na magistralę i w przypadku kolizji przerywa transmisję i po zwolnieniu magistrali wysyła dane ponownie. Super sprawą są też filtry. No ale tego wszystkiego trzeba samemu spróbować.

I aby nie było -nikogo nie namawiam do przesiadki na CAN, a jedynie gwarantuję, że jak raz spróbuje, to nie wróci do RS485