Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:oqfs4e$osq$1$P...@n...chmurka.ne
t...
W dniu 2017-09-26 o 20:17, Pszemol pisze:
>> Nie. On ma odpowiadać tylko zapytany. Jak przestało na grzecznego
>> slave w
>> RS485.

>To inaczej używamy RS485 :)
>U nas każdy się odzywa jak ma coś do powiedzenia.

No to masz problem konfliktow do rozwiazania.

>>> www.ti.com/lit/ug/tidubw6/tidubw6.pdf
>>> Masz tu schemat namaszczony przez TI :-)
>
>> Tak, znalazłem to samo już parę dni temu, zanim rozebrałem tego
>> małego, bez
>> jumperków do ustawiania baudrate.

>OIDP różne 555 różnie się zachowują jak sygnały R i S dają sprzeczne
>wytyczne dla przerzutnika.

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.
A tam w ogole jakis tajemniczy NA555

>Ale tak mi się wydaje, że tu nie spowoduje to problemu (kwestia
>momentu włączenia dla kolejnego bajtu.

Nie analizowalem tego, bo pomysl uzycia 555 jakis dziwny mi sie od
poczatku wydawal, a opis wyjatkowo ubogi :-)

Wydaje mi sie, ze chca to wyzwalac bitem startu, a czas dobrany na
caly pakiet ... ktory musi byc stałej dlugosci.

Troche za malo dokladne mi sie to wydaje - albo zbyt precyzyjnego
strojenia wymaga.

>> Nie mogę zrobić takiego druciarstwa.
>> W czasie wysyłania bitów '1' nie sterujesz linią. Zamiast 5V
>> odstępu między
>> drutami masz jakies 200mV. Sorry, ale to nieprofesjonalne.

>Czekaj, czekaj, jakie 5V i 200mV.
>Nadajnik daje typowo tylko jakieś 2,5V (wynika z konieczności
>zabezpieczenia buforów wyjściowych nadajnika przed różnicą mas +-7V).
>Po długim kablu (obciążonym rezystorem dopasowującym) masz niewiele
>ponad te 200mV i wszystko ma działać. Typowy odbiornik może mieć próg
>dowolnie gdzieś miedzy -200 a +200mV więc faktyczny zapas to tyle co
>po tym kablu jest ponad te 200mV.
>Odbiorniki fail save gdy sygnał jest 0V ma zapas chyba rzędu 70mV.
>Wcale nie musi być mniej niż normalny odbiornik (za długim kablem) z
>włączonym nadajnikiem dla stanu 1.
>Jak nie wiadomo, czy tamten ma fail-save to można opornikami wymusić
>stan ponad 200mV.

Tak czy inaczej druciarstwo - zamiast podac 2.5V podajemy 200mV :-)

> Gdyby prędkość była 57600, czy 115200 a kabel 1km to uważałbym, że
> silne przeładowanie na stan 1 przed puszczeniem luzem jest
> konieczne, ale przy małych prędkościach to nawet bez tego RS485 nie
> powinien mieć żadnych problemów.

Dodac jakis timerek co by odmierzyl ten 1 bit na przeladowanie byloby
stosunkowo prosto.


J.

do góry

Piotr Gałka <p...@c...pl> wrote:
> W dniu 2017-09-26 o 20:17, Pszemol pisze:
>>
>> Tak, autobaudrate to jedna z opcji uniknięcia jumperór do wyboru baudrate i
>> zastąpienie ich dodatkowym procesorem wstawionym tam tylko w tym celu -
>> troszkę brzmi jak strzelanie z armaty do komara.
>>
> Rozumiem, że ten, który ma po tym RS485 gadać już nie ma zapasu mocy
> obliczeniowej aby to sobie wyliczyć.

Co miałby liczyć? Założyłem sytuację w której pecet jednopłytkowiec nie
może z jakiegoś powodu machać linią RTS pełniącą w RS485 funkcję TXen.

do góry

Piotr Gałka <p...@c...pl> wrote:
> W dniu 2017-09-26 o 20:17, Pszemol pisze:
>
>> Nie. On ma odpowiadać tylko zapytany. Jak przestało na grzecznego slave w
>> RS485.
>
> To inaczej używamy RS485 :)
> U nas każdy się odzywa jak ma coś do powiedzenia.

2 przewody, half duplex. Jak Ty używasz?

>>> www.ti.com/lit/ug/tidubw6/tidubw6.pdf
>>> Masz tu schemat namaszczony przez TI :-)
>>
>> Tak, znalazłem to samo już parę dni temu, zanim rozebrałem tego małego, bez
>> jumperków do ustawiania baudrate.
>
> OIDP różne 555 różnie się zachowują jak sygnały R i S dają sprzeczne
> wytyczne dla przerzutnika. Ale tak mi się wydaje, że tu nie spowoduje to
> problemu (kwestia momentu włączenia dla kolejnego bajtu.

:-)

>> Nie mogę zrobić takiego druciarstwa.
>> W czasie wysyłania bitów '1' nie sterujesz linią. Zamiast 5V odstępu między
>> drutami masz jakies 200mV. Sorry, ale to nieprofesjonalne.
>
> Czekaj, czekaj, jakie 5V i 200mV.
> Nadajnik daje typowo tylko jakieś 2,5V (wynika z konieczności
> zabezpieczenia buforów wyjściowych nadajnika przed różnicą mas +-7V). Po
> długim kablu (obciążonym rezystorem dopasowującym) masz niewiele ponad
> te 200mV i wszystko ma działać. Typowy odbiornik może mieć próg dowolnie
> gdzieś miedzy -200 a +200mV więc faktyczny zapas to tyle co po tym kablu
> jest ponad te 200mV.
> Odbiorniki fail save gdy sygnał jest 0V ma zapas chyba rzędu 70mV. Wcale
> nie musi być mniej niż normalny odbiornik (za długim kablem) z włączonym
> nadajnikiem dla stanu 1.
> Jak nie wiadomo, czy tamten ma fail-save to można opornikami wymusić
> stan ponad 200mV. Gdyby prędkość była 57600, czy 115200 a kabel 1km to
> uważałbym, że silne przeładowanie na stan 1 przed puszczeniem luzem jest
> konieczne, ale przy małych prędkościach to nawet bez tego RS485 nie
> powinien mieć żadnych problemów.

Jakoś wyobrażam sobie, że łatwiej wstrzyknąć do linii zakłócenia gdy żaden
nadajnik nie jest włączony i linia jest tylko lekko spolaryzowana
opornikami fail safe o względnie dużej wartości (a więc masz źródło
napięcia o dużej Rwew, niż gdy nadajnik wymusza w niej napięcie
tranzystorami push pull, źródło napięcia o małej Rwew.

do góry

J.F. <j...@p...onet.pl> wrote:
> Użytkownik "Piotr Gałka" napisał w wiadomości grup
> dyskusyjnych:oqfs4e$osq$1$P...@n...chmurka.ne
t...
> W dniu 2017-09-26 o 20:17, Pszemol pisze:
>>> Nie. On ma odpowiadać tylko zapytany. Jak przestało na grzecznego
>>> slave w
>>> RS485.
>
>> To inaczej używamy RS485 :)
>> U nas każdy się odzywa jak ma coś do powiedzenia.
>
> No to masz problem konfliktow do rozwiazania.
>
>>>> www.ti.com/lit/ug/tidubw6/tidubw6.pdf
>>>> Masz tu schemat namaszczony przez TI :-)
>>
>>> Tak, znalazłem to samo już parę dni temu, zanim rozebrałem tego
>>> małego, bez
>>> jumperków do ustawiania baudrate.
>
>> OIDP różne 555 różnie się zachowują jak sygnały R i S dają sprzeczne
>> wytyczne dla przerzutnika.
>
> 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.
> A tam w ogole jakis tajemniczy NA555

Podejrzewam że po prostu Texas Instrument tak oznacza 555 i po prostu
prmuje swoją kostkę.

>> Ale tak mi się wydaje, że tu nie spowoduje to problemu (kwestia
>> momentu włączenia dla kolejnego bajtu.
>
> Nie analizowalem tego, bo pomysl uzycia 555 jakis dziwny mi sie od
> poczatku wydawal, a opis wyjatkowo ubogi :-)

Czemu dziwny?

> Wydaje mi sie, ze chca to wyzwalac bitem startu, a czas dobrany na
> caly pakiet ... ktory musi byc stałej dlugosci.

Nie cały pakiet, jeden bajt z hakiem.
Owszem, bit startu wyzwala, a potem każde następne zero wydłuża.

Generalnie jest zasada w RS485 half duplex, że przełączanie na nadawanie
odbywa się po czasie równym lub większym od czasu transmisji półtora znaku.

> Troche za malo dokladne mi sie to wydaje - albo zbyt precyzyjnego
> strojenia wymaga.

Trzebaby policzyć jak wyglądają tolerancje czasów uzyskanych dla NA555 dla
np baudrate 9600, gdzie transmisja znaku 7 bitowego z bitem parzystości, a
więc 10 bitów wliczając start i stop trwa ciut ponad 1ms.

>>> Nie mogę zrobić takiego druciarstwa.
>>> W czasie wysyłania bitów '1' nie sterujesz linią. Zamiast 5V
>>> odstępu między
>>> drutami masz jakies 200mV. Sorry, ale to nieprofesjonalne.
>
>> Czekaj, czekaj, jakie 5V i 200mV.
>> Nadajnik daje typowo tylko jakieś 2,5V (wynika z konieczności
>> zabezpieczenia buforów wyjściowych nadajnika przed różnicą mas +-7V).
>> Po długim kablu (obciążonym rezystorem dopasowującym) masz niewiele
>> ponad te 200mV i wszystko ma działać. Typowy odbiornik może mieć próg
>> dowolnie gdzieś miedzy -200 a +200mV więc faktyczny zapas to tyle co
>> po tym kablu jest ponad te 200mV.
>> Odbiorniki fail save gdy sygnał jest 0V ma zapas chyba rzędu 70mV.
>> Wcale nie musi być mniej niż normalny odbiornik (za długim kablem) z
>> włączonym nadajnikiem dla stanu 1.
>> Jak nie wiadomo, czy tamten ma fail-save to można opornikami wymusić
>> stan ponad 200mV.
>
> Tak czy inaczej druciarstwo - zamiast podac 2.5V podajemy 200mV :-)

To już nawet nie o te same wolty się rozchodzi a łatwość zakłócenia linii
sterowanej wysokooporowym źródłem napięcia.

>> Gdyby prędkość była 57600, czy 115200 a kabel 1km to uważałbym, że
>> silne przeładowanie na stan 1 przed puszczeniem luzem jest
>> konieczne, ale przy małych prędkościach to nawet bez tego RS485 nie
>> powinien mieć żadnych problemów.
>
> Dodac jakis timerek co by odmierzyl ten 1 bit na przeladowanie byloby
> stosunkowo prosto.

Wciąż druciarstwo :-) I lepiej się dogadać z programistą, aby machał RTSem.
O ile okaże się chłop kumaty...

do góry

Użytkownik "Pszemol" napisał w wiadomości grup
dyskusyjnych:oqg454$epa$...@d...me...
J.F. <j...@p...onet.pl> wrote:
>>>> www.ti.com/lit/ug/tidubw6/tidubw6.pdf
>>>> Masz tu schemat namaszczony przez TI :-)
>> [...]
>> A tam w ogole jakis tajemniczy NA555
>Podejrzewam że po prostu Texas Instrument tak oznacza 555 i po prostu
>prmuje swoją kostkę.

Tez tak mysle ... ale strzezonego ..

>>> Ale tak mi się wydaje, że tu nie spowoduje to problemu (kwestia
>>> momentu włączenia dla kolejnego bajtu.
>
>> Nie analizowalem tego, bo pomysl uzycia 555 jakis dziwny mi sie od
>> poczatku wydawal, a opis wyjatkowo ubogi :-)
>Czemu dziwny?

Bo jego mozliwosci nie bardzo mi pasuja do zadania ... choc moze sie
mylilem.

>> Wydaje mi sie, ze chca to wyzwalac bitem startu, a czas dobrany na
>> caly pakiet ... ktory musi byc stałej dlugosci.
>Nie cały pakiet, jeden bajt z hakiem.

Napisali "fixed length packet". I dla przykladu podali 30 bitow :-)
Przyznaje - na bajtach mialoby to spory sens.

>Owszem, bit startu wyzwala, a potem każde następne zero wydłuża.

Nie, 555 nie jest "retrigerable".
Sens ma, gdy jest nastrojony na 9.5 bita, bit startu wyzwala, potem
mamy 8 bitow danych, potem jeden bit stopu, i w jego polowie 555 sie
wylacza.
Kolejny bit startu wyzwala, i tak sie nadaja kolejne bajty, jedyne co
nam moze przeszkadzac to to wylaczenie nadajnika w połowie bitu stopu.

Ale ... to wymaga precyzyjnego ustawienia na te 9.5 bita.

>Generalnie jest zasada w RS485 half duplex, że przełączanie na
>nadawanie
>odbywa się po czasie równym lub większym od czasu transmisji półtora
>znaku.

no o d* w tym ukladzie.
Wyzwoli ci sie na pierwszym bajcie, wylaczy w polowie drugiego, wlaczy
dopiero na kolejnym zerze, a jedynki nie beda aktywnie wysylane .

No i ... masz 800MHz procesor, jestes pewien, ze nie odpowie w czasie
szybszym niz ~4 bity, 0.4ms.

>>> Czekaj, czekaj, jakie 5V i 200mV.
>>> Nadajnik daje typowo tylko jakieś 2,5V (wynika z konieczności
>>> zabezpieczenia buforów wyjściowych nadajnika przed różnicą mas
>>> +-7V).
>>> Po długim kablu (obciążonym rezystorem dopasowującym) masz
>>> niewiele
>>> ponad te 200mV i wszystko ma działać. Typowy odbiornik może mieć
>>> próg
>>> dowolnie gdzieś miedzy -200 a +200mV więc faktyczny zapas to tyle
>>> co
>>> po tym kablu jest ponad te 200mV.
>>> Odbiorniki fail save gdy sygnał jest 0V ma zapas chyba rzędu 70mV.
>>> Wcale nie musi być mniej niż normalny odbiornik (za długim kablem)
>>> z
>>> włączonym nadajnikiem dla stanu 1.
>>> Jak nie wiadomo, czy tamten ma fail-save to można opornikami
>>> wymusić
>>> stan ponad 200mV.
>
>> Tak czy inaczej druciarstwo - zamiast podac 2.5V podajemy 200mV :-)

>To już nawet nie o te same wolty się rozchodzi a łatwość zakłócenia
>linii
>sterowanej wysokooporowym źródłem napięcia.

Niskooporowym, bo terminatory ~120 ohm :-)

J.

do góry

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.

do góry

W dniu 2017-09-27 o 13:56, Pszemol pisze:
>> U nas każdy się odzywa jak ma coś do powiedzenia.
>
> 2 przewody, half duplex. Jak Ty używasz?

Napisałem przed chwilą w odpowiedzi dla J.F.

> Jakoś wyobrażam sobie, że łatwiej wstrzyknąć do linii zakłócenia gdy żaden
> nadajnik nie jest włączony i linia jest tylko lekko spolaryzowana
> opornikami fail safe o względnie dużej wartości (a więc masz źródło
> napięcia o dużej Rwew, niż gdy nadajnik wymusza w niej napięcie
> tranzystorami push pull, źródło napięcia o małej Rwew.
>

Zakończenie zawsze musi mieć impedancję taką jak linia. Typowe dla RS485
podobno 120om, ale my używamy obecnie standardowej skrętki UTP więc 100om.

Więc impedancja źródła wymuszającego napięcie musi być rzędu 100om.
Scalak fail-save nie wymaga wymuszania - po prostu jego próg jest
precyzyjniej ustawiony - nie -200mV do + 200mV tylko np -100mV +-30mV (a
może na plusach bo już nie chce mi się dochodzić czy jak jest 1-ka to
się nazywa, że napięcie na linii dodatnie, czy ujemne).

Zapewne wymuszenie przez nadajnik daje większy odstęp od zakłóceń, ale
nie obawiałbym się sytuacji dobrze zdefiniowanego fail-save. To jest
skrętka - praktycznie znikomo wrażliwa na zakłócenia wnikające do niej
jako różnica napięć. Zakłócenia różnicowe pojawią się chyba najpewniej
jako wynik zamiany zakłóceń sumacyjnych na różnicowe na niesymetriach
nadajników/odbiorników. Podejrzewam, że włączony nadajnik może być
bardziej niesymetryczny niż odbiornik, czy rezystor zakończenia linii
(my stosujemy scalaki fail-save więc nie wymuszamy żadnego napięcia gdy
nikt nie steruje linii).
P.G.

do góry

W dniu 2017-09-27 o 13:56, Pszemol pisze:
> Piotr Gałka <p...@c...pl> wrote:
>> W dniu 2017-09-26 o 20:17, Pszemol pisze:
>>>
>>> Tak, autobaudrate to jedna z opcji uniknięcia jumperór do wyboru baudrate i
>>> zastąpienie ich dodatkowym procesorem wstawionym tam tylko w tym celu -
>>> troszkę brzmi jak strzelanie z armaty do komara.
>>>
>> Rozumiem, że ten, który ma po tym RS485 gadać już nie ma zapasu mocy
>> obliczeniowej aby to sobie wyliczyć.
>
> Co miałby liczyć? Założyłem sytuację w której pecet jednopłytkowiec nie
> może z jakiegoś powodu machać linią RTS pełniącą w RS485 funkcję TXen.
>

Zapewne nie dokładnie wyobrażam sobie co masz do zrobienia.
Rozumiałem, że Twoje urządzenie ma się połączyć z jakimś innym i nie
wiadomo na jakiej prędkości tamten gada.
Pisałem o wyliczeniu z jaką prędkością próbuje się ze mną połączyć ten
drugi na podstawie jego pierwszej ramki (której treść tracimy, licząc,
że powtórzy) i potem ustawieniu się na tę prędkość.
A Ty na to, że to wymagało by dodatkowego procesora - to mnie zdziwiło,
ale to może wynikać z tego, że ja kompletnie nie rozumiem w jakim
środowisku działasz i nie zadałem sobie trudu, aby to ogarnąć (sorry).
P.G.

do góry

W dniu 2017-09-27 o 14:04, Pszemol pisze:
>
> Nie cały pakiet, jeden bajt z hakiem.
> Owszem, bit startu wyzwala, a potem każde następne zero wydłuża.

Chyba nie.
Stan się nie może zmienić (bo cały czas musi być na linii), a bez zmiany
stanu nie ma rozładowania kondensatora a więc nie ma wydłużenia.

Aby zrobić na 555 generator z wydłużaniem trzeba na zewnątrz dobudować
układ rozładowywania kondensatora a tu tego nie ma (ale teraz nie
zaglądałem ponownie).

> Trzebaby policzyć jak wyglądają tolerancje czasów uzyskanych dla NA555 dla
> np baudrate 9600, gdzie transmisja znaku 7 bitowego z bitem parzystości, a
> więc 10 bitów wliczając start i stop trwa ciut ponad 1ms.

Tolerancje (w %) będą praktycznie niezależne od baudrate. Myślę, że uda
się uzyskać zadowalający wynik dla jednej sztuki, ale w seryjnej
produkcji to chyba już nie za bardzo, ale kto wie.
P.G.

do góry

J.F. <j...@p...onet.pl> wrote:
> Użytkownik "Pszemol" napisał w wiadomości grup
> dyskusyjnych:oqg454$epa$...@d...me...
> J.F. <j...@p...onet.pl> wrote:
>>>>> www.ti.com/lit/ug/tidubw6/tidubw6.pdf
>>>>> Masz tu schemat namaszczony przez TI :-)
>>> [...]
>>> A tam w ogole jakis tajemniczy NA555
>> Podejrzewam że po prostu Texas Instrument tak oznacza 555 i po prostu
>> prmuje swoją kostkę.
>
> Tez tak mysle ... ale strzezonego ..
>
>>>> Ale tak mi się wydaje, że tu nie spowoduje to problemu (kwestia
>>>> momentu włączenia dla kolejnego bajtu.
>>
>>> Nie analizowalem tego, bo pomysl uzycia 555 jakis dziwny mi sie od
>>> poczatku wydawal, a opis wyjatkowo ubogi :-)
>> Czemu dziwny?
>
> Bo jego mozliwosci nie bardzo mi pasuja do zadania ... choc moze sie
> mylilem.

Jeśli może pracować jako uniwibrator to nie widze nic dziwnego.

>>> Wydaje mi sie, ze chca to wyzwalac bitem startu, a czas dobrany na
>>> caly pakiet ... ktory musi byc stałej dlugosci.
>> Nie cały pakiet, jeden bajt z hakiem.
>
> Napisali "fixed length packet". I dla przykladu podali 30 bitow :-)
> Przyznaje - na bajtach mialoby to spory sens.

No każdy 7-bitowy bajt będzie miał otoczkę start, d0..d6, parity i stop -
więc masz np fixed lenght packet of 10 bits :-)

>> Owszem, bit startu wyzwala, a potem każde następne zero wydłuża.
>
> Nie, 555 nie jest "retrigerable".
> Sens ma, gdy jest nastrojony na 9.5 bita, bit startu wyzwala, potem
> mamy 8 bitow danych, potem jeden bit stopu, i w jego polowie 555 sie
> wylacza.

Oj, to muszę to przestudiować dokładniej co TI napisał bo przyznaję że po
łebkach przejrzałem tylko :-)

Nie wiem czy łatwo będzie uzyskać dokładnośc czasówek 9,5 znaku w gorące
lato Arizony i głębokiej zimy w górach Kolorado...

> Kolejny bit startu wyzwala, i tak sie nadaja kolejne bajty, jedyne co
> nam moze przeszkadzac to to wylaczenie nadajnika w połowie bitu stopu.
>
> Ale ... to wymaga precyzyjnego ustawienia na te 9.5 bita.

I tu widzę problem. Opornik 1% łatwo mieć, gorzej z kondziorkiem.

>> Generalnie jest zasada w RS485 half duplex, że przełączanie na
>> nadawanie
>> odbywa się po czasie równym lub większym od czasu transmisji półtora
>> znaku.
>
> no o d* w tym ukladzie.
> Wyzwoli ci sie na pierwszym bajcie, wylaczy w polowie drugiego, wlaczy
> dopiero na kolejnym zerze, a jedynki nie beda aktywnie wysylane .
>
> No i ... masz 800MHz procesor, jestes pewien, ze nie odpowie w czasie
> szybszym niz ~4 bity, 0.4ms.

Ma napisane w specyfikacji że ma grzecznie czekać.

>>>> Czekaj, czekaj, jakie 5V i 200mV.
>>>> Nadajnik daje typowo tylko jakieś 2,5V (wynika z konieczności
>>>> zabezpieczenia buforów wyjściowych nadajnika przed różnicą mas
>>>> +-7V).
>>>> Po długim kablu (obciążonym rezystorem dopasowującym) masz
>>>> niewiele
>>>> ponad te 200mV i wszystko ma działać. Typowy odbiornik może mieć
>>>> próg
>>>> dowolnie gdzieś miedzy -200 a +200mV więc faktyczny zapas to tyle
>>>> co
>>>> po tym kablu jest ponad te 200mV.
>>>> Odbiorniki fail save gdy sygnał jest 0V ma zapas chyba rzędu 70mV.
>>>> Wcale nie musi być mniej niż normalny odbiornik (za długim kablem)
>>>> z
>>>> włączonym nadajnikiem dla stanu 1.
>>>> Jak nie wiadomo, czy tamten ma fail-save to można opornikami
>>>> wymusić
>>>> stan ponad 200mV.
>>
>>> Tak czy inaczej druciarstwo - zamiast podac 2.5V podajemy 200mV :-)
>
>> To już nawet nie o te same wolty się rozchodzi a łatwość zakłócenia
>> linii
>> sterowanej wysokooporowym źródłem napięcia.
>
> Niskooporowym, bo terminatory ~120 ohm :-)

:-) ok

do góry