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.

do góry

W dniu 2015-11-10 o 04:15, Pszemol pisze:
> 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.

Jeśli urządzenie ma być na stałe podłączone do PC to nie polecam
korzystania z procka udającego urządzenie USB CDC. Sam tak robiłem przy
pomocy bibliotek LPCUSB. Jeśli nastąpi reset procka (np. przez
Watchdoga) to program w procku będzie chciał na nowo zainicjować USB,
ale host w PC nie będzie mógł zrobić enumeracji bo ma otwarty wirtualny
UART. Lepiej dołożyć te 2$ i dać np FT230. Inna sprawa, że najlepiej dać
jakiś izolator w rodzaju ISO7221 na liniach między prockiem i FT230.
Wtedy zasilasz FT230 z VCC USB i nawet wyłączenie procka z zasilania nie
rozłączy ci połączenia USB z PC, a wiec nie zwiesi ci wirtualnego UART
na którym np nasłuchuje ci chodząca na PC aplikacja.

--
pozdrawiam
MD

do góry

Użytkownik "Mario" napisał w wiadomości grup
dyskusyjnych:n1scdk$mrb$...@d...me...
>Jeśli urządzenie ma być na stałe podłączone do PC to nie polecam
>korzystania z procka udającego urządzenie USB CDC. Sam tak robiłem
>przy pomocy bibliotek LPCUSB. Jeśli nastąpi reset procka (np. przez
>Watchdoga) to program w procku będzie chciał na nowo zainicjować USB,
>ale host w PC nie będzie mógł zrobić enumeracji bo ma otwarty
>wirtualny UART. Lepiej dołożyć te 2$ i dać np FT230.

A FT230 lepiej wznawia, czy nie resetuje sie ?

>Inna sprawa, że najlepiej dać jakiś izolator w rodzaju ISO7221 na
>liniach między prockiem i FT230.

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

J.

do góry

On Tue, 10 Nov 2015 10:14:36 +0100, Mario <M...@...pl> wrote:
> Watchdoga) to program w procku będzie chciał na nowo zainicjować
USB,
> ale host w PC nie będzie mógł zrobić enumeracji bo ma otwarty
wirtualny
> UART.

Jesteś pewien? W moim przypadku robi enumerację i tworzy nowy tty,
gdy aplikacja trzyma uchwyt do starego. Wystarczy w aplikacji wykryć
błąd w komunikacji i zrobić reopen ttyUSBn+1 gdzie n to id poprzednio
otwartego.
Z tego co kojarzę problem z enumeracją w takich przypadkach to brak
pełnej kompatybilności drivera hci w keenelu z tym co wykrył na
płycie.

--
Marek

do góry

W dniu 2015-11-10 o 10:30, J.F. pisze:
> Użytkownik "Mario" napisał w wiadomości grup
> dyskusyjnych:n1scdk$mrb$...@d...me...
>> Jeśli urządzenie ma być na stałe podłączone do PC to nie polecam
>> korzystania z procka udającego urządzenie USB CDC. Sam tak robiłem
>> przy pomocy bibliotek LPCUSB. Jeśli nastąpi reset procka (np. przez
>> Watchdoga) to program w procku będzie chciał na nowo zainicjować USB,
>> ale host w PC nie będzie mógł zrobić enumeracji bo ma otwarty
>> wirtualny UART. Lepiej dołożyć te 2$ i dać np FT230.
>
> A FT230 lepiej wznawia, czy nie resetuje sie ?

NIe zdarzyło mi się żeby zwiesił się FT, a LPC1768 owszem.


>> Inna sprawa, że najlepiej dać jakiś izolator w rodzaju ISO7221 na
>> liniach między prockiem i FT230.
>
> 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.


--
pozdrawiam
MD

do góry

W dniu 2015-11-10 o 10:33, Marek pisze:
> On Tue, 10 Nov 2015 10:14:36 +0100, Mario <M...@...pl> wrote:
>> Watchdoga) to program w procku będzie chciał na nowo zainicjować
> USB,
>> ale host w PC nie będzie mógł zrobić enumeracji bo ma otwarty
> wirtualny
>> UART.
>
> Jesteś pewien? W moim przypadku robi enumerację i tworzy nowy tty, gdy
> aplikacja trzyma uchwyt do starego. Wystarczy w aplikacji wykryć błąd w
> komunikacji i zrobić reopen ttyUSBn+1 gdzie n to id poprzednio otwartego.
> Z tego co kojarzę problem z enumeracją w takich przypadkach to brak
> pełnej kompatybilności drivera hci w keenelu z tym co wykrył na płycie.
>

Pod Windowsem mając otwarty terminal próba pisania do wirtualnego portu
po resecie procka, powodowała zwis tego portu. Nie powstawał przy tym
nowy port. Musiałem ubijać terminal i ponownie wymuszać enumerację np.
wyłączając zasilanie procka lub rozłączając kabel USB. Pewnie dałoby się
to zrobić gdybym np badał w procku czy jest komunikacja i przy jej braku
co trochę inicjalizował USB.
Pod Linuksem, gdyby faktycznie tworzył się nowy port to sądzę, że
programiści zajmujący sie tym potrafili by to zastosować. Wybrali dość
siłowe rozwiązanie polegające na sprzętowym Watchdogu wyłączającym
zasilanie elektroniki będącej na drugim końcu kabla USB :)

--
pozdrawiam
MD

do góry

"Mario" <M...@...pl> wrote in message news:n1scdk$mrb$1@dont-email.me...
> Jeśli urządzenie ma być na stałe podłączone do PC to nie polecam
> korzystania z procka udającego urządzenie USB CDC.

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.
Świat "embedded", jedna aplikacja.

> Sam tak robiłem przy pomocy bibliotek LPCUSB.
> Jeśli nastąpi reset procka (np. przez Watchdoga)
> to program w procku będzie chciał na nowo
> zainicjować USB, ale host w PC nie będzie mógł
> zrobić enumeracji bo ma otwarty wirtualny UART.

Rozumiem. Właśnie dlatego pytam kogoś kto już ma z tym
doświadczenie. Czyli biorę opcję z chipsetem USB-UART.

> Lepiej dołożyć te 2$ i dać np FT230. Inna sprawa, że najlepiej dać jakiś
> izolator w rodzaju ISO7221 na liniach między prockiem i FT230. Wtedy
> zasilasz FT230 z VCC USB i nawet wyłączenie procka z zasilania nie
> rozłączy ci połączenia USB z PC, a wiec nie zwiesi ci wirtualnego UART na
> którym np nasłuchuje ci chodząca na PC aplikacja.

Pomyślę o tym - bardzo dziękuję za rozsądnie brzmiące uwagi :-)

do góry

On Tue, 10 Nov 2015 13:19:55 +0100, Mario <M...@...pl> wrote:
> Pod Windowsem mając otwarty terminal próba pisania do wirtualnego
portu

Ale kogo Windows obchodzi...? Mówimy o Linuksie.


> Pod Linuksem, gdyby faktycznie tworzył się nowy port to sądzę, że
> programiści zajmujący sie tym potrafili by to zastosować.

Ale co, nie wierzysz i mam pokazać film, że tworzony jest nowy tty
jeśli poprzedni padnie a jego uchwyt trzyma proces w userlandzie?

>Wybrali dość
> siłowe rozwiązanie polegające na sprzętowym Watchdogu wyłączającym
> zasilanie elektroniki będącej na drugim końcu kabla USB :)

Kiepskich programistów jest pełno ;).

--
Marek

do góry

On 10.11.2015 10:33, Marek wrote:

> Wystarczy w aplikacji wykryć błąd w
> komunikacji i zrobić reopen ttyUSBn+1 gdzie n to id poprzednio otwartego.

Partyzantka pełną gębą :-) Sprawdzi się jak masz podpięte tylko jedno
urządzenie CDC. Nie lepiej wyszukać urządzenie za pomocą udeva? Jest
dostępne API w c, można spokojnie znaleźć port urządzenia na postawie
numeru VID/PID, albo numeru seryjnego itp. Można też dostawać zdarzenia
związane z podłączaniem/odłączaniem urządzeń.

do góry

On Tuesday, November 10, 2015 at 4:15:34 AM UTC+1, Pszemol wrote:
> 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)?
Zalezy to od posiadanej biblioteki/drvera itd. i ocywiscie jej
jakosci.

> 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.
Dokladnie takie rozwiazenie zastosowalismy na naszym
module z kontrolerem Cortex-M czyli FT232 podpiete strona UART do
kontrolera natomiast strona USB do Hosta z dowolnym OS-em.
Kosztem ok 30 PLN uniknelismy zabawy z USB-CDC. Na kontrolerze Atmel-a
piny USB sa jednoczesnie jedynymi pinami GPIO o "duzej" wydajnosci pradowej.

BTW.
Dlaczego nie mozesz bezposrednio polaczyc procesora z kontrolerem UART-em
skoro ma to byc trwale/stale polaczenie?

do góry