Pan Piotr Dmochowski napisał:

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

Mam wrażenie, że wzmiankowany udev jest właśnie czymś takim, tylko
zrobionym porządnie i uniwersalnie. A nade wszystko JUŻ zrobionym,
więc nie trzeba wiele pisać, wystarczy jedna linijka w pliku reguł.

--
Jarek

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ł).
>
> 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 ;-)

No to się wcześniej bierze dowolnego peceta, wtyka mu swoje diwajsy,
patrzy ewentualnie w komunikaty kernela w logach, a potem pisze lub
modyfikuje regułę udev. To są przenośnie rzeczy, w urządzeniu zrobionym
później, będzie to działać tak samo.

--
Jarek

do góry

W dniu 2015-11-11 o 23:31, Pszemol pisze:
> "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.
Ale jakoś je trzeba rozróżnić. Ja bym wolał dać jakie zworki cz inny
obrotowy przełącznik podający np. kod od 0 do 7, który będzie wysłany
jako fragment odpowiedzi niż uzależniać działanie aplikacji od
kolejności inicjalizacji portów. Jak rozpoznasz dwa takie same moduły
jeżeli po restarcie zmieni się kolejność podłączenia? Możesz
zagwarantować że zawsze jest ta sama sekwencja? Co będzie jak padnie hub
i zmieni się liczba portów, jakieś id czy inny detal i regułka
wyszukująca nie zadziała?

> 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.
Ja bym jednak nie mieszał funkcji, złącze niech przekazuje dane, moduł
niech raportuje co przekazuje lub do czego sam jest podłączony.

--
Pozdrawiam
Piotrek

do góry

Pan Piotr Dmochowski napisał:

>> 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.
> Ale jakoś je trzeba rozróżnić. Ja bym wolał dać jakie zworki cz inny
> obrotowy przełącznik podający np. kod od 0 do 7, który będzie wysłany
> jako fragment odpowiedzi niż uzależniać działanie aplikacji od
> kolejności inicjalizacji portów. Jak rozpoznasz dwa takie same moduły
> jeżeli po restarcie zmieni się kolejność podłączenia?

KERNEL=="sd[a-z]", ACTION=="add|change", \
ENV{DEVPATH}=="/devices/*/1-1/1-1:1.0/host*", SYMLINK+="USB1"

KERNEL=="sd[a-z]", ACTION=="add|change", \
ENV{DEVPATH}=="/devices/*/1-2/1-2:1.0/host*", SYMLINK+="USB2"

...i kolejne analogiczne linijki opisujące reszte portów w systemie.

Akurat jakiś tydzień temu miałem potrzebę, by takie same urządzenia
usb-storage były rozpoznawane na podstawie dziurki, do której zostały
podłączone. I są -- tworzy się dla nich link /dev/USBn, w zależności
od fizycznego umiejsowaienia, a niezależny od kolejności odnajdowania
(tak jak to jest w przypadku samych urządzeń /dev/sda, /dev/sdb...).
Tego właśnie potrzebowałem i dokładnie to mam.

> Możesz zagwarantować że zawsze jest ta sama sekwencja? Co będzie
> jak padnie hub i zmieni się liczba portów, jakieś id czy inny detal
> i regułka wyszukująca nie zadziała?

Obrotowe przełączniki, to ja miałem w urządzeniach podłączanych do
łańcucha SCSI. Dziękuję, wystarczy, przypuszczam, że juz nie chcę.

--
Jarek

do góry

"Jarosław Sokołowski" <j...@l...waw.pl> wrote in message
news:slrnn47h7p.5bg.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 ;-)
>
> No to się wcześniej bierze dowolnego peceta, wtyka mu swoje diwajsy,
> patrzy ewentualnie w komunikaty kernela w logach, a potem pisze lub
> modyfikuje regułę udev. To są przenośnie rzeczy, w urządzeniu
> zrobionym później, będzie to działać tak samo.

Ale moich diwajsów jeszcze przecież nie ma...
Całą infrastrukturę projektujemy od nowa.

I na ten przykład widzę że kolega dał na naszych diwajsach
jako pomysł właśnie taki obrotowy przełącznik, którym
wybiera się cyfrę od 0-9 śrubokrętem płaskim a ja takich
rzeczy strasznie nie lubię. Było to akceptowalne może
w latach 80-tych ale dziś? :-) Come on....

Mam więc teraz już dzięki Wam dwie opcje do przedyskutowania.
I za to dziękuję.

do góry

W dniu wtorek, 10 listopada 2015 04:15:34 UTC+1 użytkownik Pszemol napisał:
> Jak trudno jest udawać USB UART (np. taki jak w chipsach FTDI)
> mając do dyspozycji 32-bitowy procesor z USB, np. ARM
> (Cortex M3 firmy NXP, np. LPC1788 lub M4 LPC4088)?
>
> Buduję urządzenie, które będzie podłączane do linuxa...
> Będzie się komunikowało strumieniem danych dobrze
> reprezentowanym przez coś ala UART i pasowałoby
> się przedstawić do tego linuxa jako dodatkowy port...
>
> Mam więc opcję kupić gotowy chipset USB-UART i połączyć
> z jego UARTem któryś UART z mojego Cortexa M3.
> Ale to wydaje się być trochę nadmiarowe, bo tenże Cortex
> M3 ma już port USB-Device. Gdybym chciał uniknąć
> kładzenia na płytce chipsetu USB-UART i wejść z USB
> wprost na port device mojego Cortexa - jak ciężko jest
> w tym procku udawać że jest się UARTem dla USB Hosta?
>
> Istotne jest aby aplikacja używająca moje urządzenie
> widziała tylko port szeregowy i najchętniej aby nie było
> konieczności pisania specjalnego drivera pod linuxa.

Niestety mam ciuta złe doświadczenia z FTDI, drivery D2XX są ŹLE opisane, tryb FT245
serial mode działa faktycznie szybko (35MB/s), ale przy konfiguracji FTDI=>FPGA=>PC
trza trochę się narobić. Zarówno w HW jak i SW. Jak czytasz z FIFO dane, są
prawidłowe, ale przesunięte w "w fazie" o kilka adresów. Jak chcesz, to mogę Ci
przesłać międzymordzie zrobjone po mojemu (Xilinx/VHDL).
Podaj adres - wyślę.

do góry

"Jarosław Sokołowski" <j...@l...waw.pl> wrote in message
news:slrnn47ijj.63n.jaros@falcon.lasek.waw.pl...
> Pan Piotr Dmochowski napisał:
>
>>> 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.
>> Ale jakoś je trzeba rozróżnić. Ja bym wolał dać jakie zworki cz inny
>> obrotowy przełącznik podający np. kod od 0 do 7, który będzie wysłany
>> jako fragment odpowiedzi niż uzależniać działanie aplikacji od
>> kolejności inicjalizacji portów. Jak rozpoznasz dwa takie same moduły
>> jeżeli po restarcie zmieni się kolejność podłączenia?
>
> KERNEL=="sd[a-z]", ACTION=="add|change", \
> ENV{DEVPATH}=="/devices/*/1-1/1-1:1.0/host*", SYMLINK+="USB1"
>
> KERNEL=="sd[a-z]", ACTION=="add|change", \
> ENV{DEVPATH}=="/devices/*/1-2/1-2:1.0/host*", SYMLINK+="USB2"
>
> ...i kolejne analogiczne linijki opisujące reszte portów w systemie.
>
> Akurat jakiś tydzień temu miałem potrzebę, by takie same urządzenia
> usb-storage były rozpoznawane na podstawie dziurki, do której zostały
> podłączone. I są -- tworzy się dla nich link /dev/USBn, w zależności
> od fizycznego umiejsowaienia, a niezależny od kolejności odnajdowania
> (tak jak to jest w przypadku samych urządzeń /dev/sda, /dev/sdb...).
> Tego właśnie potrzebowałem i dokładnie to mam.

Tak ma być i u nas :-) Identyfikacja co gdzie wsadzone, bez wpływu na to
kiedy wsadzone albo bez wpływu na to że 2-giej płytki brak, bo chwilowo
wyjęta do serwisu, ale 1-sza oraz 3 i 4-ta są i działają normalnie, pod tymi
samymi adresami co były - nic się nie może przesuwać aby zasłonić dziurę,
nic nie może się dublować bo coś się nie do końca odłączyło i zablokowało
COM5 i nagle COM6 się pojawił, jak to się dzieje w Windows.

>> Możesz zagwarantować że zawsze jest ta sama sekwencja? Co będzie
>> jak padnie hub i zmieni się liczba portów, jakieś id czy inny detal
>> i regułka wyszukująca nie zadziała?
>
> Obrotowe przełączniki, to ja miałem w urządzeniach podłączanych do
> łańcucha SCSI. Dziękuję, wystarczy, przypuszczam, że juz nie chcę.

Też mam jakiś uraz archaizmu do wszelkich dip-switchy czy rotary-switchy :-)

do góry

W dniu czwartek, 12 listopada 2015 02:57:32 UTC+1 użytkownik s...@g...com
napisał:
Jak chcesz, to mogę Ci przesłać międzymordzie zrobjone po mojemu (Xilinx/VHDL).
> Podaj adres - wyślę.

ZROBIONE, a nie ZROBJONE -- upsss. paluch mi się "omksnął" na klawiaturze.

do góry

<s...@g...com> wrote in message
news:9f54e8cc-15d0-4a4e-9c6a-bad9aa01b048@googlegrou
ps.com...
> W dniu wtorek, 10 listopada 2015 04:15:34 UTC+1 użytkownik Pszemol
> napisał:
>> Jak trudno jest udawać USB UART (np. taki jak w chipsach FTDI)
>> mając do dyspozycji 32-bitowy procesor z USB, np. ARM
>> (Cortex M3 firmy NXP, np. LPC1788 lub M4 LPC4088)?
>>
>> Buduję urządzenie, które będzie podłączane do linuxa...
>> Będzie się komunikowało strumieniem danych dobrze
>> reprezentowanym przez coś ala UART i pasowałoby
>> się przedstawić do tego linuxa jako dodatkowy port...
>>
>> Mam więc opcję kupić gotowy chipset USB-UART i połączyć
>> z jego UARTem któryś UART z mojego Cortexa M3.
>> Ale to wydaje się być trochę nadmiarowe, bo tenże Cortex
>> M3 ma już port USB-Device. Gdybym chciał uniknąć
>> kładzenia na płytce chipsetu USB-UART i wejść z USB
>> wprost na port device mojego Cortexa - jak ciężko jest
>> w tym procku udawać że jest się UARTem dla USB Hosta?
>>
>> Istotne jest aby aplikacja używająca moje urządzenie
>> widziała tylko port szeregowy i najchętniej aby nie było
>> konieczności pisania specjalnego drivera pod linuxa.
>
> Niestety mam ciuta złe doświadczenia z FTDI, drivery D2XX są ŹLE opisane,
> tryb FT245 serial mode działa faktycznie szybko (35MB/s), ale przy
> konfiguracji FTDI=>FPGA=>PC trza trochę się narobić. Zarówno w HW jak i
> SW. Jak czytasz z FIFO dane, są prawidłowe, ale przesunięte w "w fazie" o
> kilka adresów. Jak chcesz, to mogę Ci przesłać międzymordzie zrobjone po
> mojemu (Xilinx/VHDL).
> Podaj adres - wyślę.

Dziękuję bardzo ale ani tam nie będę miał FTDI ani nie FPGA.

do góry

Pan Pszemol napisał:

>>> Jak rozpoznasz dwa takie same moduły jeżeli po restarcie zmieni się
>>> kolejność podłączenia?
>>
>> KERNEL=="sd[a-z]", ACTION=="add|change", \
>> ENV{DEVPATH}=="/devices/*/1-1/1-1:1.0/host*", SYMLINK+="USB1"
>>
>> KERNEL=="sd[a-z]", ACTION=="add|change", \
>> ENV{DEVPATH}=="/devices/*/1-2/1-2:1.0/host*", SYMLINK+="USB2"
>>
>> ...i kolejne analogiczne linijki opisujące reszte portów w systemie.
>>
>> Akurat jakiś tydzień temu miałem potrzebę, by takie same urządzenia
>> usb-storage były rozpoznawane na podstawie dziurki, do której zostały
>> podłączone. I są -- tworzy się dla nich link /dev/USBn, w zależności
>> od fizycznego umiejsowaienia, a niezależny od kolejności odnajdowania
>> (tak jak to jest w przypadku samych urządzeń /dev/sda, /dev/sdb...).
>> Tego właśnie potrzebowałem i dokładnie to mam.
>
> Tak ma być i u nas :-) Identyfikacja co gdzie wsadzone, bez wpływu na to
> kiedy wsadzone albo bez wpływu na to że 2-giej płytki brak, bo chwilowo
> wyjęta do serwisu, ale 1-sza oraz 3 i 4-ta są i działają normalnie, pod tymi
> samymi adresami co były - nic się nie może przesuwać aby zasłonić dziurę,
> nic nie może się dublować bo coś się nie do końca odłączyło i zablokowało
> COM5 i nagle COM6 się pojawił, jak to się dzieje w Windows.

W przypadku portów szeregowych rozwiązuje się to analogicznie -- udev
dla urządzenia widzianego jako UART wpiętego do dziurki numer 4 (i tylko
do niej) robi alias /dev/bulbulator i sprawa załatwiona.

>>> Możesz zagwarantować że zawsze jest ta sama sekwencja? Co będzie
>>> jak padnie hub i zmieni się liczba portów, jakieś id czy inny detal
>>> i regułka wyszukująca nie zadziała?
>>
>> Obrotowe przełączniki, to ja miałem w urządzeniach podłączanych do
>> łańcucha SCSI. Dziękuję, wystarczy, przypuszczam, że juz nie chcę.
>
> Też mam jakiś uraz archaizmu do wszelkich dip-switchy czy rotary-switchy :-)

Ale jakieś numery seryjne warto mieć, jeśli jest taka możliwość. Karty
sieciowe rozpoznaje się w udev przez ich MAC, a potem obsługuje się w
sposób indywidualny. Nazwę urządzenia (typu eth3) też można tam zmienić).

--
Jarek

do góry