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

On Thursday, November 12, 2015 at 3:17:00 PM UTC+1, Mario wrote:
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...

oraz

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.

Z powyzszych informacji tak wynika.
A co autor mial na mysli to trzeba dopytac autora.

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.

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.

Symlinki są do dupy. Zrobiłem prosty test: otworzyłem port przez symlink
w terminalu, wypiąłem w trakcie pracy terminala port, podłączyłem go
znowu i symlink nie został zaktualizowany.

Symlinki są do dupy. Zrobiłem prosty test: otworzyłem port przez
symlink
w terminalu, wypiąłem w trakcie pracy terminala port, podłączyłem
go
znowu i symlink nie został zaktualizowany.

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

Symlinki są do dupy. Zrobiłem prosty test: otworzyłem port przez symlink
w terminalu, wypiąłem w trakcie pracy terminala port, podłączyłem go
znowu i symlink nie został zaktualizowany.

SOA#1 -- to chciałem, to mam. Kol. Pszemol też chyba nie chce niczego

wypinać -- jak w czsie bootowania systemu link prowadił do /dev/dupa,
to tak już pozostanie aż do wyłączenia zasilania.

-- jak w czsie bootowania systemu link prowadił do /dev/dupa,
to tak już pozostanie aż do wyłączenia zasilania.

Wystarczy zakłócenie, które zresetuje urządzenie USB, nikt nie
musi wyjmować wtyczki z gniazdka.

Pan Zbych napisał:

-- jak w czsie bootowania systemu link prowadił do /dev/dupa,
to tak już pozostanie aż do wyłączenia zasilania.

Wystarczy zakłócenie, które zresetuje urządzenie USB, nikt nie
musi wyjmować wtyczki z gniazdka.

Tak, a "CE", to skrót od "China Eksport".

-- jak w czsie bootowania systemu link prowadił do /dev/dupa,
to tak już pozostanie aż do wyłączenia zasilania.

Wystarczy zakłócenie, które zresetuje urządzenie USB, nikt nie
musi wyjmować wtyczki z gniazdka.

Tak, a "CE", to skrót od "China Eksport".

Każde urządzenie kiedyś się wykrzaczy, kwestia energii zakłóceń.
Ale oczywiście możesz żyć w przekonaniu, że tylko "China Export"
się krzaczy.

Wystarczy zakłócenie, które zresetuje urządzenie USB,
nikt nie musi wyjmować wtyczki z gniazdka.

Tak, a "CE", to skrót od "China Eksport".

Każde urządzenie kiedyś się wykrzaczy, kwestia energii zakłóceń.
Ale oczywiście możesz żyć w przekonaniu, że tylko "China Export"
się krzaczy.

No więc nie spotkałem się z sytuacją, by wykrzaczyło się urządzenie USB.
Nawet w tym sensie, że się nie zawiesza, lecz tylko resetuje i musi być
ponownie zarejestrowane przez host. To nie jest przekonanie, takie rzeczy
zapisywane są w logach. A właściwie nie są -- jeśli rozpatrywać rzecz
w innym ujęciu. Nie wykluczam, że część z tych urządzeń nawet nie miała
certyfikatu CE -- USB to po prostu odporna technologia.

Wystarczy zakłócenie, które zresetuje urządzenie USB,
nikt nie musi wyjmować wtyczki z gniazdka.

Tak, a "CE", to skrót od "China Eksport".

Każde urządzenie kiedyś się wykrzaczy, kwestia energii zakłóceń.
Ale oczywiście możesz żyć w przekonaniu, że tylko "China Export"
się krzaczy.

No więc nie spotkałem się z sytuacją, by wykrzaczyło się urządzenie USB.
Nawet w tym sensie, że się nie zawiesza, lecz tylko resetuje i musi być
ponownie zarejestrowane przez host. To nie jest przekonanie, takie rzeczy
zapisywane są w logach. A właściwie nie są -- jeśli rozpatrywać rzecz
w innym ujęciu. Nie wykluczam, że część z tych urządzeń nawet nie miała
certyfikatu CE -- USB to po prostu odporna technologia.

Nie bardzo rozumiem ten komentarz...
Co ma "odporność USB" na reset samego urządzenia do USB podłącoznego?

W dniu 10.11.2015 o 13:02, Mario pisze:

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.


Jest taka kostka ADUM4160. Sprawdziłem, działa w porządku, tylko trzeba
"ręcznie" jej wskazać poziomem na dwóch pindolkach czy gadamy po USB FS
czy LS.