Wiem, że temat jest banalny. Ale ja chcę się upewnić. Urządzenia, w zależności od funkcji, (Master/Slave) będą miały skrosowane bądź nie linie TXD, RXD. Mam rację? Urządzenie, które było slave, nie może nagle stac sie masterem, bez przekrosowania tych linii? Pytam, by się upewnić.
Pozdrawiam.
Aktyw Forum
Zarejestruj się na forum.ep.com.pl i zgłoś swój akces do Aktywu Forum. Jeśli jesteś już zarejestrowany wystarczy, że się zalogujesz.
Sprawdź punkty Zarejestruj sięRS232 - szybkie pytanie - TXD, RXD
Moderatorzy:Jacek Bogusz, Moderatorzy
Kompletnie pomieszałeś pojęcia. W standardzie RS232 nie istnieją pojęcia Master i Slave. Jedynym podziałem są typy sprzęgu. 1) DTE - Data Terminal Equipment oraz DCE- Data Communication Equipment. Przykłady : w komputerach typu PC standardowe wyprowadzenie RS232 jest typie DTE natomiast proktycznie każdy modem posiada wyprowadzenie RS232 w typie DCE.. O co chodzi? Otóż dla DTE kierunkiem sygnału TxD jest "out" (wyjście transmitownych danych) a RxD "in" (dane przychodzące). W urządzeniach ze sprzęgiem DCE jest odwrotnie, TxD jest "in" a RxD jest "out". Z tego powodu nie istnieje jeden przepis na kable połączeniowe. Trzeba znać typ wyprowadzeń. jeżeli łączysz urządzenie DTE z urządzeniem DCE wtedy połączenie jest "proste" - TxD z jednego na TxD z drugiego, analogicznie z liniami RxD. Gdy łączone są urządzenia o takim samym typie sprzęgu (DTE z DTE lub DCE z DCE) wtedy trzeba "crossować" TxD z jednego na RxD z drugiego. To bardzo uproszczona definicja, bez wnikania w problemy z pozostałymi liniami sterującymi. Standardy nie definiują precyzyjnie wykonań złącza (męskie ,żeńskie) a opis w rodzaju TxD i RxD nie definiuje do końca funkcji wyprowadzenia, konieczna jest wiedza czy jest "in" lub "out" (albo DTE lub DCE). Trochę to skomplikowanie brzmi ale jak to sobie rozrysować i chwilę logicznie pomyśleć to staje się oczywiste.
Wracając do tematu... 
1. Jeżeli chcę mieć połączone urządzenia o równorzędnym statusie, DTE <-> DTE używam skrosowanego kabelka o żeńskich wtyczkach. Teraz problem... jak to oprogramować Może jakiś króciutki programik w BASCOMie?
Np. niech DTE2 czeka na daną spod DTE1, a jeśli ta dana ma wartość 100, to niech DTE2 odeśle do DTE1 wartość 200 Będę bardzo zobowiązany.
2. RS232 to połączenie tylko dwóch urządzeń. Przynajmniej z założenia. A jeśli się uprę, i podepnę pod DTE (komputer) 16 urządzeń (DCE)? Na wysłaną daną oczywiście zareaguje tylko jedno DCE, które dokona programowej identyfikacji adresu, ukrytego, na 4 pierwszych bitach otrzymanej danej?
3. Jak wykonać zadanie z pkt. pierwszego dla RS485? (schemacik+programik)?
Temat zaciekawił mnie. No i najwyższa pora okiełznać RS232!
1. Jeżeli chcę mieć połączone urządzenia o równorzędnym statusie, DTE <-> DTE używam skrosowanego kabelka o żeńskich wtyczkach. Teraz problem... jak to oprogramować
Może jakiś króciutki programik w BASCOMie?Np. niech DTE2 czeka na daną spod DTE1, a jeśli ta dana ma wartość 100, to niech DTE2 odeśle do DTE1 wartość 200
Będę bardzo zobowiązany.2. RS232 to połączenie tylko dwóch urządzeń. Przynajmniej z założenia. A jeśli się uprę, i podepnę pod DTE (komputer) 16 urządzeń (DCE)? Na wysłaną daną oczywiście zareaguje tylko jedno DCE, które dokona programowej identyfikacji adresu, ukrytego, na 4 pierwszych bitach otrzymanej danej?
3. Jak wykonać zadanie z pkt. pierwszego dla RS485? (schemacik+programik)?
Temat zaciekawił mnie. No i najwyższa pora okiełznać RS232!
Zapewne chciałeś powiedzieć, coś o okiełznaniu transmisji szeregowej lub UART'a (a precycyjnie mówiąc to asynchronicznej transmisji szeregowej). RS232 jest jedynie normą napięciową i opisem styku mającą zastosowanie przy transmisji szeregowej.Temat zaciekawił mnie. No i najwyższa pora okiełznać RS232!
Generalnie w oprogramoiwaniu nie uwzględnia się jakiego rodzaju jest zastosowany interfejs (RS232 czy RS485), chyba że wykorzystuje się specyfikę wynikającą z użytego interfejsu (jak transmisja jednoparowa dla RS485).
W RS232 nie przyłącza się kilku urządzeń do pracy na wspólnym kablu. Jeżeli chcesz do jednego kabla przyłączyć kilka urządzeń, to należy użyć interfejsu RS485, te układy mają możliwość wysterowania nadajnika do stanu wysokiej impedancji (trzeciego stanu) i nie zakłócać transisji innych "ziomali". Wiąże się to z koniecznością sterowania trzecim stanem. Przed rozpoczęciem transmisji należy "włączyć" swój nadajnik, potransmitować i po zakończeniu nadawania wyłączyć. Jedyna komplikacja wynika z "wyczajenia" momentu wyłączenia nadajnika.
Zapewne chciałeś powiedzieć, coś o okiełznaniu transmisji szeregowej lub UART'a (a precycyjnie mówiąc to asynchronicznej transmisji szeregowej). RS232 jest jedynie normą napięciową i opisem styku mającą zastosowanie przy transmisji szeregowej.
Wiem, wiem
Chciałem to ująć szybciej, dlatego wyszło mało precyzyjnie W RS232 nie przyłącza się kilku urządzeń do pracy na wspólnym kablu. Jeżeli chcesz do jednego kabla przyłączyć kilka urządzeń, to należy użyć interfejsu RS485, te układy mają możliwość wysterowania nadajnika do stanu wysokiej impedancji (trzeciego stanu) i nie zakłócać transisji innych "ziomali".
Aaa... No i właśnie o to mi chodziło. Trzeci stan (odcięcie od magistrali, brak zakłócania pozostałych)... To był problem...
No i właśnie... Po jakiej stronie się to odbywa? Sprzętowej, czy programowej? Tym się zajmuje MAX485 czy programista?Wiąże się to z koniecznością sterowania trzecim stanem. Przed rozpoczęciem transmisji należy "włączyć" swój nadajnik, potransmitować i po zakończeniu nadawania wyłączyć. Jedyna komplikacja wynika z "wyczajenia" momentu wyłączenia nadajnika.
Tam się zaczyna zabawa MASTER, SLAVE... Ma ktoś jakieś przystępnie sformułowane materiały, stronki itp.? Dla mnie najlepszym byłaby komunikacja równorzędna MASTER-MASTER, lub coś podobnego... Taki system ma większe możliwości, jest bardziej "mobilny", i programista systemu ma większe możliwości... Tylko jak to rozwiązać programowo... Jakiś token-ring? A może priorytety dla urządzeń? Ale to już śliski teren dla mnie. Kt mi pomoże się w tym połapać?
To w takim razie pozostaje ci zastosowanie interfejsu RS485. Jeżeli przykładowo zastosujesz SN75176 (jest to nadajniko/odbiornik). Możesz spróbować z transmisją jednoparową, czyli wszystkie urządzenia łączysz do jednej pary przewodów. Wszystkie wyjścia A lub + (w zależnści jak jaka firma oznacza) łączysz ze sobą i wszystkie B lub - też. Interfejsy wysterowujesz by były na nasłuchu. Ten kto ma ochotę nadawać przełącza się na nadawanie i transmituje. Oczywiści powstaje problem konfliktu dostępu do kabla.
Rozważasz rozwiązanie z token-ring. Rozwiązanie jak rozwiązanie ma wady i zalety. Sprawia to trochę problemów, bo przy "krążącym żetonie" ma on ochotę czasami zaginąć i wtedy powstaje problem rekonfiguracji (identycznie jak na starcie). W ten sposób można wdepnąć w całkiem spory temt, bo trzeba rozstrzygnąć kto ma zacząć, ilu jest "dyskutantów" itp. Prędzej proponowałbym zastosowanie jednego procka specjalnie do nadzoru transmisji, takiego "krupiera, co rozdaje karty". Problemy będą podobne, ale przynajmniej jest wiadomo kto zaczyna zabawę. Jeżeli do tego chcesz jeszcze uzyskać możliwość dynamicznej rekonfiguracji (wpiąć lub wypiąć z takiej sieci urządzenie) to robi się całkiem spory temat.
Ewentualnie można rozważyć transmisję ze słuchaniem własnego echa i nie bawić się w żadne żetony. Jak nie dało się nadać, a o tym jest łatwo się przekonać, to po losowej długości opóźnienia spróbować jeszcze raz.
Rozważasz rozwiązanie z token-ring. Rozwiązanie jak rozwiązanie ma wady i zalety. Sprawia to trochę problemów, bo przy "krążącym żetonie" ma on ochotę czasami zaginąć i wtedy powstaje problem rekonfiguracji (identycznie jak na starcie). W ten sposób można wdepnąć w całkiem spory temt, bo trzeba rozstrzygnąć kto ma zacząć, ilu jest "dyskutantów" itp. Prędzej proponowałbym zastosowanie jednego procka specjalnie do nadzoru transmisji, takiego "krupiera, co rozdaje karty". Problemy będą podobne, ale przynajmniej jest wiadomo kto zaczyna zabawę. Jeżeli do tego chcesz jeszcze uzyskać możliwość dynamicznej rekonfiguracji (wpiąć lub wypiąć z takiej sieci urządzenie) to robi się całkiem spory temat.
Ewentualnie można rozważyć transmisję ze słuchaniem własnego echa i nie bawić się w żadne żetony. Jak nie dało się nadać, a o tym jest łatwo się przekonać, to po losowej długości opóźnienia spróbować jeszcze raz.
No... To mi się zaczyna podobaćPrędzej proponowałbym zastosowanie jednego procka specjalnie do nadzoru transmisji, takiego "krupiera, co rozdaje karty". Problemy będą podobne, ale przynajmniej jest wiadomo kto zaczyna zabawę. Jeżeli do tego chcesz jeszcze uzyskać możliwość dynamicznej rekonfiguracji (wpiąć lub wypiąć z takiej sieci urządzenie) to robi się całkiem spory temat.
(jak najbardziej z wpinaniem i wypinaniem urządzeń, można porobić wstępne priorytety (w sofcie wpinanego układu) a później, jak wspomniałeś, jednostka, która zajmuje się tylko zarządzaniem transmisją (w tym, przydziela adresy, testuje urządzenia, etc.). Robi się tutaj mały problemik, jeśli chodzi o niezawodność systemu, bo kiedy taka jednostka padnie... Trzebaby w takim przypadku, pójść za przykładem rozwiązań telekomunikacyjnych (centrale telefoniczne) i zdublować taką jednostkę (w razie wykrycia awarii wyłączona zostaje pierwsza, podłącza się druga, a do systemu zostaje zgłoszona sygnalizacja awarii, mówiąza o konieczności wymiany modułu... Chyba trochę zjechałem z tematu... A to też jest ciekawe rozwiązanieEwentualnie można rozważyć transmisję ze słuchaniem własnego echa i nie bawić się w żadne żetony. Jak nie dało się nadać, a o tym jest łatwo się przekonać, to po losowej długości opóźnienia spróbować jeszcze raz.
Trzeba pomyśleć...Z tym padaniem to bym nie przesadzał. Od kilku lat mam w domu zainstalowanych trochę procków zajmujących się różnymi zadaniami. W sumie to jak do tej pory nie padł ŻADEN. Jak coś zostało włączone do prądu, tak chodzi do dziś bezawaryjnie (żaden układ nie wypuścił jeszcze z siebie dymka). Ponieważ część urządzeń jest zbudowana na bazie procków z rodziny C51, to statystycznie zdarza się średnio raz na rok zwis niektórych urządzeń (przy drobnej pomocy zakładu energetycznego). Te co mają wbudowane watchdogi nie zwisły nigdy....Robi się tutaj mały problemik, jeśli chodzi o niezawodność systemu, bo kiedy taka jednostka padnie...
Reasumując, to jak napiszesz soft bez błędów, to praktycznie jedyną awarią jaka może się zdarzyć jest zanik zasilania, ale to wtedy wszystkie procki będą miały ten sam problem.
Załóżmy, że opracowane przeze mnie urządzenie (lub szereg takich urządzeń) komunikuje się w standardzie RS485. Niech każde z takich urządzeń wyposarzone jest w dwa złącza DB9M (no właśnie - jakie złącza przyjęło się stosować dla RS485?) i połączone w szereg z innymi.
Chciałbym teraz móc wpiąć się w "to" z komputerem PC. A do tego potrzebowałbym kabelka - konwertera, z RS232C na RS485. Przydałoby się, aby takie coś zmieściło się wewnątrz obudowy gniazda nakablowego DB9F. Czy to jest możliwe? A może lepiej w docelowym urządzeniu zastosować dwa wyprowadzenia: RS232C do komunikacji z komputerem PC, a RS485, do komunikacji z resztą świata?
Pytanie teraz, jak zrealizować niezawodność komunikacji PC <-> układ. Pewnie tylko oczekiwanie na zwrotną odpowiedź potwierdzającą i próby ponawiania wysłania ramki, w przypadku braku odpowiedzi.
A niezawodność komunikacji (obsługa kolizji) dla RS485, przy zachowaniu równouprawnienia urządzeń do magistrali? Coś słyszałem o nasłuchiwaniu własnego echa... Ale zaraz, chwila, jeśli to idzie na jednej parze przewodów, i urządzenie może tylko nadawać LUB odbierać (RS485), to w jaki sposób miałby się obbywać nasłuch...? Nasłuch chyba odpada?
Chciałbym teraz móc wpiąć się w "to" z komputerem PC. A do tego potrzebowałbym kabelka - konwertera, z RS232C na RS485. Przydałoby się, aby takie coś zmieściło się wewnątrz obudowy gniazda nakablowego DB9F. Czy to jest możliwe? A może lepiej w docelowym urządzeniu zastosować dwa wyprowadzenia: RS232C do komunikacji z komputerem PC, a RS485, do komunikacji z resztą świata?
Pytanie teraz, jak zrealizować niezawodność komunikacji PC <-> układ. Pewnie tylko oczekiwanie na zwrotną odpowiedź potwierdzającą i próby ponawiania wysłania ramki, w przypadku braku odpowiedzi.
A niezawodność komunikacji (obsługa kolizji) dla RS485, przy zachowaniu równouprawnienia urządzeń do magistrali? Coś słyszałem o nasłuchiwaniu własnego echa... Ale zaraz, chwila, jeśli to idzie na jednej parze przewodów, i urządzenie może tylko nadawać LUB odbierać (RS485), to w jaki sposób miałby się obbywać nasłuch...? Nasłuch chyba odpada?
Zbudowanie układu zawierającego z jednej strony MAX232, 4 kondensatory i MAX485 nie jest skomplikowane. Do sterowania interfejsem można wykorzystać wyjściowe linie modemowe UART'a z PC.Chciałbym teraz móc wpiąć się w "to" z komputerem PC. A do tego potrzebowałbym kabelka - konwertera, z RS232C na RS485. Przydałoby się, aby takie coś zmieściło się wewnątrz obudowy gniazda nakablowego DB9F. Czy to jest możliwe? A może lepiej w docelowym urządzeniu zastosować dwa wyprowadzenia: RS232C do komunikacji z komputerem PC, a RS485, do komunikacji z resztą świata?
Popatrz na PDF'y od układów RS485 (MAX485 lub SN75176), to wszystko stanie się jasne.Ale zaraz, chwila, jeśli to idzie na jednej parze przewodów, i urządzenie może tylko nadawać LUB odbierać (RS485), to w jaki sposób miałby się obbywać nasłuch...? Nasłuch chyba odpada?
Jeżeli mogę swoje trzy bity...
komunikacja PC->sieć RS485 - w najprostszym przypadku wystarczy 'tępy' konwerter: max232 + max485 (+ może kilka ledów) - jako smd powinno się to zmieścić we wtyczce,
problem zarządzania sygnałami (raptem np. DTR-em do zmiany kierunku nadawanie-odbiór) przerzucasz na oprogramowanie w PC
jak chcesz mieć konwerter inteligentny to zastanów się nad prockiem z dwoma UART-ami, np. SAB 80C537 albo któryś z Dallasów (np.DS89C430), z jednej strony max232 do PC z drugiej max485 do sieci...
a co do samej organizacji sieci:
tak mniej więcej jest rozwiązana komunikacja z modułami ADAM4xxx Advantecha:
jeden master (mniej lub bardziej inteligentny), który rządzi ruchem w sieci, reszta modułów to slave, one nigdy (prawie) z własnej woli nic nie gadają, odpowiadają tylko na pytania od mastera, to znaczy: meldują swój status, zwracają wartości pomiarów, potwierdzają przyjęcie komendy, etc. i kiedy master nie pyta - sieć milczy.
jeżeli master zapyta co coś, lub każe jakiemuś modułowi coś wykonać, oczekuje przez jakiś czas (setki milisekund) oznak akceptacji polecenia, jak nie ma, zgłaszany jest błąd że coś jest nie halo.
ramek z pytaniami słuchają wszystkie moduły, odpowiada tylko ten, którego pytanie dotyczy (jest adresacja).
tu problemem jest tylko to, że może będziesz chciał mieć natychmiastową informację o jakimś wydarzeniu 'w terenie' (np. alarm) a info dostaniesz z opóźnieniem wynikającym z ilości urządzeń, ale możesz też urządzonka 'business critical' odpytywać odpowiednio częściej, w szczególności ciągle (ale ich nie może być za wiele)
takie rozwiązanie ma też zaletę, że możesz automatycznie określić konfigurację sieci: wysyłasz po kolei ramki z pytaniem typu: 'przedstaw się' do kolejnych urządzeń,
niejako 'w ciemno', te które są żywe meldują się ramką z informacją o typie modułu, może jakimiś detalami konfiguracji, te które nie odpowiedzą - albo ich fizycznie nie ma, albo padły - efekt taki sam...
komunikacja PC->sieć RS485 - w najprostszym przypadku wystarczy 'tępy' konwerter: max232 + max485 (+ może kilka ledów) - jako smd powinno się to zmieścić we wtyczce,
problem zarządzania sygnałami (raptem np. DTR-em do zmiany kierunku nadawanie-odbiór) przerzucasz na oprogramowanie w PC
jak chcesz mieć konwerter inteligentny to zastanów się nad prockiem z dwoma UART-ami, np. SAB 80C537 albo któryś z Dallasów (np.DS89C430), z jednej strony max232 do PC z drugiej max485 do sieci...
a co do samej organizacji sieci:
tak mniej więcej jest rozwiązana komunikacja z modułami ADAM4xxx Advantecha:
jeden master (mniej lub bardziej inteligentny), który rządzi ruchem w sieci, reszta modułów to slave, one nigdy (prawie) z własnej woli nic nie gadają, odpowiadają tylko na pytania od mastera, to znaczy: meldują swój status, zwracają wartości pomiarów, potwierdzają przyjęcie komendy, etc. i kiedy master nie pyta - sieć milczy.
jeżeli master zapyta co coś, lub każe jakiemuś modułowi coś wykonać, oczekuje przez jakiś czas (setki milisekund) oznak akceptacji polecenia, jak nie ma, zgłaszany jest błąd że coś jest nie halo.
ramek z pytaniami słuchają wszystkie moduły, odpowiada tylko ten, którego pytanie dotyczy (jest adresacja).
tu problemem jest tylko to, że może będziesz chciał mieć natychmiastową informację o jakimś wydarzeniu 'w terenie' (np. alarm) a info dostaniesz z opóźnieniem wynikającym z ilości urządzeń, ale możesz też urządzonka 'business critical' odpytywać odpowiednio częściej, w szczególności ciągle (ale ich nie może być za wiele)
takie rozwiązanie ma też zaletę, że możesz automatycznie określić konfigurację sieci: wysyłasz po kolei ramki z pytaniem typu: 'przedstaw się' do kolejnych urządzeń,
niejako 'w ciemno', te które są żywe meldują się ramką z informacją o typie modułu, może jakimiś detalami konfiguracji, te które nie odpowiedzą - albo ich fizycznie nie ma, albo padły - efekt taki sam...
Nasłuchiwac możesz zawsze, ważne żebyś umiał odróżnić czy to co dostajesz jest tym co Ty nadawałeś czy danymi z zewnątrz. Wszystkie problemy (głównie kolizje z powodu aktywności dwóch nadajników) musisz rozwiązać programowo (jeżeli używasz zwykłych UART jako peryferiali do obsługi transmisji) Wszystkie protokoły do takiej magistrali mają rozbudowane mechanizmy sprawdzania adresów, sum kontrolnych oraz rozbudowane systemy potwierdzeń (to w wyższej warstwie). Bez tego będzie prawie działało ale zawsze będziesz walczył z duchami. Jeżeli na PC planujesz używać Winows-ów do doradzam zastosowanie zewnetrznego koncetratora komunikacyjnego (wg pomysłu Taszy) i komunikację PC z koncentratorem na standardowym łączu RS232.
pajaczekna upartego chyba się da, jak masz dwa uarty, to jeden działa jako nadajnik/odbiornik,
drugi (przy pomocy drugiego max485) tylko slucha wyjść tego pierwszego, podstawowego,
jak moduł jest w trybie odbiór - oba słysza to samo, jak moduł jest nadawca, drugi kontrolny uart usłyszy to co na szynie - albo poprawne echo albo 'krzaki' jak jest kolizja i ktoś się 'wciął', ale to filozofuje teraz, ja obstawiam jednego master-a i stadko urządzeń podrzędnych gadających tylko wtedy kiedy są pytane, najmniej kłopotów...
Pajączku, odbiornik cały czas jest do tej pary dołączony i odbiera KAŻDĄ transmisję. To nadajnik (dołączony do tej samej pary przewodów) musisz odłączać aby inne urządzenie mogło nadawać (aby nie było kolizji). Do tego wystarcza pojedynczy UART, a dane odbierane w trakcie własnej transmisji można: a) zignorować (wtedy lepiej wyłączyc odbieranie w UART-jezeli możliwe), b) użyć do kontroli kolizji (ale to nie jest wystarczające sprawdzenie, z powodu sposobu pracy odbiornika( moment próbkowania sygnału), twój odbiornik może pokazać prawidłową daną ale odbiornik innego urządzenia może odebrac już daną z błędem). Właśnie organizacja dołączania i odłączania transmitera jest całą zabawą na takiej szynie. A w szczególności wszystkie możliwe przypadki kiedy cos idzie nie tak jak powinno, kiedy trzeba to wykryć i wyjść z tej sytuacji. Ogólnie nie ma na to prostego rozwiązania. Rozwiązania sprzętowe (np. CAN, oczywiście w warstwie logicznej) są drogie ale pewne, ale skomplikowane, ale..., Rozwiązania programowe (na zwykłym UART) zawsze będą wnosiły większe opóżnienia oraz konieczność kontroli i operowania na kilku poziomach protokołu, dla uzyskania pewności że dane z jednego urządzenia zostały przekazane do innego)
Witam.
Pisaliście o dostępie do lini losowo, przekazywaniem pałeczki, i inne, ale nikt nie przypomniał tu zasady szczelin czasowych, priorytetach itp.
Najprostszy nasuwający mi się wykorzystujący to sposób aby rozwiazać problem gdy kilku chce nadawać: to ustalić priorytet urządzeń, czyli nadawanie ktorego urzadzenia jest wazniejsze. A od zakończenia jego nadawania o tym kto nastepny zajmie linię będzie decydował czas. Im urządzenie ma wyższy priorytet tym czas ten będzie dla niego krótszy.
Priorytet mozna by ustawiac recznie przy uruchamianiu sieci, a przy dodawaniu kolejnych urz do sieci mozna tez zrobic automatykę sprawdzającą i przydzielającą priorytet nowemu, przy pierwszym jego przyłaczaniu do sieci. Urządzenie z najwyzszym priorytetem moze puszczać też co jakis czas paczke synchronizującą, aby nie doszło do momentu ze po dlugiej ciszy kilku na raz bedzie mialo ochote nadawac ....
...mozna by tak dlugo wymyslac rozne rozwiazania...
pozdr
+5V
Pisaliście o dostępie do lini losowo, przekazywaniem pałeczki, i inne, ale nikt nie przypomniał tu zasady szczelin czasowych, priorytetach itp.
Najprostszy nasuwający mi się wykorzystujący to sposób aby rozwiazać problem gdy kilku chce nadawać: to ustalić priorytet urządzeń, czyli nadawanie ktorego urzadzenia jest wazniejsze. A od zakończenia jego nadawania o tym kto nastepny zajmie linię będzie decydował czas. Im urządzenie ma wyższy priorytet tym czas ten będzie dla niego krótszy.
Priorytet mozna by ustawiac recznie przy uruchamianiu sieci, a przy dodawaniu kolejnych urz do sieci mozna tez zrobic automatykę sprawdzającą i przydzielającą priorytet nowemu, przy pierwszym jego przyłaczaniu do sieci. Urządzenie z najwyzszym priorytetem moze puszczać też co jakis czas paczke synchronizującą, aby nie doszło do momentu ze po dlugiej ciszy kilku na raz bedzie mialo ochote nadawac ....
...mozna by tak dlugo wymyslac rozne rozwiazania...
pozdr
+5V
Jest tylko 1 problem.
Jak chcesz stwierdzic jakie to urzadzenia nadaja (i jakie maja priorytety ??). Jesli jest konflikt (2 lub wiecej nadaje jednoczesnie) to efektem transmisji jest brak transmisji, a wiec wymiany adresow (priorytetow). Jedynie urzadzenie o najwyzszym priorytecie moglo by twierdzic "Mam najwyzszy, wiec inni sie pewnie usuna", zas kazde majace mniejszy twierdzilo by:" ocho... ktos nadaje, moze ma wyzszy, wiec lepiej sie usune by nie bylo na mnie". Tylko co jesli nadawac chcialy 2 urzadzenia o nienajwyzszych priorytetach ??
Bis:
W sumie miales racje, cos mi sie podejrzane tam wydawalo, ale chyba nieslusznie.
Jak chcesz stwierdzic jakie to urzadzenia nadaja (i jakie maja priorytety ??). Jesli jest konflikt (2 lub wiecej nadaje jednoczesnie) to efektem transmisji jest brak transmisji, a wiec wymiany adresow (priorytetow). Jedynie urzadzenie o najwyzszym priorytecie moglo by twierdzic "Mam najwyzszy, wiec inni sie pewnie usuna", zas kazde majace mniejszy twierdzilo by:" ocho... ktos nadaje, moze ma wyzszy, wiec lepiej sie usune by nie bylo na mnie". Tylko co jesli nadawac chcialy 2 urzadzenia o nienajwyzszych priorytetach ??
Bis:
W sumie miales racje, cos mi sie podejrzane tam wydawalo, ale chyba nieslusznie.
założeniem jest że każde urządzenie ma inny priorytet, i to "instalator" je określa (coś za coś).
kolizja to czesto normalna sprawa, np. w ethernecie.
Twój przypadek gdy chca wszyscy na raz, sam sie rozwiąże przy kolejnej próbie nadawania, bo każde z tych urządzeń rozpocznie już w innym czasie.
inna rzecz, to to, że ten system raczej nie zakłada dużego obciążenia łącza, aby nie było przypadku że jakieś urządzenie (o niskim priorytecie) sie nie dopcha do łącza.
kolejne urządzenia możesz dołączać mając np. dokumentację, lub wykonując wczesniejsze sprawdzenie (np. to najzupełniej normalne w instalacjach systemów alarmowych).
jak chcesz dynamicznie dołaczać urządzenia do sieci, to stawiasz wyzsze wymagania, jak masz wyzsze wymagania, to "zapłać więcej" i wrzuć procedurki które to załatwią w mocniejszym procku, itp itd...
kolizja to czesto normalna sprawa, np. w ethernecie.
Twój przypadek gdy chca wszyscy na raz, sam sie rozwiąże przy kolejnej próbie nadawania, bo każde z tych urządzeń rozpocznie już w innym czasie.
inna rzecz, to to, że ten system raczej nie zakłada dużego obciążenia łącza, aby nie było przypadku że jakieś urządzenie (o niskim priorytecie) sie nie dopcha do łącza.
kolejne urządzenia możesz dołączać mając np. dokumentację, lub wykonując wczesniejsze sprawdzenie (np. to najzupełniej normalne w instalacjach systemów alarmowych).
jak chcesz dynamicznie dołaczać urządzenia do sieci, to stawiasz wyzsze wymagania, jak masz wyzsze wymagania, to "zapłać więcej" i wrzuć procedurki które to załatwią w mocniejszym procku, itp itd...
Kto jest online
Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 71 gości