Izolowany konwerter zrobić z RS232

W dniu 2017-09-23 o 04:01, Pszemol pisze:

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

W dniu 2017-09-23 o 00:10, Pszemol 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. 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.

Dnia Sat, 23 Sep 2017 11:19:56 +0200, Piotr Gałka napisał(a):

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.

W dniu 2017-09-23 o 15:24, J.F. pisze:

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.

Użytkownik "Piotr Gałka" napisał w wiadomości grup dyskusyjnych:oq5u0c$rvk$1$ snipped-for-privacy@news.chmurka.net... W dniu 2017-09-23 o 15:24, J.F. pisze:

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.

W dniu 2017-09-25 o 11:55, J.F. pisze:

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

W dniu 2017-09-25 o 11:55, J.F. pisze:

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.

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.

Użytkownik "Piotr Gałka" napisał w wiadomości grup dyskusyjnych:oqb4nt$t2m$1$ snipped-for-privacy@news.chmurka.net... W dniu 2017-09-25 o 11:55, J.F. pisze:

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.

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.

W dniu 2017-09-25 o 17:13, J.F. pisze:

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.

Użytkownik "Piotr Gałka" napisał w wiadomości grup dyskusyjnych:oqbdhp$ij$1$ snipped-for-privacy@news.chmurka.net... W dniu 2017-09-25 o 17:13, J.F. pisze:

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.

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,

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?

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

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ą:

Pozdrawiam

DD

Użytkownik "Pszemol" napisał w wiadomości grup dyskusyjnych:oqcejp$37t$ snipped-for-privacy@dont-email.me...

przerobic "swojego" na czterodruta ?

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

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.

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.

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

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.

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

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

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

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.

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ć.

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

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

Tak, znalazłem to samo już parę dni temu, zanim rozebrałem tego małego, bez jumperków do ustawiania baudrate.

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.

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

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.