🚀 go-pugleaf

"Sebastian Biały" <heby@poczta.onet.pl> wrote in message 
news:nh5b05$8or$1@node2.news.atman.pl...
> On 2016-05-13 01:29, Pszemol wrote:
>> W swoim urządzeniu "przemysłowym" będę miał fefnaście takich
>> samych portów (albo fefnaście i jeszcze trochę) z tym że będą one po
>> 2 lub po 4 na jedno urządzenie USB Exara, wszystko podłączone
>> przez USB huba lub dwa.
>
> Idę o zaklad że o ile jako tako ustabilizujesz kolejnośc po wlaczeniu
> to jesli ktoś złosliwie przestawi dziurkę USB moga być kłopoty.

Nie powinno być chyba aż tak źle ?
USB DUART od Exara powinien zawsze raportować oba swe kanały
w odpowiedniej kolejności. Tych USB-DUARTów będzie 4 na jednym
HUBie i każda karta z takim DUARTem będzie mieć dwa GPIO
dedykowane na rozpoznanie w którym gnieździe HUBa siedzi...
Wiec mamy już 8 UARTów o jako-takiej orientacji gdzie są na HUBie.
Teraz muszę rozpracować problem tego na którym HUBie jest
który port, no i jego typ interfejsu jakoś przekazać do systemu (GUI).

> Podejrzane tez i to sporo jest ilośc tych portów. Dlaczego jest ich aż 
> tyle? RS485 zapewnia wiele urządzeń na wspólnej magistrali.

Oczywiście że zapewnia, i będzie ich tam na jednej skrętce RS485
około 16. Takich skrętek będzie po dwie na UART (4 na 1 karcie).
W szczególności możesz mieć więc 4 duarty na HUBie, na każdym
2 porty RS485 więc masz 8 skrętek RS485 napędzanych z jednego
HUBa.
Kazdy HUB może mieć mieszaninę kart różnych typów, np. kartę
z dwoma RS232 albo kartę z 4 portami RS485, lub 1 RS232 i 2 RS485.
Do wyboru do koloru, w zależności od potrzeb konkretnej instalacji
u klienta i konstelacji jego konkretnych urządzeń.

>> Niektóre z tych portów będą na płytkach w standardzie RS232,
>> inne RS485, jeszcze inne będą szeregową pętlą prądową...
>> Ponieważ kostka USB-UART od Exara oferuje oprócz typowych linii
>> RXD, TXD, RTS, CTS itp jeszcze kilka linii we/wy (GPIO) to mogę
>> na takiej swojej płytce zakodować czy te dwa porty to są RS232
>> a te są RS485 a te są z interfejsem pętli prądowej.
>> Jak teraz umieścić w systemie linuxa informację na temat rodzaju
>> interfejsów jakie są dołączone na końcu uarta na potrzeby aplikacji?
>
> Nie wiem czy linux w ogóle dostanie te informacje - RS485 i RS232
> niczym się nie róznią od strony software drivera.

Linux sam z siebie oczywiście informacji takiej nie dostanie...
Bo skąd miałby wiedzieć co ja mam na płytce? :-)
Ja pytam jak tą informację zgrabnie przesłać mam po
odczytaniu pinów GPIO na USB-DUARTcie aby nie złamać
przypadkiem jakichś linuksowych taboo :-)

> Płyty główne przemysłowe z którymi miałem do czynienia
> konfigurowano zworkami (rzadko kiedy w biosie).
> OS nie widział różnicy.

Mi chodzi o to, aby użytkownik mógł uszkodzoną kartę z dwoma
portami RS232 (na przykład) wyjąć z gniazda, włożyć tam nową
w to samo miejsce i aby aplikacji/konfiguracji nie musiał ruszać.
Taki jest cel do osiągnięcia.

Oprócz tego chodzi o to, aby ułatwić samą konfigurację, i aby
nie oferować całej plejady portów które z natury rzeczy samej
nie nadają się do podłączenia do tego typu urządzeń (stąd te
filtry o których pisałem wczoraj: wybierz np. tylko RS485).

>> Innymi słowy, zamiast pytać użytkownika konfigurującego drukarkę,
>> na którym porcie ma drukarkę, i oferować mu fefnaście portów
>> do wyboru chcę odfiltrować te z pętlą prądową czy RS485 i pokazać
>> mu tylko te RS232.
>
> Zgaduje że sie nie da. Szczegóły w instruckji do scalaka.

Instrukcja scalaka podaje że scalak oferuje 10 pinow GPIO dla każdego
kanału UARTa (10 linii licząc oprócz dedykowanych linii RXD i TXD).
Te linie możesz sobie przeznaczyć na jakieś RTS/CTS/CDC czy inne
funkcje - w szczególności zostaje 2-3 linie na ustalenie typu karty
według ustalonego kodu: np. 000 to 2xRS232, 001 to 4xRS485, 010 to
2 pętle prądowe, 011 to 1xRs232 + 2xRS485 itp, itd... Typów będzie 8 :-)
Tą informację chcę przekazać systemowi i jakość ułatwić życie aplikacji.

>> W innej części tej samej aplikacji chciałbym
>> na odmianę skonfigurować inne urządzenie, które tylko gada po
>> pętli prądowej i chciałbym automatycznie wyszukać z tych kilkunastu
>> ttyXUSB?? ten który ma na swym końcu pętlę prądową...
>
> Zasugeruje inne rozwiązanie które sam stosowałem: aplikacja zaczynała 
> pracę od komunikacji na każdym porcie wyszukując urzadzenia. Tak, to marna 
> rada jeśli urządzenia głupie.

Strasznie długo by to trwało...
No i problem z taką konfiguracją będziesz miał gdy w czasie startu
jakieś urządzenie nie odpowie, będzie chwilowo wyłączone, i zostanie
niewykryte... Będziesz okresowo powtarzał wykrywanie? Masakra.

>> Czy muszę sobie radzić z jakimiś tablicami tekstowymi umieszczonymi
>> gdzieś w systemie plików czy może jest jakiś sprytny sposób w linuxie
>> aby "podwiesić" fachowo taką informację bezpośrednio pod ttyXUSB5
>> a inną informację podwiesić pod /dev/ttyXUSB9?
>
> Masz kilka problemów:
> a) absurdalna ilość portów wskazuje na jakiś bug w designie całości

:-) fefnaście nie jest żadną konkretną liczbą.
A urządzenie jest duże i będzie rozmawiać z ogromną liczbą peryferiów
zgrupowanych w różnych klasach/typach w liczne grupy.
Niech Cię to nie przeraża - poprzednie generacje takich systemów
działały ze sztywno instalowaną matrycą portów RS232 i nie wymagały
takiej plastycznej konfiguracji: nowa generacja jest modułowa i pojawił
się do rozwiązania nowy problem konfiguracji. Chcemy aby była ona P&P.

> b) najpierw musisz ustabilizować za pomocą udev kolejnośc stawiania i 
> zakleić na stale druty w dziurach USB żeby nie bylo syndromu sprzątaczki

Płytki robię ze specjalnymi gniazdami, nie będzie wtyczek i kabli USB.
Będzie moduł w postaci scalaka HUBa na płytce "głównej" i 4 gniazda
krawędziowe podające sygnały USB, zasilanie i numer portu na gnieździe.

> c) potem możesz sobie aliasować za pomocą udeva jak chcesz.
>
> Natomiast:
> a) uzywanie przelotek na USB w celu sterowania czymkolwiek to katastrofa. 
> USB jest mocno niestabilne.
Mówisz że masz bardzo złe doświadczenia... ?
Czy używałeś już "przelotek" przemysłowych od firmy Exar?
Czy doświadczenie masz tylko z lipnymi PL2303 lub FTDI232?

> b) przelotki USB mają wiele wad, wliczając w to niekomatybilne
> napięcia, opóźnienia, gubienie danych itp.

Opóźnienia, gubienie danych - to wszystko jest przecież do opanowania
protokołem komunikacyjnym. Każda transmisja szeregowa, nawet
wbudowanym RS232 powinna mieć mechanizmy zabezpieczające
ją przed gubieniem znaków czy zakłóceniami - chyba nikt poważny
nie zakłada że dostanie każdy znak który wysłał po drugiej stronie
kabla... zwłaszcza w środowisku przemysłowym.

Co do niekompatybilnych napięć to myślisz chyba o jakichś fuszerkach.
Ja te USB-DUARTy plus osobne drivery linii (izolowane i zasilane
normalnie z zasilacza a nie przez diodę z RTSa) planuję zrobić na
swoich własnych płytkach drukowanych więc to ja będę kontrolował
poziomy napięć: DUART przecież steruje TTL 3v3 a ja jadę sygnałem dalej.

> c) to się na pewno da zrobić lepiej niż na przelotkach USB.

Nie znam dobrego sposobu na grupowanie klastrów po 4-8 portów
RS232, bo chyba I2C nie jest alternatywą ze względu na gorszą
przepustowość... Zresztą czy I2C miałoby być o tyle lepsze od USB?