Procesor z USB udający device type UART

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

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.

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.

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.

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.

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

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 ?

Pan Pszemol napisał:

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

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

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.

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

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.

Pan Piotr Dmochowski napisał:

???

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

Pan Pszemol napisał:

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.

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

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?

Ja bym jednak nie mieszał funkcji, złącze niech przekazuje dane, moduł niech raportuje co przekazuje lub do czego sam jest podłączony.

Pan Piotr Dmochowski napisał:

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.

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

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

W dniu wtorek, 10 listopada 2015 04:15:34 UTC+1 użytkownik Pszemol napisał:

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

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.

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

W dniu czwartek, 12 listopada 2015 02:57:32 UTC+1 użytkownik snipped-for-privacy@gmail.com napisał: Jak chcesz, to mogę Ci przesłać międzymordzie zrobjone po mojemu (Xilinx/VHDL).

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

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

Pan Pszemol napisał:

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.

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