On Wed, 11 Nov 2015 17:30:43 +0100, Zbych <a...@o...pl> wrote:
> Masz do wyboru:
> 1. numer seryjny

No to specyfikacja USB narzuca, nie powinny być wpięte do hosta dwa
lub więcej urządzeń z tym samym nr seryjnym w deskryptorze.

--
Marek

do góry

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.

--
Pozdrawiam
Jakub Rakus

do góry

On Wednesday, November 11, 2015 at 1:44:37 AM UTC+1, Pszemol wrote:
> "Mario" <M...@...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.

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

do góry

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" <M...@...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?


--
pozdrawiam
MD

do góry

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" <M...@...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.

do góry

"brak" <j...@g...com> wrote in message
news:0caab8a2-677c-4ed1-8443-253437f36c6a@googlegrou
ps.com...
> 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" <M...@...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.

Panowie, co jest niejasne tutaj? :-) Chętnie uzupełnię...
Czy od wyjaśnienia tej niejasności w jakiś spośób zależy dalsza dyskusja czy
wpływa na odpowiedź na pytanie?

do góry

On 12.11.2015 00:08, Jarosław Sokołowski wrote:
> 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.
>

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.

do góry

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.

--
Jarek

do góry

On Thu, 12 Nov 2015 18:02:40 +0100, Zbych <z...@o...pl> wrote:
> 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.

Dlaczego symlink miałby się sam aktuakuzować?

--
Marek

do góry

On 12.11.2015 23:34, Jarosław Sokołowski wrote:
> 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

Sprawdziłem jeszcze raz, faktycznie symlinki są aktualizowane poprawnie.

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

do góry