Implementacja 32-bitowego procesora ARM jako urządzenia USB-UART dla Linuxa

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.

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

"Piotr Dmochowski" <imie_nazwisko@poczta.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

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ł

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?

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.

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

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

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.

Podaj adres - wyślę.

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

Masz do wyboru:
1. numer seryjny

A to swoja droga ... izolatora na USB jeszcze nie ma ?

Zdaje się że są jakieś szybkie izolatory, które można by dać na linie USB.

On Wednesday, November 11, 2015 at 1:44:37 AM UTC+1, Pszemol wrote:
"Mario" <Mario@w.pl> wrote in message news:n1u05r$ad7$1@dont-email.me...
Dlaczego nie mozesz bezposrednio polaczyc procesora
z kontrolerem UART-em skoro ma to byc trwale/stale polaczenie?

O jakim kontrolerze piszesz?
Dla rozroznienia zwyczajowo procesor typu Cortex-M nazywa sie kontrolerem vel uC
natomiast procesot typu Cortex-A procesorem.

"Mario" <Mario@w.pl> wrote in message news:n1u05r$ad7$1@dont-email.me...
Dlaczego nie mozesz bezposrednio polaczyc procesora
z kontrolerem UART-em skoro ma to byc trwale/stale polaczenie?

O jakim kontrolerze piszesz?
Dla rozroznienia zwyczajowo procesor typu Cortex-M nazywa sie kontrolerem vel uC

On chyba łączy te urządzenie z prockiem do
komputera z Linuksem. Raczej można się spodziewać, że ten komputer nie
będzie miał w ogóle UART.
Taaaa. To nie jest PC in procesorem Intel, np. i.MX6 posiada 5 UART-ow.

A swoją drogą płytka komputera głownego ma 3 UARTy, ale
to za mało, i na dodatek nie są izolowane, więc nie będę ich używał.
Zwykle komputery nie maja optoizolacji to nie ta polka.

W dniu 2015-11-12 o 14:27, brak pisze:
On Wednesday, November 11, 2015 at 1:44:37 AM UTC+1, Pszemol wrote:
"Mario" <Mario@w.pl> wrote in message news:n1u05r$ad7$1@dont-email.me....
Dlaczego nie mozesz bezposrednio polaczyc procesora
z kontrolerem UART-em skoro ma to byc trwale/stale polaczenie?

O jakim kontrolerze piszesz?
Dla rozroznienia zwyczajowo procesor typu Cortex-M nazywa sie
kontrolerem vel uC natomiast procesot typu Cortex-A procesorem.

Czyli uważałeś, ze chce połączyć Cortex-M z Cortex-A?

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

Tak, ma być na stałe podłączone do "jednopłytkowego"
"peceta" embedded na ARMie 1GHz przez port USB3.1.
Moje USB-Device będzie USB2.0, w tej samej skrzynce.