NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Jak stworzyć izolowany konwerter bez TTL z RS232 na RS485 - dostępne scalaki?
Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8 Next
J.F.
Guest
Guest
Sat Sep 23, 2017 6:28 am
Dnia Fri, 22 Sep 2017 22:05:41 -0500, Pszemol napisał(a):
Quote:
"J.F." <jfox_xnospamx@poczta.onet.pl> wrote in message
[...]
Ja piszę o automatycznym machaniu RTSem przez uarta odpowiednio
ustawionego.
Jest to funkcja uarta dedykowana właśnie do zastosowania w
RS485.
Ale 16550 chyba jeszcze tego nie ma.
Wiec malo ktory program ma :-(
Ficzerek ten się nazywa "RS-485 half duplex direction control".
Chyba masz rację, oryginalny 16C550 tego jeszcze nie miał,
miały to późniejsze chipy EXARa - od lat jestem jak widać rozpieszczony
używając uartów klasy XR16C850 i podobnych która mają właśnie taki
ficzerek i nie zdawałem sobie nawet sprawy jaki szczęściarz ze mnie
[...]
Ja piszę o automatycznym machaniu RTSem przez uarta odpowiednio
ustawionego.
Jest to funkcja uarta dedykowana właśnie do zastosowania w
RS485.
Ale 16550 chyba jeszcze tego nie ma.
Wiec malo ktory program ma :-(
Ficzerek ten się nazywa "RS-485 half duplex direction control".
Chyba masz rację, oryginalny 16C550 tego jeszcze nie miał,
miały to późniejsze chipy EXARa - od lat jestem jak widać rozpieszczony
używając uartów klasy XR16C850 i podobnych która mają właśnie taki
ficzerek i nie zdawałem sobie nawet sprawy jaki szczęściarz ze mnie
Jakk tak siegam pamiecia ... te dwa porty szeregowe nie zeszly do
chipsetu ?
A potem wyszly ... i faktycznie jestes rozpieszczony ze je w ogole
miales
czy na osobnej karcie ?
Quote:
4.18 Feature Control Register (FCTR) - Read/Write
FCTR[2]: IrDa RX Inversion
FCTR[2]: IrDa RX Inversion
Irda, ech, tez juz dawno nie widzialem :-)
Quote:
FCTR[3]: Auto RS-485 Direction Control
. Logic 0 = Standard ST16C550 mode. Transmitter generates an interrupt when
transmit holding register
becomes empty and transmit shift register is shifting data out.
. Logic 1 = Enable Auto RS485 Direction Control function. The direction
control signal, RS485 pin, changes
its output logic state from low to high one bit time after the last stop bit
of the last character is shifted out.
. Logic 0 = Standard ST16C550 mode. Transmitter generates an interrupt when
transmit holding register
becomes empty and transmit shift register is shifting data out.
. Logic 1 = Enable Auto RS485 Direction Control function. The direction
control signal, RS485 pin, changes
its output logic state from low to high one bit time after the last stop bit
of the last character is shifted out.
I o to chodzi.
Quote:
Also, the Transmit interrupt generation is delayed until the transmitter
shift register becomes empty.
shift register becomes empty.
A o to to IMO niekoniecznie.
Quote:
The
RS485 output pin will automatically return to a logic low when a data byte
is loaded into the TX FIFO.
https://www.exar.com/ds/16c850-231-080905.pdf
No piknie.
RS485 output pin will automatically return to a logic low when a data byte
is loaded into the TX FIFO.
https://www.exar.com/ds/16c850-231-080905.pdf
No piknie.
To jest osobny pin czy RTS ?
Bo jesli osobny ... chyba byles rozpieszczony komputerm/karta z portem
RS485 a nie 232.
Quote:
Ty opisałeś nazywa się "transmitter holding register empty" THRE a jest
jeszcze "transmitter empty" TEMT.
tylko TEMT przerwania nie zglasza.
wiec musisz procesor zmarnowac na pilnowanie, albo jakies
przerwanie/timer dobrac do predkosci :-P
No tak, lepiej mieć ficzerek opisany wyżej
jeszcze "transmitter empty" TEMT.
tylko TEMT przerwania nie zglasza.
wiec musisz procesor zmarnowac na pilnowanie, albo jakies
przerwanie/timer dobrac do predkosci :-P
No tak, lepiej mieć ficzerek opisany wyżej
Szczegolnie jak bufor dlugi i czekac trzeba nie na jeden czy 2 znaki,
ale np na 120 ... albo alternatywnie taki maly timerek dolozyc do
konwertera :-)
P.S. ale widze rozwiazanie - trzeba dolozyc jakies maly uC, ktory
bedzie monitorowal nadawane dane, rozpoznawal predkosc i sterowal
kierunkiem odpowiednio :-)
J.
Dariusz Dorochowicz
Guest
Guest
Sat Sep 23, 2017 8:21 am
W dniu 2017-09-23 o 04:01, Pszemol pisze:
Quote:
"Dariusz Dorochowicz" <_dadoro_@wp.com> wrote in message
news:oq430a$a57$1@node1.news.atman.pl...
Może z tego wydłubiesz?
https://ivel.pl/p2850,konwerter-rs232-rs485.html?gclid=EAIaIQobChMI-cWPu-6z1gIVlcqyCh2ytg9wEAYYASABEgKkhfD_BwE
No więc obczaiłem jak tu działa sterowanie kierunkiem transmisji:
Zwarte DE/RE sterowane TX, transmisja zera włącza nadajnik,
transmisja
jedynki, bitu stopu wyłącza nadajnik...
Czyli zamiast push-pull i polaryzacji pary raz +5V a za drugim
razem -5V
masz tylko 5V i zero volt, pozwalasz odbiornikowi zewrzeć linię w
trakcie
transmisji jedynki opornikiem 120ohm.
Oszukaństwo czy raczej praktyczne rozwiązanie szeroko stosowane??
Wiesz, to ma znaczenie wtedy, kiedy nie masz do dyspozycji sygnału
sterującego nadajnikiem, czyli właśnie w konwerterach i
repeaterach. Jak
masz swojego procka to nie ma to najmniejszego sensu. W "normalnym"
gotowym urządzeniu tylko raz się spotkałem z tym, że trzeba było
wstępnie spolaryzować magistralę - na szczęście wystarczył rezystor z
którejś linii do masy. I to był jakiś kontroler do PC-ta. Z innymi
kontrolerami było OK.
Nie musisz mieć swojego procka - wszystkie porty RS232 mają linię
RTS która
była historycznie używana zawsze do sterowania kierunkiem nadawania
RS485.
Jak masz urządzenie które nie ma fizycznie żadnej linii poza TxD i RxD
to sobie możesz korzystać z RTSa ile wlezie. A jak weźmiesz takiego
AT91SAM9260 który nawet na niektórych UARTach ma RTS tylko starsze
wersje linuxów nie obsługują tego poprawnie to też sobie możesz.
I co wtedy robisz?
Dajesz timer wyzwalany bitem startu do sterowania linią DE/RE? I czas
ustawiasz zgodnie z baudrate?
Czy może robisz tak jak konwerter z linku u góry, że steruje nadajnikiem
tylko w czasie bitu startu i zerowych bitów danych a resztę zostawia
odbiornikom aby sobie radziły z niesterowaną linią?
Temat został odłożony, a teraz jest nieaktualny.
Gdybym miał to jednak zrobić, to słowo daję - nie wiem. Być może nawet
postawiłbym tam po drodze jakiegoś "maluszka" (TINY albo raczej
malutkiego ARMa) żeby się nie zastanawiać, a przy okazji mógłby coś
pożytecznego zrobić co w Linuksie może być trudne... Różne pomysły
można mieć. Ale na pewno przetestowałbym wreszcie właśnie ten układ o
którym piszesz i może właśnie tego użył.
Nie wiem czy się rozumiemy... ja nie chcę kupić, ja nie chcę użyć.
Ja chcę zrobić. Mam dwa urządzenia połączyć, potrzebuję porobić
między nimi interfejsy różne, i między innymi RS232-RS485.
Innymi słowy - chcę "wyprodukować" nową swoją płytkę na której
jedną z kilku funkcji będzie taki konwerter
news:oq430a$a57$1@node1.news.atman.pl...
Może z tego wydłubiesz?
https://ivel.pl/p2850,konwerter-rs232-rs485.html?gclid=EAIaIQobChMI-cWPu-6z1gIVlcqyCh2ytg9wEAYYASABEgKkhfD_BwE
No więc obczaiłem jak tu działa sterowanie kierunkiem transmisji:
Zwarte DE/RE sterowane TX, transmisja zera włącza nadajnik,
transmisja
jedynki, bitu stopu wyłącza nadajnik...
Czyli zamiast push-pull i polaryzacji pary raz +5V a za drugim
razem -5V
masz tylko 5V i zero volt, pozwalasz odbiornikowi zewrzeć linię w
trakcie
transmisji jedynki opornikiem 120ohm.
Oszukaństwo czy raczej praktyczne rozwiązanie szeroko stosowane??
Wiesz, to ma znaczenie wtedy, kiedy nie masz do dyspozycji sygnału
sterującego nadajnikiem, czyli właśnie w konwerterach i
repeaterach. Jak
masz swojego procka to nie ma to najmniejszego sensu. W "normalnym"
gotowym urządzeniu tylko raz się spotkałem z tym, że trzeba było
wstępnie spolaryzować magistralę - na szczęście wystarczył rezystor z
którejś linii do masy. I to był jakiś kontroler do PC-ta. Z innymi
kontrolerami było OK.
Nie musisz mieć swojego procka - wszystkie porty RS232 mają linię
RTS która
była historycznie używana zawsze do sterowania kierunkiem nadawania
RS485.
Jak masz urządzenie które nie ma fizycznie żadnej linii poza TxD i RxD
to sobie możesz korzystać z RTSa ile wlezie. A jak weźmiesz takiego
AT91SAM9260 który nawet na niektórych UARTach ma RTS tylko starsze
wersje linuxów nie obsługują tego poprawnie to też sobie możesz.
I co wtedy robisz?
Dajesz timer wyzwalany bitem startu do sterowania linią DE/RE? I czas
ustawiasz zgodnie z baudrate?
Czy może robisz tak jak konwerter z linku u góry, że steruje nadajnikiem
tylko w czasie bitu startu i zerowych bitów danych a resztę zostawia
odbiornikom aby sobie radziły z niesterowaną linią?
Temat został odłożony, a teraz jest nieaktualny.
Gdybym miał to jednak zrobić, to słowo daję - nie wiem. Być może nawet
postawiłbym tam po drodze jakiegoś "maluszka" (TINY albo raczej
malutkiego ARMa) żeby się nie zastanawiać, a przy okazji mógłby coś
pożytecznego zrobić co w Linuksie może być trudne... Różne pomysły
można mieć. Ale na pewno przetestowałbym wreszcie właśnie ten układ o
którym piszesz i może właśnie tego użył.
Nie wiem czy się rozumiemy... ja nie chcę kupić, ja nie chcę użyć.
Ja chcę zrobić. Mam dwa urządzenia połączyć, potrzebuję porobić
między nimi interfejsy różne, i między innymi RS232-RS485.
Innymi słowy - chcę "wyprodukować" nową swoją płytkę na której
jedną z kilku funkcji będzie taki konwerter
Ależ oczywiście że rozumiem częściowo Twój problem. Częściowo, bo nie
znam wszystkich uwarunkowań ani preferencji. A tu ma znaczenie np
protokół komunikacji. Przy konwerterach sterowanych z użyciem timera
protokół musi uwzględniać konieczność robienia przerw między nadawaniem
i odbieraniem. Jeżeli masz na to wpływ, no to można kombinować.
Osobiście najbardziej mi się podoba rozwiązanie ze sterowaniem linią DE,
a nie DI. Ma m.in. jedną wadę - jeżeli chcesz żeby nie trzeba było
opierać się na odbiornikach fail safe, to polaryzacja linii musi być
cały czas zasilana. Całość się skomplikuje przy kontrolerze w środku
magistrali. No i różne takie rzeczy trzeba rozważyć przy podejmowaniu
decyzji. Co innego jak robisz punkt-punkt, co innego jak musisz przyjąć
że musisz współpracować z dziwnymi urządzeniami itd.
Co do ustawiania timeoutów to są jakieś algorytmy autodetekcji
ustawienia portów, ale nie korzystałem nigdy, więc nie wiem co są warte.
Ale możesz np dać procka który nie będzie zbierał całego bajtu i pchał
go dalej po skompletowaniu, tylko włączy nadajnik jak się pojawi
pierwsza zmiana stanu i wyłączy po odebraniu całego bajtu. Tzn że sam
UART procka będzie tylko żeby zweryfikować i ewentualnie w jakiś sposób
zareagować jak dane będą niekompletne. To by nie wprowadzało praktycznie
opóźnienia w transmisji, a i pozwalałoby na zrobienie jednego softu
również dla repeatera RS485... Tak sobie gdybam.
Ponieważ w którymś momencie zrezygnowaliśmy z korzystania z pecetowych
portów 232 (potrafią się skubańce powiesić i trzeba peceta restartować)
i zaczęliśmy korzystać z innych rozwiazań, to nawet nie wiem jak teraz
rynek wygląda. A zajrzałbym do paru konwerterów.
Pozdrawiam
DD
Piotr GaĹka
Guest
Guest
Sat Sep 23, 2017 9:19 am
W dniu 2017-09-23 o 00:10, Pszemol pisze:
Quote:
Ja piszę o automatycznym machaniu RTSem przez uarta odpowiednio
ustawionego.
Jest to funkcja uarta dedykowana właśnie do zastosowania w
RS485.
W mikrokontrolerach, które obecnie używamy (ATXmega256A3U) mam 7 UARTów,
ustawionego.
Jest to funkcja uarta dedykowana właśnie do zastosowania w
RS485.
W mikrokontrolerach, które obecnie używamy (ATXmega256A3U) mam 7 UARTów,
ale każdy ma tylko TXD i RXD i jeszcze jakiś XCK.
O tym XCK to wiem tylko, że te UARTy mają jakiś tryb transmisji
synchronicznej - nigdy w to nie wnikaliśmy.
Może taki clock dało by się wykorzystać do włączania nadajnika na
początku każdego bitu.
P.G.
J.F.
Guest
Guest
Sat Sep 23, 2017 1:24 pm
Dnia Sat, 23 Sep 2017 11:19:56 +0200, Piotr Gałka napisał(a):
Quote:
W dniu 2017-09-23 o 00:10, Pszemol pisze:
Ja piszę o automatycznym machaniu RTSem przez uarta odpowiednio
ustawionego.
Jest to funkcja uarta dedykowana właśnie do zastosowania w
RS485.
W mikrokontrolerach, które obecnie używamy (ATXmega256A3U) mam 7 UARTów,
ale każdy ma tylko TXD i RXD i jeszcze jakiś XCK.
Ja piszę o automatycznym machaniu RTSem przez uarta odpowiednio
ustawionego.
Jest to funkcja uarta dedykowana właśnie do zastosowania w
RS485.
W mikrokontrolerach, które obecnie używamy (ATXmega256A3U) mam 7 UARTów,
ale każdy ma tylko TXD i RXD i jeszcze jakiś XCK.
Tylko do tego chyba masz troche normalnych pinow I/O, z ktorych kazdy
moze robic za RTS.
Pozostaje tylko sprawdzic jak to z tymi przerwaniami :-)
J.
Piotr GaĹka
Guest
Guest
Sat Sep 23, 2017 3:18 pm
W dniu 2017-09-23 o 15:24, J.F. pisze:
Quote:
W mikrokontrolerach, które obecnie używamy (ATXmega256A3U) mam 7 UARTów,
ale każdy ma tylko TXD i RXD i jeszcze jakiś XCK.
Tylko do tego chyba masz troche normalnych pinow I/O, z ktorych kazdy
moze robic za RTS.
Pozostaje tylko sprawdzic jak to z tymi przerwaniami :-)
ale każdy ma tylko TXD i RXD i jeszcze jakiś XCK.
Tylko do tego chyba masz troche normalnych pinow I/O, z ktorych kazdy
moze robic za RTS.
Pozostaje tylko sprawdzic jak to z tymi przerwaniami :-)
Nie ja piszę oprogramowanie więc tego nie wiem, ale myślę, że jest
jakieś przerwanie jak "wszystko wyszło".
Ja podłączam hardware i stąd wiem, że prawie z każdej strony procka
znajdę jakieś piny z UARTem.
Było hasło, że hardwareowy RTS i dlatego wtrąciłem swoje 3gr, wszystkie
UARTy jakie widziałem od 10... lat nie mają.
P.G.
J.F.
Guest
Guest
Mon Sep 25, 2017 9:55 am
Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:oq5u0c$rvk$1$PiotrGalka@news.chmurka.net...
W dniu 2017-09-23 o 15:24, J.F. pisze:
Quote:
W mikrokontrolerach, które obecnie używamy (ATXmega256A3U) mam 7
UARTów,
ale każdy ma tylko TXD i RXD i jeszcze jakiś XCK.
Tylko do tego chyba masz troche normalnych pinow I/O, z ktorych
kazdy
moze robic za RTS.
Pozostaje tylko sprawdzic jak to z tymi przerwaniami :-)
Nie ja piszę oprogramowanie więc tego nie wiem, ale myślę, że jest
jakieś przerwanie jak "wszystko wyszło".
Ja podłączam hardware i stąd wiem, że prawie z każdej strony procka
znajdę jakieś piny z UARTem.
Było hasło, że hardwareowy RTS i dlatego wtrąciłem swoje 3gr,
wszystkie UARTy jakie widziałem od 10... lat nie mają.
UARTów,
ale każdy ma tylko TXD i RXD i jeszcze jakiś XCK.
Tylko do tego chyba masz troche normalnych pinow I/O, z ktorych
kazdy
moze robic za RTS.
Pozostaje tylko sprawdzic jak to z tymi przerwaniami :-)
Nie ja piszę oprogramowanie więc tego nie wiem, ale myślę, że jest
jakieś przerwanie jak "wszystko wyszło".
Ja podłączam hardware i stąd wiem, że prawie z każdej strony procka
znajdę jakieś piny z UARTem.
Było hasło, że hardwareowy RTS i dlatego wtrąciłem swoje 3gr,
wszystkie UARTy jakie widziałem od 10... lat nie mają.
Piotrze - ale specjalizowane uklady, czy zawarte w jakis uC ?
W uC jak pisalem - moze potrzebne, moze niepotrzebne, jest multum
portow, ktore moga te funkcje pelnic w razie potrzeby.
I tylko jakis "automatyczny RTS" by sie mogl przydac, a go nie bedzie
.... chociaz ... takie uC czesto do 485 uzywane, to az dziwne, ze nie
ma.
A moze jednak lepiej, jak program to obsluguje :-)
J.
Dariusz Dorochowicz
Guest
Guest
Mon Sep 25, 2017 12:48 pm
W dniu 2017-09-25 o 11:55, J.F. pisze:
Quote:
Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:oq5u0c$rvk$1$PiotrGalka@news.chmurka.net...
W dniu 2017-09-23 o 15:24, J.F. pisze:
W mikrokontrolerach, które obecnie używamy (ATXmega256A3U) mam 7
UARTów,
ale każdy ma tylko TXD i RXD i jeszcze jakiś XCK.
Tylko do tego chyba masz troche normalnych pinow I/O, z ktorych kazdy
moze robic za RTS.
Pozostaje tylko sprawdzic jak to z tymi przerwaniami :-)
Nie ja piszę oprogramowanie więc tego nie wiem, ale myślę, że jest
jakieś przerwanie jak "wszystko wyszło".
Ja podłączam hardware i stąd wiem, że prawie z każdej strony procka
znajdę jakieś piny z UARTem.
Było hasło, że hardwareowy RTS i dlatego wtrąciłem swoje 3gr,
wszystkie UARTy jakie widziałem od 10... lat nie mają.
Piotrze - ale specjalizowane uklady, czy zawarte w jakis uC ?
W uC jak pisalem - moze potrzebne, moze niepotrzebne, jest multum
portow, ktore moga te funkcje pelnic w razie potrzeby.
I tylko jakis "automatyczny RTS" by sie mogl przydac, a go nie bedzie
... chociaz ... takie uC czesto do 485 uzywane, to az dziwne, ze nie ma.
A moze jednak lepiej, jak program to obsluguje
dyskusyjnych:oq5u0c$rvk$1$PiotrGalka@news.chmurka.net...
W dniu 2017-09-23 o 15:24, J.F. pisze:
W mikrokontrolerach, które obecnie używamy (ATXmega256A3U) mam 7
UARTów,
ale każdy ma tylko TXD i RXD i jeszcze jakiś XCK.
Tylko do tego chyba masz troche normalnych pinow I/O, z ktorych kazdy
moze robic za RTS.
Pozostaje tylko sprawdzic jak to z tymi przerwaniami :-)
Nie ja piszę oprogramowanie więc tego nie wiem, ale myślę, że jest
jakieś przerwanie jak "wszystko wyszło".
Ja podłączam hardware i stąd wiem, że prawie z każdej strony procka
znajdę jakieś piny z UARTem.
Było hasło, że hardwareowy RTS i dlatego wtrąciłem swoje 3gr,
wszystkie UARTy jakie widziałem od 10... lat nie mają.
Piotrze - ale specjalizowane uklady, czy zawarte w jakis uC ?
W uC jak pisalem - moze potrzebne, moze niepotrzebne, jest multum
portow, ktore moga te funkcje pelnic w razie potrzeby.
I tylko jakis "automatyczny RTS" by sie mogl przydac, a go nie bedzie
... chociaz ... takie uC czesto do 485 uzywane, to az dziwne, ze nie ma.
A moze jednak lepiej, jak program to obsluguje
Są takie co mają, są takie co nie mają. A i są takie co mają różne
rodzaje nawet w jednym układzie. Od TxD/RxD do pełnego (?) USARTa.
A ten XCK w XMega, jak sie można domyślić, to do transmisji
synchronicznej. Handshaking trzeba samemu "ręcznie" obsłużyć.
Pozdrawiam
DD
Piotr GaĹka
Guest
Guest
Mon Sep 25, 2017 2:44 pm
W dniu 2017-09-25 o 11:55, J.F. pisze:
Quote:
Było hasło, że hardwareowy RTS i dlatego wtrąciłem swoje 3gr,
wszystkie UARTy jakie widziałem od 10... lat nie mają.
Piotrze - ale specjalizowane uklady, czy zawarte w jakis uC ?
wszystkie UARTy jakie widziałem od 10... lat nie mają.
Piotrze - ale specjalizowane uklady, czy zawarte w jakis uC ?
Przez 10 lat widziałem tylko UARTy w Xmegach
Użyłem słowa "wszystkie" aby zwrócić uwagę, że istnieją osoby, które
niby ciągle coś z UARTami mają do czynienia (my akurat używamy ich do
RS485), ale pod hasłem UART rozumieją coś co ma tylko TXD i RXD.
Quote:
W uC jak pisalem - moze potrzebne, moze niepotrzebne, jest multum
portow, ktore moga te funkcje pelnic w razie potrzeby.
I tylko jakis "automatyczny RTS" by sie mogl przydac, a go nie bedzie
... chociaz ... takie uC czesto do 485 uzywane, to az dziwne, ze nie ma.
portow, ktore moga te funkcje pelnic w razie potrzeby.
I tylko jakis "automatyczny RTS" by sie mogl przydac, a go nie bedzie
... chociaz ... takie uC czesto do 485 uzywane, to az dziwne, ze nie ma.
Nie wiem dokładnie jak taki RTS działa to trudno mi się wypowiedzieć czy
byłby przydatny w RS485.
Mi się wydaje, że RTS/CTS to były informacje, że jestem gotów na
odbieranie danych, ale może się mylę.
Czy taki sygnał z UARTa przydałby się do sterowania DE RS485 - mam
wątpliwości.
P.G.
J.F.
Guest
Guest
Mon Sep 25, 2017 3:13 pm
Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:oqb4nt$t2m$1$PiotrGalka@news.chmurka.net...
W dniu 2017-09-25 o 11:55, J.F. pisze:
Quote:
W uC jak pisalem - moze potrzebne, moze niepotrzebne, jest multum
portow, ktore moga te funkcje pelnic w razie potrzeby.
I tylko jakis "automatyczny RTS" by sie mogl przydac, a go nie
bedzie ... chociaz ... takie uC czesto do 485 uzywane, to az
dziwne, ze nie ma.
Nie wiem dokładnie jak taki RTS działa to trudno mi się wypowiedzieć
czy byłby przydatny w RS485.
Mi się wydaje, że RTS/CTS to były informacje, że jestem gotów na
odbieranie danych, ale może się mylę.
portow, ktore moga te funkcje pelnic w razie potrzeby.
I tylko jakis "automatyczny RTS" by sie mogl przydac, a go nie
bedzie ... chociaz ... takie uC czesto do 485 uzywane, to az
dziwne, ze nie ma.
Nie wiem dokładnie jak taki RTS działa to trudno mi się wypowiedzieć
czy byłby przydatny w RS485.
Mi się wydaje, że RTS/CTS to były informacje, że jestem gotów na
odbieranie danych, ale może się mylę.
Urzadzenie chcąc nadawac aktywuje sygnal RTS, modem przestawia sie na
nadawanie i potwierdza sygnalem CTS.
Przy czym ... urzadzenie w zasadzie powinno poczekac, az sie ten
aktywny stan na CTS pojawi, zanim zacznie wysylac.
Quote:
Czy taki sygnał z UARTa przydałby się do sterowania DE RS485 - mam
wątpliwości.
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 :-)
J.
Piotr GaĹka
Guest
Guest
Mon Sep 25, 2017 5:14 pm
W dniu 2017-09-25 o 17:13, J.F. pisze:
Quote:
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.
P.G.
J.F.
Guest
Guest
Mon Sep 25, 2017 5:26 pm
Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:oqbdhp$ij$1$PiotrGalka@news.chmurka.net...
W dniu 2017-09-25 o 17:13, J.F. pisze:
Quote:
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.
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.
Pszemol
Guest
Guest
Tue Sep 26, 2017 4:38 am
J.F. <jfox_xnospamx@poczta.onet.pl> wrote:
Quote:
Użytkownik "Piotr Gałka" napisał w wiadomości grup
dyskusyjnych:oqbdhp$ij$1$PiotrGalka@news.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
dyskusyjnych:oqbdhp$ij$1$PiotrGalka@news.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?
Dariusz Dorochowicz
Guest
Guest
Tue Sep 26, 2017 6:39 am
W dniu 2017-09-26 o 04:38, Pszemol pisze:
Quote:
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?
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
J.F.
Guest
Guest
Tue Sep 26, 2017 8:09 am
Użytkownik "Pszemol" napisał w wiadomości grup
dyskusyjnych:oqcejp$37t$1@dont-email.me...
Quote:
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 ?
Quote:
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ć
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.
Quote:
Ktoś się przypadkiem orientuje czy standardowe drivery do rs232 pod
linuksem nie umożliwiają takiej funkcji machania RTSem w takt
nadawania?
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.
Piotr GaĹka
Guest
Guest
Tue Sep 26, 2017 8:16 am
W dniu 2017-09-26 o 04:38, Pszemol pisze:
Quote:
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?
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.
elektroda NewsGroups Forum Index - Elektronika Polska - Jak stworzyć izolowany konwerter bez TTL z RS232 na RS485 - dostępne scalaki?