W dniu 2017-09-23 o 04:01, Pszemol pisze:
> "Dariusz Dorochowicz" <_...@w...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?gcl
id=EAIaIQobChMI-cWPu-6z1gIVlcqyCh2ytg9wEAYYASABEgKkh
fD_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