W dniu 11.11.2015 o 17:13, Pszemol pisze:
> "Zbych" <z...@o...pl> wrote in message
> news:56431ccf$0$22823$65785112@news.neostrada.pl...
>>> Ach, tu mi uzmysłowiłeś że chciałem zapytać też o coś innego...
>>> A mianowicie identyfikację portów wielokrotnie powtórzonych.
>>> Innymi słowy mam płytkę wtykaną w USB, na płytce dwa UARTy.
>>> W porzo. Teraz chcę takich płytek mieć 5, każda po dwa UARTy.
>>> Jak zidentyfikuję która płytka jest na którym /dev/sda0...8 czy
>>> jak się one tam zwą? A po pierwotnej instalacji, coś się schrzani,
>>> pierun trzaśnie, serwisant płytkę wymieni, i jak wpasować nową
>>> aby widoczna była tak samo jak stara?
>>
>> Nakleić na każdym konwerterze jego numer seryjny i dać możliwość
>> przyporządkowania numeru do funkcji w twoim programie.
>
> Chciałbym aby serwisant który ma wymienić uszkodzoną płytkę
> nie musiał wchodzić do konfiguracji systemu i czegokolwiek
> zmieniać. Wolałbym aby ustawił nową płytkę tak, aby system
> sam sobie rozpoznał która jest która i że ta nowa nie jest
> dodatkowa tylko jest zamiennikiem tej którą wyjęto...
>

Jeśli płytki są identyczne to jak system ma je rozróżnić?

Masz do wyboru:
1. numer seryjny
2. jakieś dip-switche na płytce, które nadają jej numer/identyfikator
3. numer gniazda USB w hoście, do którego wpięto płytkę

do góry

"Zbych" <a...@o...pl> wrote in message
news:56436d35$0$686$65785112@news.neostrada.pl...
> W dniu 11.11.2015 o 17:13, Pszemol pisze:
>> "Zbych" <z...@o...pl> wrote in message
>> news:56431ccf$0$22823$65785112@news.neostrada.pl...
>>>> Ach, tu mi uzmysłowiłeś że chciałem zapytać też o coś innego...
>>>> A mianowicie identyfikację portów wielokrotnie powtórzonych.
>>>> Innymi słowy mam płytkę wtykaną w USB, na płytce dwa UARTy.
>>>> W porzo. Teraz chcę takich płytek mieć 5, każda po dwa UARTy.
>>>> Jak zidentyfikuję która płytka jest na którym /dev/sda0...8 czy
>>>> jak się one tam zwą? A po pierwotnej instalacji, coś się schrzani,
>>>> pierun trzaśnie, serwisant płytkę wymieni, i jak wpasować nową
>>>> aby widoczna była tak samo jak stara?
>>>
>>> Nakleić na każdym konwerterze jego numer seryjny i dać możliwość
>>> przyporządkowania numeru do funkcji w twoim programie.
>>
>> Chciałbym aby serwisant który ma wymienić uszkodzoną płytkę
>> nie musiał wchodzić do konfiguracji systemu i czegokolwiek
>> zmieniać. Wolałbym aby ustawił nową płytkę tak, aby system
>> sam sobie rozpoznał która jest która i że ta nowa nie jest
>> dodatkowa tylko jest zamiennikiem tej którą wyjęto...
>>
>
> Jeśli płytki są identyczne to jak system ma je rozróżnić?

No właśnie próbuję się nad tym zastanowić.

> Masz do wyboru:
> 1. numer seryjny
> 2. jakieś dip-switche na płytce, które nadają jej numer/identyfikator
> 3. numer gniazda USB w hoście, do którego wpięto płytkę

Czy numer gniazda w USB hosta lub huba jest programowo rozpoznawalny?

Dipswitche wchodzą w grę, jak najbardziej, tylko jakoś trzeba je
przemycić przez kanał USB aby aplikacja po stronie hosta mogła
jakoś powiązać ze sobą konkretny port szeregowy jaki widzi
w systemie z numerkiem odczytanym i jakoś przekazanym (jak?)
hostowi.

do góry

On 11.11.2015 17:50, Pszemol wrote:
> "Zbych" <a...@o...pl> wrote in message
> news:56436d35$0$686$65785112@news.neostrada.pl...
>> W dniu 11.11.2015 o 17:13, Pszemol pisze:
>>> "Zbych" <z...@o...pl> wrote in message
>>> news:56431ccf$0$22823$65785112@news.neostrada.pl...
>>>>> Ach, tu mi uzmysłowiłeś że chciałem zapytać też o coś innego...
>>>>> A mianowicie identyfikację portów wielokrotnie powtórzonych.
>>>>> Innymi słowy mam płytkę wtykaną w USB, na płytce dwa UARTy.
>>>>> W porzo. Teraz chcę takich płytek mieć 5, każda po dwa UARTy.
>>>>> Jak zidentyfikuję która płytka jest na którym /dev/sda0...8 czy
>>>>> jak się one tam zwą? A po pierwotnej instalacji, coś się schrzani,
>>>>> pierun trzaśnie, serwisant płytkę wymieni, i jak wpasować nową
>>>>> aby widoczna była tak samo jak stara?
>>>>
>>>> Nakleić na każdym konwerterze jego numer seryjny i dać możliwość
>>>> przyporządkowania numeru do funkcji w twoim programie.
>>>
>>> Chciałbym aby serwisant który ma wymienić uszkodzoną płytkę
>>> nie musiał wchodzić do konfiguracji systemu i czegokolwiek
>>> zmieniać. Wolałbym aby ustawił nową płytkę tak, aby system
>>> sam sobie rozpoznał która jest która i że ta nowa nie jest
>>> dodatkowa tylko jest zamiennikiem tej którą wyjęto...
>>>
>>
>> Jeśli płytki są identyczne to jak system ma je rozróżnić?
>
> No właśnie próbuję się nad tym zastanowić.
>
>> Masz do wyboru:
>> 1. numer seryjny
>> 2. jakieś dip-switche na płytce, które nadają jej numer/identyfikator
>> 3. numer gniazda USB w hoście, do którego wpięto płytkę
>
> Czy numer gniazda w USB hosta lub huba jest programowo rozpoznawalny?

Tak, np. dla jednego z urządzeń CDC-ACM ścieżka wygląda tak:
/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.2/1-1.
2.4/1-1.2.4:1.1/tty/ttyACM0

odczytane za pomocą: udevadm info -a -p $(udevadm info -q path -n
/dev/ttyACM0)

Widać po kolei do której magistrali pci jest podłączony kontroler, potem
hub, jest tam też (chyba) numer gniazda w hubie, ale nie pytaj mnie o
dokładne znaczenie tych liczb, bo nie było mi to jeszcze do niczego
potrzebne.

> Dipswitche wchodzą w grę, jak najbardziej, tylko jakoś trzeba je
> przemycić przez kanał USB aby aplikacja po stronie hosta mogła
> jakoś powiązać ze sobą konkretny port szeregowy jaki widzi
> w systemie z numerkiem odczytanym i jakoś przekazanym (jak?)
> hostowi.

Jak użyjesz ftdi, to będziesz miał trochę niepotrzebnych linii I/O, do
których możesz podpiąć switche i odczytać ich stan programowo.
Jak byś robił sam urządzenie CDC-ACM, to możesz jego numer seryjny
zmieniać na podstawie stanu switchy.

do góry

"Zbych" <z...@o...pl> wrote in message
news:5643944f$0$22824$65785112@news.neostrada.pl...
> On 11.11.2015 17:50, Pszemol wrote:
>> "Zbych" <a...@o...pl> wrote in message
>> news:56436d35$0$686$65785112@news.neostrada.pl...
>>> W dniu 11.11.2015 o 17:13, Pszemol pisze:
>>>> "Zbych" <z...@o...pl> wrote in message
>>>> news:56431ccf$0$22823$65785112@news.neostrada.pl...
>>>>>> Ach, tu mi uzmysłowiłeś że chciałem zapytać też o coś innego...
>>>>>> A mianowicie identyfikację portów wielokrotnie powtórzonych.
>>>>>> Innymi słowy mam płytkę wtykaną w USB, na płytce dwa UARTy.
>>>>>> W porzo. Teraz chcę takich płytek mieć 5, każda po dwa UARTy.
>>>>>> Jak zidentyfikuję która płytka jest na którym /dev/sda0...8 czy
>>>>>> jak się one tam zwą? A po pierwotnej instalacji, coś się schrzani,
>>>>>> pierun trzaśnie, serwisant płytkę wymieni, i jak wpasować nową
>>>>>> aby widoczna była tak samo jak stara?
>>>>>
>>>>> Nakleić na każdym konwerterze jego numer seryjny i dać możliwość
>>>>> przyporządkowania numeru do funkcji w twoim programie.
>>>>
>>>> Chciałbym aby serwisant który ma wymienić uszkodzoną płytkę
>>>> nie musiał wchodzić do konfiguracji systemu i czegokolwiek
>>>> zmieniać. Wolałbym aby ustawił nową płytkę tak, aby system
>>>> sam sobie rozpoznał która jest która i że ta nowa nie jest
>>>> dodatkowa tylko jest zamiennikiem tej którą wyjęto...
>>>>
>>>
>>> Jeśli płytki są identyczne to jak system ma je rozróżnić?
>>
>> No właśnie próbuję się nad tym zastanowić.
>>
>>> Masz do wyboru:
>>> 1. numer seryjny
>>> 2. jakieś dip-switche na płytce, które nadają jej numer/identyfikator
>>> 3. numer gniazda USB w hoście, do którego wpięto płytkę
>>
>> Czy numer gniazda w USB hosta lub huba jest programowo rozpoznawalny?
>
> Tak, np. dla jednego z urządzeń CDC-ACM ścieżka wygląda tak:
> /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.2/1-1.
2.4/1-1.2.4:1.1/tty/ttyACM0
>
> odczytane za pomocą: udevadm info -a -p $(udevadm info -q path -n
> /dev/ttyACM0)
>
> Widać po kolei do której magistrali pci jest podłączony kontroler, potem
> hub, jest tam też (chyba) numer gniazda w hubie, ale nie pytaj mnie o
> dokładne znaczenie tych liczb, bo nie było mi to jeszcze do niczego
> potrzebne.

Dzięki, pobawię się tym ... Jeśli to tak działa to pięknie, nie potrzebuje
przełączników obrotowych identyfikujących która z 5 czy 10 płytek
modułowych jest podłaczona do jakich urządzeń zewnętrznych.

>> Dipswitche wchodzą w grę, jak najbardziej, tylko jakoś trzeba je
>> przemycić przez kanał USB aby aplikacja po stronie hosta mogła
>> jakoś powiązać ze sobą konkretny port szeregowy jaki widzi
>> w systemie z numerkiem odczytanym i jakoś przekazanym (jak?)
>> hostowi.
>
> Jak użyjesz ftdi, to będziesz miał trochę niepotrzebnych linii I/O, do
> których możesz podpiąć switche i odczytać ich stan programowo.
> Jak byś robił sam urządzenie CDC-ACM, to możesz jego numer
> seryjny zmieniać na podstawie stanu switchy.

FTDI był użyty tylko w celu nakierowania na to co planuję... :-)
W faktycznym projekcie nie używam chipsetu FTDI tylko firmy EXAR,
model scalaka to XR21B1422 (to jest USB -> 2xUART+ kilka GPIO).

do góry

Pan Pszemol napisał:

>>> Czy numer gniazda w USB hosta lub huba jest programowo rozpoznawalny?
>>
>> Tak, np. dla jednego z urządzeń CDC-ACM ścieżka wygląda tak:
>> /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.2/1-1.
2.4/1-1.2.4:1.1/tty/ttyACM0
>>
>> odczytane za pomocą: udevadm info -a -p $(udevadm info -q path -n
>> /dev/ttyACM0)
>>
>> Widać po kolei do której magistrali pci jest podłączony kontroler, potem
>> hub, jest tam też (chyba) numer gniazda w hubie, ale nie pytaj mnie o
>> dokładne znaczenie tych liczb, bo nie było mi to jeszcze do niczego
>> potrzebne.
>
> Dzięki, pobawię się tym ... Jeśli to tak działa to pięknie, nie potrzebuje
> przełączników obrotowych identyfikujących która z 5 czy 10 płytek
> modułowych jest podłaczona do jakich urządzeń zewnętrznych.

W tej sytuacji w ogóle należy zainteresowć się tworzeniem reguł
umieszczonych w /etc/udev. Tam można dość dokładnie opisać, co
ma się stać po włożeniu czegoś konkretnego do konkretnej dziurki.

--
Jarek

do góry

"Jarosław Sokołowski" <j...@l...waw.pl> wrote in message
news:slrnn47clr.13p.jaros@falcon.lasek.waw.pl...
> Pan Pszemol napisał:
>
>>>> Czy numer gniazda w USB hosta lub huba jest programowo rozpoznawalny?
>>>
>>> Tak, np. dla jednego z urządzeń CDC-ACM ścieżka wygląda tak:
>>> /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.2/1-1.
2.4/1-1.2.4:1.1/tty/ttyACM0
>>>
>>> odczytane za pomocą: udevadm info -a -p $(udevadm info -q path -n
>>> /dev/ttyACM0)
>>>
>>> Widać po kolei do której magistrali pci jest podłączony kontroler, potem
>>> hub, jest tam też (chyba) numer gniazda w hubie, ale nie pytaj mnie o
>>> dokładne znaczenie tych liczb, bo nie było mi to jeszcze do niczego
>>> potrzebne.
>>
>> Dzięki, pobawię się tym ... Jeśli to tak działa to pięknie, nie
>> potrzebuje
>> przełączników obrotowych identyfikujących która z 5 czy 10 płytek
>> modułowych jest podłaczona do jakich urządzeń zewnętrznych.
>
> W tej sytuacji w ogóle należy zainteresowć się tworzeniem reguł
> umieszczonych w /etc/udev. Tam można dość dokładnie opisać, co
> ma się stać po włożeniu czegoś konkretnego do konkretnej dziurki.

Dzięki. Bardziej mi chodzi o wstanie systemu z nową konfiguracją
w czasie power-on. W tym akurat systemie nie przewiduję wkładania,
ani wyjmowania płytek pod napięciem. Mimo że USB to umożliwia.
Czy z punktu widzenia systemu to też obsługuje /etc/udev ?

do góry

Pan Pszemol napisał:

>> W tej sytuacji w ogóle należy zainteresowć się tworzeniem reguł
>> umieszczonych w /etc/udev. Tam można dość dokładnie opisać, co
>> ma się stać po włożeniu czegoś konkretnego do konkretnej dziurki.
>
> Dzięki. Bardziej mi chodzi o wstanie systemu z nową konfiguracją
> w czasie power-on. W tym akurat systemie nie przewiduję wkładania,
> ani wyjmowania płytek pod napięciem. Mimo że USB to umożliwia.
> Czy z punktu widzenia systemu to też obsługuje /etc/udev ?

Tak, nie ma większego znaczenia, czy rozpoznawanie dotyczy sytuacji
wkładania wtyczki w gniazdko, czy startu systemu. Udev jest porządnie
zrobionym podsystemem, można opisać co się chce (i czego się nie chce,
by system robił).

--
Jarek

do góry

W dniu 2015-11-11 o 23:03, Pszemol pisze:

> Dzięki. Bardziej mi chodzi o wstanie systemu z nową konfiguracją
> w czasie power-on. W tym akurat systemie nie przewiduję wkładania,
> ani wyjmowania płytek pod napięciem. Mimo że USB to umożliwia.
Widzę że panowie zafiksowaliście się na tych numerach, co po czym i
dlaczego itp itd.
Nie szkoda czasu na takie szukanie po omacku, które w dodatku ma
wątpliwą gwarancję działania?
Może warto pójść warstwę wyżej i zrobić mechanizm typu: pytamy moduł co
on za jeden i jakie ma dane, a jak nam odpowiedź pasuje to utrzymujemy
połączenie i pobieramy dane (a jak nam odpowiedź się nie spodoba to
zamykamy port i niech inni próbują). Albo na podstawie odpowiedzi dajemy
cynk do aplikacji, którego portu ma używać żeby otrzymać właściwe dane.
Można zrobić program rozbiegowy który przepyta wszystkie dostępne porty
i przygotuje odpowiedni plik konfiguracyjny dla głównej aplikacji.

--
Pozdrawiam
Piotrek

do góry

"Jarosław Sokołowski" <j...@l...waw.pl> wrote in message
news:slrnn47fo7.423.jaros@falcon.lasek.waw.pl...
> Pan Pszemol napisał:
>
>>> W tej sytuacji w ogóle należy zainteresowć się tworzeniem reguł
>>> umieszczonych w /etc/udev. Tam można dość dokładnie opisać, co
>>> ma się stać po włożeniu czegoś konkretnego do konkretnej dziurki.
>>
>> Dzięki. Bardziej mi chodzi o wstanie systemu z nową konfiguracją
>> w czasie power-on. W tym akurat systemie nie przewiduję wkładania,
>> ani wyjmowania płytek pod napięciem. Mimo że USB to umożliwia.
>> Czy z punktu widzenia systemu to też obsługuje /etc/udev ?
>
> Tak, nie ma większego znaczenia, czy rozpoznawanie dotyczy sytuacji
> wkładania wtyczki w gniazdko, czy startu systemu. Udev jest porządnie
> zrobionym podsystemem, można opisać co się chce (i czego się nie chce,
> by system robił).

Super - dzięki Wam wszystkim za pomoc...
Niestety cienki bolek ze mnie jesli chodzi o linuxa.
Pewne rzeczy warto wiedzieć w fazie początkowej projektowania
aby sobie później nie pluć w brodę że mogło się zrobić inaczej ;-)

do góry

"Piotr Dmochowski" <i...@p...onet.pl> wrote in message
news:5643c0a6$0$22826$65785112@news.neostrada.pl...
>> Dzięki. Bardziej mi chodzi o wstanie systemu z nową konfiguracją
>> w czasie power-on. W tym akurat systemie nie przewiduję wkładania,
>> ani wyjmowania płytek pod napięciem. Mimo że USB to umożliwia.
> Widzę że panowie zafiksowaliście się na tych numerach, co po czym i
> dlaczego itp itd.
> Nie szkoda czasu na takie szukanie po omacku, które w dodatku ma wątpliwą
> gwarancję działania?
> Może warto pójść warstwę wyżej i zrobić mechanizm typu: pytamy moduł co on
> za jeden i jakie ma dane, a jak nam odpowiedź pasuje to utrzymujemy
> połączenie i pobieramy dane (a jak nam odpowiedź się nie spodoba to
> zamykamy port i niech inni próbują). Albo na podstawie odpowiedzi dajemy
> cynk do aplikacji, którego portu ma używać żeby otrzymać właściwe dane.
> Można zrobić program rozbiegowy który przepyta wszystkie dostępne porty i
> przygotuje odpowiedni plik konfiguracyjny dla głównej aplikacji.

Problem z Twoim pomysłem pojawi się, gdy do szyny USB będą
podłączone dwa identyczne moduły rozmawiające z identycznym
typem urządzeń do kórych użytkownik będzie chciał mieć intymny
dostęp znając ich fizyczną lokalizację i przypisanie do reszty systemu.
Wymiana takiej płytki modułu (po burzy, po awarii) powinna dać
rezultat w postaci automatycznej rekonfiguracji podłączonych
urządzeń w to samo miejsce w architekturze całego urządzenia
i być do odróżnienia od sytuacji gdy ktoś dokłada nową płytkę
a nie wymienia uszkodzonej. Przypominam że płytki są identyczne
pod wpływem typu samej płytki (np. po prostu porty RS485)
i pod wpływem typu urzadzęń do jakich akurat są podłączone.

do góry