-
Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.chmurka.net!.POSTED.213.192.88.238
!not-for-mail
From: Piotr Gałka <p...@c...pl>
Newsgroups: pl.misc.elektronika
Subject: Re: Izolowany konwerter zrobić z RS232 na RS485
Date: Wed, 27 Sep 2017 17:41:28 +0200
Organization: news.chmurka.net
Message-ID: <oqggr6$t0$1$PiotrGalka@news.chmurka.net>
References: <opto2l$cpi$1@dont-email.me> <optqbr$dh$1@node2.news.atman.pl>
<oq383a$h18$1@dont-email.me> <oq39qv$t3$1@node2.news.atman.pl>
<oq3i3v$14g$1@dont-email.me>
<1twaf8qykgqv6$.12r519vb638hx.dlg@40tude.net>
<oq3ohg$jq0$1@dont-email.me> <w...@4...net>
<oq41og$kd1$1@dont-email.me> <oq58vm$jtf$1$PiotrGalka@news.chmurka.net>
<1igniw41jfh8l$.1pbrhp2du7lsa$.dlg@40tude.net>
<oq5u0c$rvk$1$PiotrGalka@news.chmurka.net>
<59c8d28a$0$15207$65785112@news.neostrada.pl>
<oqb4nt$t2m$1$PiotrGalka@news.chmurka.net>
<59c91d2a$0$5156$65785112@news.neostrada.pl>
<oqbdhp$ij$1$PiotrGalka@news.chmurka.net>
<59c93c34$0$640$65785112@news.neostrada.pl> <oqcejp$37t$1@dont-email.me>
<59ca0b2c$0$15194$65785112@news.neostrada.pl>
<oqe5km$on2$6@dont-email.me> <oqfs4e$osq$1$PiotrGalka@news.chmurka.net>
<59cb7df1$0$5147$65785112@news.neostrada.pl>
NNTP-Posting-Host: 213.192.88.238
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 27 Sep 2017 15:41:26 +0000 (UTC)
Injection-Info: news.chmurka.net; posting-account="PiotrGalka";
posting-host="213.192.88.238"; logging-data="928";
mail-complaints-to="abuse-news.(at).chmurka.net"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.3.0
Content-Language: pl
In-Reply-To: <59cb7df1$0$5147$65785112@news.neostrada.pl>
Xref: news-archive.icm.edu.pl pl.misc.elektronika:724181
[ ukryj nagłówki ]W dniu 2017-09-27 o 12:31, J.F. pisze:
>
> No to masz problem konfliktow do rozwiazania.
Jak decydowaliśmy (wieki temu) jak działamy na RS485 to wyszło nam, że
tak jest znacznie szybciej niż czekać na odpytanie. Zakładaliśmy do 100
urządzeń na magistrali, a odpytanie 100 urządzeń to jakby nie liczył
musi potrwać.
Aby doszło do zderzenia ramek musi jednocześnie zajść kilka zdarzeń, a
każde jest mało lub bardzo mało prawdopodobne:
- podczas poprzedniej transmisji dwa (lub więcej) urządzeń podejmuje
decyzję "teraz ja",
- u 2 (co najmniej) generator losowego opóźnienia (między końcem
poprzedniej transmisji a wejściem na linię) akurat dał taką samą liczbę
i to mniejszą niż u pozostałych (gdy więcej jak dwu chce).
- trafią z wejściem na linię w odległości nie większej niż jakieś
1,5..2us (czas propagacji dla zakładanej maksymalnej długości kabla -
300m + jakieś różne opóźnienia wykrycia zbocza gdy u jednego 2,5V a u
drugiego 500mV), a jak nie są na przeciwległych końcach to zbieżność
musi być jeszcze dokładniejsza, a przecież wykrycie końca poprzedniej
transmisji jest obarczone jakimś jitterem, timery w nich nie chodzą
synchronicznie itp.
Jak nawet się zdarzy to brak odpowiedzi spowoduje powtórzenie, ale każdy
wylosuje nowe opóźnienie, a generator pseudolosowy oparty jest na stałej
TypNr (urządzenia) więc u każdego "chodzi" inaczej.
Dodatkowo, takie podejście daje możliwość przydzielania ramkom
priorytetów - alarmowe mogą dostawać liczby losowe z puli mniejszych niż
pozostałe.
> Hm, 555 to raczej nie powinny, bo to bylo od poczatku ustalone, ludzie
> uzywaja na milion sposobow i musi byc kompatybilne.
> Ale moze byc problem w jakis cmos wersjach.
Natknąłem się na to chyba faktycznie w jakichś cmos, ale to jest chyba
stan nie występujący w typowych aplikacjach więc normalnie bez znaczenia.
> Wydaje mi sie, ze chca to wyzwalac bitem startu, a czas dobrany na caly
> pakiet ... ktory musi byc stałej dlugosci.
W ogóle nie zaglądałem do opisu. Zakładam, że przyjęli generowanie
impulsu na czas jednego bajtu. Powinien się kończyć w trakcie bitów
stopu i być wyzwalany bitem startu. Ale biorąc pod uwagę jakieś rozrzuty
parametrów RC (produkcyjne i temperaturowe) to nie można być pewnym, czy
nie skończy się już w trakcie bitu startu i wtedy chyba dojdzie właśnie
do stanu jednocześnie Set i Reset.
P.G.
Następne wpisy z tego wątku
- 27.09.17 17:56 Piotr Gałka
- 27.09.17 18:03 Piotr Gałka
- 27.09.17 18:12 Piotr Gałka
- 27.09.17 18:30 Pszemol
- 28.09.17 06:50 Pszemol
- 28.09.17 06:50 Pszemol
- 28.09.17 10:50 Piotr Gałka
- 28.09.17 11:10 Piotr Gałka
- 28.09.17 11:44 J.F.
- 29.12.17 01:43 RoMan Mandziejewicz
- 29.12.17 07:41 J.F.
Najnowsze wątki z tej grupy
- System operacyjny dla 6800?
- Przyłączenie działki do sieci elektrycznej
- Działalność nierejestrowana/definicja sprzętu elektronicznego/misie i kolejki
- Smukły, długi ściągacz izolacji do kynaru
- rezystor 3 omy 400W
- [newbie] Jaki multimetr za 2-4 stówy?
- szafka sieciowa
- Raspberry Pi 5 + dyski SATA
- lutownica na węgiel
- Znów czary (albo niewiedza) - tym razem fotowoltaika
- Chess
- Vitruvian Man - parts 7-11a
- przeźroczyste koszulki
- Re: Win 10/11 nie lubi OKI
- Programator czasowy TUYA.
Najnowsze wątki
- 2024-05-17 ZŁOMNIK o pracy w TVN TURBO, nowych przepisach i współczesnej motoryzacji. Turbo Taryfa!
- 2024-05-17 Białystok => DevOps Engineer Conexa First (Contractor) <=
- 2024-05-17 Warszawa => Starszy inżynier oprogramowania (Rust) <=
- 2024-05-17 Zabrze => Junior HelpDesk <=
- 2024-05-17 Bieruń => Administrator i wdrożeniowiec Lotus Notes/Domino <=
- 2024-05-17 Warszawa => Senior Software Engineer PHP (BillPro) Contractor <=
- 2024-05-17 Warszawa => International freight forwarder <=
- 2024-05-17 Warszawa => Fullastack (Java) Developer <=
- 2024-05-17 Lublin => Business Development Manager - obszar bezpieczeństwa IT <=
- 2024-05-17 Warszawa => Mid PHP Developer (Laravel) <=
- 2024-05-17 Warszawa => Mid PHP Developer (Laravel) <=
- 2024-05-17 Warszawa => Senior PHP Developer (Symfony) <=
- 2024-05-18 wojna wojno a kredyt trzeba spłacać
- 2024-05-16 Samo rozładowywanie baterii trakcyjnej w elektryku.
- 2024-05-16 Warszawa => Senior PHP Developer (Symfony) <=