Sieć mikrokontrolerów i wyszukiwanie

Cześć, Ja w bardzo podobnej sieci (mozna obejrzec jej foto na

), zrobilem tak: Master wysyla w petli zapytanie do kazdego slave, jak sleve rozpozna swoj adres odpowiada masterowi, Jesli nie odpowie master pyta kilka razy to ocznacza ze umarl, wlacza sygnalizacje odciecia slava i idzie dalej. Tyle ze ja wiem ile mam slaveow, tzn moge ktoregos programowo wylaczyc jesli faktycznie padnie, zeby master nie wyl mi w kolo. Nie wiem jak zrobic przy nie wiadomej ilosci slavo, A co do szybkosci to mi nie zalezy zbytnio,

7 slavow jest odpytywanych od 3s do 30s zalezy czy zgubi jakies ramki i musi powtarzac,tyle ze siec jest dosyc rozlegla, z kabla starego telefonicznego, dlugosc sieci to ok 200m. Jesli chcesz miec obsluge zmiennej ilosci slavow to trzeba sie zaglebic w jakies bardziej skompikowane protokoly i tam szukac pomyslow. (moja siec jest pierwsza siecia jaka zrobilem, sporo napracowałem sie przy komunikacji, najpierw w jedna strone, no i zrobilem ja w Bascom AVR) Pzd Michał

A czy w momencie ustalania adresow koniecznie musisz pracowac w trybie transmisji pakietowej? Bo powyzszy algorytm zadziala bardzo dobrze w jednobitowej "pamieci dzielonej" opartej na linii TXD na zasadzie przypominajacej "iloczyn na drucie". Z mastera wysylasz do slave'ow pakiety z zapytaniami jak powyzej. Po odebraniu odpowiedzi wylaczaja one port szeregowy i programowo steruja stanem TXD. Jesli slave chce udzielic odpowiedzi twierdzacej, to wymusza na TXD stan niski. W przeciwnym przypadku przelacza TXD na _wejscie z wlaczonym_ pull-upem. Master odczytuje programowo stan RXD i w jednym kroku poznaje wynik rownolegle obliczonej odpowiedzi. I tak odpowiednio wiele razy. BTW, to nie jest "nieslychanie pracochlonne", wymaga co najwyzej log(M)*K zapytan, gdzie M jest liczba roznych adresow, a K liczba slave'ow.

Pozdrawiam Piotr Wyderski

Użytkownik Sebastian Bialy napisał:

Cóś podobnego widziałem w pdfie One-Wire Dallasa - może to coś pomoże... Oni tam przeszukiwali sieć one-wire, też szeregowo, pod kątem dołączenia jakiejś-tam ilości układów. I chyba wcale nie było to takie skomplikowane.

Ja bym zrobił tak, żeby od MAC-a zależało, KIEDY slave odpowie - szczelina czasowa _dokładnie_ określona dla jednego i tylko jednego układu.

Hmmm. Magistrala musi być "długa" więc raczej coś róznicowego jak RS485. Wobrażam sobie po drodze "koncentrator" którego zadaniem jest zrobienie rozgałęzienia w magistrali - powinien on na siebie przejąć część zadań odpowiedzialnych za szukanie slave po swojej stronie druta. W każdym razie iloczyn na drucie będzie cieżko wykonać na RS485 z zakladaniem dodatkowych koncentratorów, choć jeszcze pomyślę.

Problem pojawia się kiedy podłączam nowe slavey w trakcie pracy magistrali. Należało by cyklicznie wywolywac ten agorytm, co może przy prędkościach 9600 mieć znaczenie i zakłucac normalną komunikację.

Pozerkam, ale jestem pewny, że korzystają z jakiejś wersji iloczynu montażowego.

Troche duzo kombinacji :) 2^(10*8) ;) Ale na pewno pomoże w jakims stopniu równo rozkładać odpowiedzi równo w szczelinie czasowej (aczkolwiek nie tyle sam adres, co jakiś jego skrót-hash).

:( Niestety u mnie adres może się składać z 10 bajtów (jeszcze nie zdecydowałem dokładnie w każdym razie nie mniej jak 6) i dlatego przeszukanie wszystkich slave (a mogą mieć _dowolny_ adres z tej przestrzeni) nie wchodzi w grę.

Użytkownik Sebastian Bialy napisał:

Owszem... korzystają :(

Jeszcze coś mi chodzi po głowie zeby wykorzystac cos a'la DHCP ;) ale to przynajmniej CDMA|CD/ethernet potrzebuje ;)

eL eS

Odpada - DHCP (nawet w jakiejś prymitywnej formie tylko powiadamiania o istnieniu) wymaga inicjatywy ze strony slave a to natychmiast wymusza rozwiązanie kolizyje sieci (bo jest na 2 drutach i nie mogę dać więcej). Niestety w moim rozwiązaniu sensowne jest tylko nadawanie komunikatów prze mastera i kontrolowana odpowiedz slave, żeby unikać kolizji.

powiadamiania o

wymusza

komunikatów

Próbowałeś spojrzeć na CANa - też dwa druty, też różnicowo i kolizje rozwiązuje hardware. P.G.

Użytkownik Sebastian Bialy napisał:

Aha. Czyli masz : TX mastera do wszystkich RX slave'ow RX mastera do wszystkich TX slave'ow <- przynajmniej tu na pewno masz OR sprzętowy sprzętowy (jesli dobrze rozumiem)

(tak sobie bajam) Gdyby master wysylal w kazdym komunikacie po znaku otwierającym swoj MAC, slave ktory stwierdzi, ze nie zna takiego MAC-a _powinien_ odezwac sie nie pytany - wysłać swój MAC w chwili, kiedy akurat master o nic nikogo nie pyta. To bylby sygnal dla mastera, ze jest ktos nowy. Zaleta - hotplug. Wada - jeden slave na raz, bo sie po...mieszają.

:)

(/tak sobie bajam)

eL eS

No to albo ja nie rozumiem idei rownoleglego polaczenia wyjsc nadajnikow (wowczas prosze o lepsze wyjasnienie), albo Ty bedziesz musial miec iloczyn (albo sume, wszystko jedno) na drucie, co najmniej w formie przechodzenia K-1 nadajnikow w tryb wysokiej impedancji, tylko jeszcze tego nie zauwazasz. Pisales, ze chcesz zasymulowac Ethernet, a jak zamierzasz wykrywac konflikt na szynie nie majac operacji na drucie? Jesli jej nie masz, to zrobisz zwarcie... :-)

Wymyslilem znacznie lepszy algorytm odtwarzania identyfikatorow, ktory obywa sie bez udzialu mastera -- na podstawie ruchu na szynie kazdy uklad slave sam "domysli sie" identyfikatorow reszty. Wymaga on jednak iloczynu (sumy) na drucie i obywa sie bez konfliktow (a wlasciwie konflikty we wlasciwym czasie i miejscu sa dla niego kluczowe). Jesli bedziesz mial taka operacje, to Ci go opisze.

Mozna wyslac do wszystkich ukladow wiadomosc "czy zostales juz zidentyfikowany" i -- ponownie wykorzystujac iloczyn na drucie

-- w razie potrzeby przeprowadzic identyfikacje tylko nowo dolaczonych ukladow.

Pozdrawiam Piotr Wyderski

Użytkownik "Piotr Wyderski" snipped-for-privacy@ii.uni.wroc.pl> napisał w wiadomości news:cr0q6p$1cu$ snipped-for-privacy@news.dialog.net.pl...

RS485 łączyło się, łączy się i będzie się łączyło równolegle.

Na pewno zauważa, bo pytanie dotyczy sytuacji jednoczesnego wchodzenia na linię kilku nadajników. P.G.

No to tam musi byc wired OR albo wired AND...

Pozdrawiam Piotr Wyderski

Proponuje sie zapoznac z Ethernetem [losowe opoznienia] i Plug-And-Play.

J.

Witam. Powiedz mi, czy mozesz zagwarantowac, ze urzadzenia SLAVE beda w stanie natychmiast zareagowac na broadcast? Najsensowniejszy wydaje mi sie sposob wykrywania kolizji taki jak na magistrali CAN. Czyli iloczyn na drucie (tak jak CAN na pseudo RS-485). Nadanie zera dominuje nad jedynka. Po uslyszeniu broadcastu wszystkie SLAVEy musialyby rozpoczac nadawanie _dokladnie_ w tym samym momencie. Na poczatku nadawalyby swoj numer, bit po bicie -zaczynajac od najbardziej znaczacego. Jesli podczas nadawania 1 na magistali byloby 0 to urzadzenie przegrywa. Musialbys zrealizowac mechanizm powtarzania broadcastow dla pozostalych urzadzen (bez tych co juz sie odmeldowaly). Zastosowanie koncentratorow jest mozliwe, to one musza przejac role mastera dla obslugiwanego fragmentu sieci.

Az sie prosi aby zastosowac CAN. Bez problemu osiagniesz odleglosci rzedu kilku kilometrow. Koncentratory musialyby calkowicie oddzielac fragmenty sieci. Do adresowania mialbys 29 bitow. Jedyny problem to dlugosc ramek-do 8 bajtow.

peters

Nie ma. Jest wchodzenie na linię i jej zwalnianie (wysoka impedancja), a scalaki odporne na zderzenia (wymaga tego standard RS485). P.G.

No to algorytm w wersji podstawowej wyglada nastepujaco. Slave dzialaja rownolegle.

----------------8<-------------

Faza wstepna:

1. Master ustawia TDX na 0 i wysyla do slave polecenie przejscia do trybu identyfikacji.

1. Slave ustawiaja swoje czasomierze na generowanie przebiegu o tym samym czasie trwania (kilkadziesiat mikrosekund) i czekaja na przejscie RXD w stan 1. Master czeka chwile i ustawia TXD na

1. Slave zeruja czasomierze.

Faza identyfikacji:

Jedynym zadaniem transceivera mastera jest natychmiastowe przenoszenie na swoja linie TXD stanu linii RXD. Przerwania z czasomierza numerujemy 0,1,2,3,...,2*K-1, gdzie K jest dlugoscia identyfikatora. Podczas przyjscia przerwania o numerze parzystym slave wystawiaja na TXD jeden bit swojego adresu (np. zaczynajac od najbardziej znaczacego). Jesli bit ten ma wartosc 0, slave wymusza na TXD 0. Jesli ma on wartosc 1, slave ustawia TXD w stan wysokiej impedancji. Na przerwaniach nieparzystych slave odczytuja stan RXD. Jesli nie zgadza sie on z wartoscia nadanego bitu, slave wypada z gry i czeka na zakonczenie obecnej tury identyfikacji (majacej K rund). Jesli sie zgadza, to przechodzi on do nastepnej rundy, tj. powtarza powyzsza procedure.

Po wykonaniu K rund tura sie konczy. W tym momencie z gry nie wypadl dokladnie jeden slave (o najmniejszym identyfikatorze). Od tej chwili milczy on i czeka na koniec fazy identyfikacji. Pozostale uklady slave rozpoczynaja kolejna ture w sposob opisany powyzej. Identyfikacja konczy sie, gdy wygrywa identyfikator zlozony z samych jedynek, ktory jest zarezerwowany. Slave przechodza w tryb standardowej komunikacji pakietowej.

Podczas trwania kazdej rundy master czyta stan linii RXD w tych samych momentach co slave, poznajac identyfikatory w kolejnosci od najmniejszego (leksykograficznie) do najwiekszego, a na koncu wspomniany identyfikator specjalny (wszystkie slave maja TXD w stanie wysokiej impedancji, bo kiedys musialy wygrac). Wowczas master zna identyfikatory wszystkich ukladow.

----------------8<-------------

Teraz mozna troche poprawic zlozonosc komunikacyjna, np. wymagajac, by po zakonczeniu tury slave wyslaly identyfikator pozycji, na ktorej wykryly kolizje (w ten sam sposob jak swoje bity adresu, dzieki czemu minimalny identyfikator wygra) i kolejna ture rozpoczynac nie od poczatku, lecz od wskazanej pozycji (co wyeliminuje wspolne prefiksy adresow).

Pozdrawiam Piotr Wyderski

Nie. Nie ma żadnych iloczynów sprzętowych - RS485 chyba w ogóle nie rozumie pojęcia kolizji z konkretnym stanem logicznym,. Gdy masz iloczyn montażowy to przy kolizji 1 i 0 dostaniesz coś konkretnego (np. 0). W RS485 nie. Nie wiadomo co dostaniesz...

Nie ma gwarancji jak to długo potrwa, chyba że istniały by sloty czasowe i komunikat "jestem!" trwałby krócej niż slot i isyniała by pewna metoda stwiardzenia, że master nic nie nadaje.

O losowych opóźnieniach pisałem wczesniej, że być może własnie to zaimplementuje. Tylko muszem mieć opóźnienia na tyle długie a ramkę na tyle krótką, żeby była szansa w ogóle na przedostanie się pojedynczych komunikatów - przypuszczam, że można to łatwo oszacować z pradopodobieństwa, jakie są szanse slave'a na przesłanie swojego MACa niezakłuconego.