Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:oqbdhp$ij$1$P...@n...chmurka.net
...
W dniu 2017-09-25 o 17:13, J.F. pisze:
>>> Czy taki sygnał z UARTa przydałby się do sterowania DE RS485 - mam
>>> wątpliwości.
>> Jak jednak widac - taki sygnal by sie przydal. Automatycznie
>> aktywowany.
>> Troche dziwne, ze go nie ma ... ale z drugiej strony - programistom
>> nie sprawia to problemu :-)

>Dawniej używaliśmy UARTy w PC, ale te linie RTS i chyba DTR
>używaliśmy do zupełnie innych celów - przełączaliśmy do 64 pętli
>prądowych (jedna linia - "na pętlę 0", druga linia - "na kolejną
>pętlę". Oczywiście poza tym linie te dostarczały zasilanie dla
>całości.
>Z tego wychodzi, mi, że nawet tam nie były sterowane automatycznie
>tylko ręcznie z programu.

Zdecydowanie nie byly sterowane automatycznie, a sterowanie reczne
trafialo na problem przerwania.
Ba - o ile pamietam, to pecetowy BIOS potrafil RTS wlaczyc, na CTS
poczekac ... ale juz RTS nie wylaczal.
Zreszta owczesne modemy juz byly full duplex.

To tylko ta kosc co Pszemol wygrzebal miala jakis automat.

Tym niemniej ... pecet byl "do wszystkiego" i mial port RS-232,
niepelny zreszta.

Male uC czesto uzywane z RS-485, to by im sie przydalo :-)

J.

do góry

J.F. <j...@p...onet.pl> wrote:
> Użytkownik "Piotr Gałka" napisał w wiadomości grup
> dyskusyjnych:oqbdhp$ij$1$P...@n...chmurka.net
...
> W dniu 2017-09-25 o 17:13, J.F. pisze:
>>>> Czy taki sygnał z UARTa przydałby się do sterowania DE RS485 - mam
>>>> wątpliwości.
>>> Jak jednak widac - taki sygnal by sie przydal. Automatycznie
>>> aktywowany.
>>> Troche dziwne, ze go nie ma ... ale z drugiej strony - programistom
>>> nie sprawia to problemu :-)
>
>> Dawniej używaliśmy UARTy w PC, ale te linie RTS i chyba DTR
>> używaliśmy do zupełnie innych celów - przełączaliśmy do 64 pętli
>> prądowych (jedna linia - "na pętlę 0", druga linia - "na kolejną
>> pętlę". Oczywiście poza tym linie te dostarczały zasilanie dla
>> całości.
>> Z tego wychodzi, mi, że nawet tam nie były sterowane automatycznie
>> tylko ręcznie z programu.
>
> Zdecydowanie nie byly sterowane automatycznie, a sterowanie reczne
> trafialo na problem przerwania.
> Ba - o ile pamietam, to pecetowy BIOS potrafil RTS wlaczyc, na CTS
> poczekac ... ale juz RTS nie wylaczal.
> Zreszta owczesne modemy juz byly full duplex.
>
> To tylko ta kosc co Pszemol wygrzebal miala jakis automat.
>
> Tym niemniej ... pecet byl "do wszystkiego" i mial port RS-232,
> niepelny zreszta.
>
> Male uC czesto uzywane z RS-485, to by im sie przydalo :-)
>
Problem mam teraz, bom rozpieszczony, a muszę się dogadać z jednopłytkowcem
przez jego rs232 a w swoim mam rs485 i obsługujemy trzy baudrate: 1200,
2400 i 9600.

Nie wypada mi przyjąć rozwiązania z konwertera "automatycznego", tego co to
odwróconym TX steruje nadajnikiem linii rs485, bo przecież to jest
druciarstwo, więc jak mi się nie uda gościa softwarowego od tego
jednopłytkowca przekonać aby mi machał RTSem w czasie gdy odpowiada na moje
zapytania to będzie kicha: NE555 i trzy jumpery do ustawiania baudrate
trzeba bedzie dać :-(

Ktoś się przypadkiem orientuje czy standardowe drivery do rs232 pod
linuksem nie umożliwiają takiej funkcji machania RTSem w takt nadawania?

do góry

W dniu 2017-09-26 o 04:38, Pszemol pisze:

> Problem mam teraz, bom rozpieszczony, a muszę się dogadać z jednopłytkowcem
> przez jego rs232 a w swoim mam rs485 i obsługujemy trzy baudrate: 1200,
> 2400 i 9600.
>
> Nie wypada mi przyjąć rozwiązania z konwertera "automatycznego", tego co to
> odwróconym TX steruje nadajnikiem linii rs485, bo przecież to jest
> druciarstwo, więc jak mi się nie uda gościa softwarowego od tego
> jednopłytkowca przekonać aby mi machał RTSem w czasie gdy odpowiada na moje
> zapytania to będzie kicha: NE555 i trzy jumpery do ustawiania baudrate
> trzeba bedzie dać :-(
>
> Ktoś się przypadkiem orientuje czy standardowe drivery do rs232 pod
> linuksem nie umożliwiają takiej funkcji machania RTSem w takt nadawania?

Co do samego drivera, to zapewne zależy to również od samego procka (nie
ja z tym walczyłem więc gdybam), ale na pewno przy starych jądrach
systemu (bodaj 2.6.x) i SAM9260 nie działało to poprawnie. Przy 3.x
podobno jest już OK, ale jeszcze nie mogę wyegzekwować potwierdzenia (są
ważniejsze sprawy - cokolwiek by to znaczyło).

Ale w ogóle to RS485 to bardzo wdzięczny temat - jak nie wiesz czy
zadziała to bierzesz MAXa w obudowie DIP (albo na płyteczce SO->DIP),
płytkę uniwersalną:
http://www.gotronik.pl/plytki-stykowe-c-16.html
i sprawdzasz. Szkoda czasu na rozważania teoretyczne. Jak już wiesz co i
jak to możesz się pozastanawiać jak zrobić.
A jak masz dość czasu to robisz to samo na PCB żeby nie mieć wątpliwości
czy przypadkiem któryś z drucików słabo nie stykał.

Pozdrawiam

DD

do góry

Użytkownik "Pszemol" napisał w wiadomości grup
dyskusyjnych:oqcejp$37t$...@d...me...
>>
>Problem mam teraz, bom rozpieszczony, a muszę się dogadać z
>jednopłytkowcem
>przez jego rs232 a w swoim mam rs485 i obsługujemy trzy baudrate:
>1200,
>2400 i 9600.

przerobic "swojego" na czterodruta ?

Ten jednoplytkowiec nie bedzie czegos wysylal nieproszony, tzn w
sposob niekontrolowany i grozący konfliktem ?

>Nie wypada mi przyjąć rozwiązania z konwertera "automatycznego", tego
>co to
>odwróconym TX steruje nadajnikiem linii rs485, bo przecież to jest
>druciarstwo, więc jak mi się nie uda gościa softwarowego od tego
>jednopłytkowca przekonać aby mi machał RTSem w czasie gdy odpowiada
>na moje
>zapytania to będzie kicha: NE555 i trzy jumpery do ustawiania
>baudrate
>trzeba bedzie dać :-(

www.ti.com/lit/ug/tidubw6/tidubw6.pdf
Masz tu schemat namaszczony przez TI :-)

do 9600 to chyba mozesz tez druciarstwo - po zmianie z 0 na 1 na
ulamek bita zostaw wlaczony nadajnik, pojemnosci kabla przeladuje, a
potem rezystory podtrzymujace wystarcza.

>Ktoś się przypadkiem orientuje czy standardowe drivery do rs232 pod
>linuksem nie umożliwiają takiej funkcji machania RTSem w takt
>nadawania?

cos mi mignelo, ze maja ... i ze to nie do konca dobrze dziala.
No bo sam wiesz - Exar, albo problem przerwania, a unix lubi dlugie
bufory :-)

J.

do góry

W dniu 2017-09-26 o 04:38, Pszemol pisze:
> Problem mam teraz, bom rozpieszczony, a muszę się dogadać z jednopłytkowcem
> przez jego rs232 a w swoim mam rs485 i obsługujemy trzy baudrate: 1200,
> 2400 i 9600.
>
> Nie wypada mi przyjąć rozwiązania z konwertera "automatycznego", tego co to
> odwróconym TX steruje nadajnikiem linii rs485, bo przecież to jest
> druciarstwo, więc jak mi się nie uda gościa softwarowego od tego
> jednopłytkowca przekonać aby mi machał RTSem w czasie gdy odpowiada na moje
> zapytania to będzie kicha: NE555 i trzy jumpery do ustawiania baudrate
> trzeba bedzie dać :-(
>
> Ktoś się przypadkiem orientuje czy standardowe drivery do rs232 pod
> linuksem nie umożliwiają takiej funkcji machania RTSem w takt nadawania?
>

Nie wiem czy dobrze rozumiem Twój problem.
Protokoły zazwyczaj zawierają jakieś mechanizmy powtarzania jak brak
odpowiedzi. Pierwszą ramkę można wykorzystać do rozpoznania prędkości na
której ten drugi chodzi i się na nią ustawić.
P.G.

do góry

W dniu 2017-09-26 o 04:38, Pszemol pisze:

> Problem mam teraz, bom rozpieszczony, a muszę się dogadać z jednopłytkowcem
> przez jego rs232 a w swoim mam rs485 i obsługujemy trzy baudrate: 1200,
> 2400 i 9600.
>
> Nie wypada mi przyjąć rozwiązania z konwertera "automatycznego", tego co to
> odwróconym TX steruje nadajnikiem linii rs485, bo przecież to jest
> druciarstwo, więc jak mi się nie uda gościa softwarowego od tego
> jednopłytkowca przekonać aby mi machał RTSem w czasie gdy odpowiada na moje
> zapytania to będzie kicha: NE555 i trzy jumpery do ustawiania baudrate
> trzeba bedzie dać :-(

Jeszcze jedna sprawa mi się przypomniała, chociaż z Linuxem to trudniej
będzie. Jeżeli masz wpływ na protokół i na magistrali nie będziesz miał
innych urządzeń, to opcja z 555 jest o tyle prostsza, że można wymusić
odstępy między transmisją kolejnych pakietów, co zapobiegnie
przedwczesnemu włączaniu nadajnika - po prostu z definicji jest pauza
między pakietami. Przy niewielkim wymaganiu na transfer można to nawet
na stałe ustawić - żeby nie trzeba było jumperów.

Pozdrawiam

DD

do góry

W dniu 2017-09-26 o 04:38, Pszemol pisze:
> Ktoś się przypadkiem orientuje czy standardowe drivery do rs232 pod
> linuksem nie umożliwiają takiej funkcji machania RTSem w takt nadawania?

Jak kiedyś przerabiałem podobny temat to były patche kernela pod kilka
mikroprocesorów, które mają
sprzętowo zaimplementowane sterowanie kierunkiem RS-485 w module UART. Teraz już
chyba są włączone
do oficjalnych źródeł kernela. W moim przypadku był to AT91SAM9260. Działało
bezbłędnie dla
dowolnych prędkości transmisji.

do góry

Dariusz Dorochowicz <dadoro@_wp_._com_> wrote:
> W dniu 2017-09-26 o 04:38, Pszemol pisze:
>
>> Problem mam teraz, bom rozpieszczony, a muszę się dogadać z jednopłytkowcem
>> przez jego rs232 a w swoim mam rs485 i obsługujemy trzy baudrate: 1200,
>> 2400 i 9600.
>>
>> Nie wypada mi przyjąć rozwiązania z konwertera "automatycznego", tego co to
>> odwróconym TX steruje nadajnikiem linii rs485, bo przecież to jest
>> druciarstwo, więc jak mi się nie uda gościa softwarowego od tego
>> jednopłytkowca przekonać aby mi machał RTSem w czasie gdy odpowiada na moje
>> zapytania to będzie kicha: NE555 i trzy jumpery do ustawiania baudrate
>> trzeba bedzie dać :-(
>>
>> Ktoś się przypadkiem orientuje czy standardowe drivery do rs232 pod
>> linuksem nie umożliwiają takiej funkcji machania RTSem w takt nadawania?
>
> Co do samego drivera, to zapewne zależy to również od samego procka (nie
> ja z tym walczyłem więc gdybam), ale na pewno przy starych jądrach
> systemu (bodaj 2.6.x) i SAM9260 nie działało to poprawnie. Przy 3.x
> podobno jest już OK, ale jeszcze nie mogę wyegzekwować potwierdzenia (są
> ważniejsze sprawy - cokolwiek by to znaczyło).
>
> Ale w ogóle to RS485 to bardzo wdzięczny temat - jak nie wiesz czy
> zadziała to bierzesz MAXa w obudowie DIP (albo na płyteczce SO->DIP),
> płytkę uniwersalną:
> http://www.gotronik.pl/plytki-stykowe-c-16.html
> i sprawdzasz. Szkoda czasu na rozważania teoretyczne. Jak już wiesz co i
> jak to możesz się pozastanawiać jak zrobić.
> A jak masz dość czasu to robisz to samo na PCB żeby nie mieć wątpliwości
> czy przypadkiem któryś z drucików słabo nie stykał.
>
Nie bardzo rozumiem o czym Ty piszesz... co Ty chcesz sprawdzać budując
nową płytkę z MAXem?
I ja piszę o jednopłytkowym pececie, który został użyty przez inną firmę i
z tym produktem muszę współpracować.

do góry

J.F. <j...@p...onet.pl> wrote:
> Użytkownik "Pszemol" napisał w wiadomości grup
> dyskusyjnych:oqcejp$37t$...@d...me...
>>>
>> Problem mam teraz, bom rozpieszczony, a muszę się dogadać z
>> jednopłytkowcem
>> przez jego rs232 a w swoim mam rs485 i obsługujemy trzy baudrate:
>> 1200,
>> 2400 i 9600.
>
> przerobic "swojego" na czterodruta ?

Mógłbym, lokalnie, ale dalej musiałbym puścić tylko dwa druty, bo taki mamy
standard.

> Ten jednoplytkowiec nie bedzie czegos wysylal nieproszony, tzn w
> sposob niekontrolowany i grozący konfliktem ?

Nie. On ma odpowiadać tylko zapytany. Jak przestało na grzecznego slave w
RS485.

>> Nie wypada mi przyjąć rozwiązania z konwertera "automatycznego", tego
>> co to
>> odwróconym TX steruje nadajnikiem linii rs485, bo przecież to jest
>> druciarstwo, więc jak mi się nie uda gościa softwarowego od tego
>> jednopłytkowca przekonać aby mi machał RTSem w czasie gdy odpowiada
>> na moje
>> zapytania to będzie kicha: NE555 i trzy jumpery do ustawiania
>> baudrate
>> trzeba bedzie dać :-(
>
> 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.

> do 9600 to chyba mozesz tez druciarstwo - po zmianie z 0 na 1 na
> ulamek bita zostaw wlaczony nadajnik, pojemnosci kabla przeladuje, a
> potem rezystory podtrzymujace wystarcza.

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.

>> Ktoś się przypadkiem orientuje czy standardowe drivery do rs232 pod
>> linuksem nie umożliwiają takiej funkcji machania RTSem w takt
>> nadawania?
>
> cos mi mignelo, ze maja ... i ze to nie do konca dobrze dziala.
> No bo sam wiesz - Exar, albo problem przerwania, a unix lubi dlugie
> bufory :-)

A pamiętasz jakieś słowa kluczowe aby to poszukać w linuksie?

do góry

Piotr Gałka <p...@c...pl> wrote:
> W dniu 2017-09-26 o 04:38, Pszemol pisze:
>> Problem mam teraz, bom rozpieszczony, a muszę się dogadać z jednopłytkowcem
>> przez jego rs232 a w swoim mam rs485 i obsługujemy trzy baudrate: 1200,
>> 2400 i 9600.
>>
>> Nie wypada mi przyjąć rozwiązania z konwertera "automatycznego", tego co to
>> odwróconym TX steruje nadajnikiem linii rs485, bo przecież to jest
>> druciarstwo, więc jak mi się nie uda gościa softwarowego od tego
>> jednopłytkowca przekonać aby mi machał RTSem w czasie gdy odpowiada na moje
>> zapytania to będzie kicha: NE555 i trzy jumpery do ustawiania baudrate
>> trzeba bedzie dać :-(
>>
>> Ktoś się przypadkiem orientuje czy standardowe drivery do rs232 pod
>> linuksem nie umożliwiają takiej funkcji machania RTSem w takt nadawania?
>>
>
> Nie wiem czy dobrze rozumiem Twój problem.
> Protokoły zazwyczaj zawierają jakieś mechanizmy powtarzania jak brak
> odpowiedzi. Pierwszą ramkę można wykorzystać do rozpoznania prędkości na
> której ten drugi chodzi i się na nią ustawić.

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.

do góry