🚀 go-pugleaf

Czy istnieje jakiś limit na ilość cyfr w urządzeniu reprezentującym
port szeregowy w Linuxie?

Myślę o rozwiązaniu następującym - użycie mechanizmu udev
i zmodyfikowanie sposobu w jakim przydzielane są nazwy portów.
Zamiast kolejnego wolnego numeru portu ttyXUSB0, ttyXUSB1
chcę aby tworzyły się urządzenia według wzoru ttyXUSBthap
gdzie t - typ portu (1-RS485, 2-pętla prądowa, 0-RS232, itp), h - to
numer huba lub numer gniazda USB na sterowniku/komputerze
liczone od 0 do ilości portów USB na użytym sterowniku (h-1),
a - to adres urządzenia na płytce huba, czyli numer portu w hubie (0-3)
i ostatnia cyfra p - to już port w obrębie DUARTa (0-1) czy QUARTa (0-3).

Czyli chcę aby po wetknięciu huba do drugiego gniazda sterownika
mającego płytkę 2x rs232 w czwartym gnieździe tego huba
pojawiły się w systemie dwa nowe porty o nazwach/numerach
ttyXUSB0130 i ttyXUSB0131. Rozwijając te nazwy mamy:
typ 0: RS232
numer portu 1: drugi port
numer gniazda huba 3: czwarte gniazdo huba

I teraz zastanawiam się czy może lepiej byłoby numerować od 1
a nie od 0, aby wyeliminować port o nazwie ttyXUSB0000 :)

Co o tym myślicie?

"Pszemol" <Pszemol@PolBox.com> wrote in message 
news:nh5ot5$1bt$1@dont-email.me...
> "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?