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

Tue Nov 10, 2015 4:15 am   

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.

Tue Nov 10, 2015 10:14 am   

W dniu 2015-11-10 o 04:15, Pszemol pisze:

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

Tue Nov 10, 2015 10:30 am   

Użytkownik "Mario" napisał w wiadomości grup
dyskusyjnych:n1scdk$mrb$1@dont-email.me...

A FT230 lepiej wznawia, czy nie resetuje sie ?


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

J.

Tue Nov 10, 2015 10:33 am   

On Tue, 10 Nov 2015 10:14:36 +0100, Mario <Mario@w.pl> wrote:

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

Tue Nov 10, 2015 1:02 pm   

W dniu 2015-11-10 o 10:30, J.F. pisze:

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



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


--
pozdrawiam
MD

Tue Nov 10, 2015 1:19 pm   

W dniu 2015-11-10 o 10:33, Marek pisze:

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

Tue Nov 10, 2015 1:55 pm   

"Mario" <Mario@w.pl> wrote in message news:n1scdk$mrb$1@dont-email.me...

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.


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


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

Tue Nov 10, 2015 2:21 pm   

On Tue, 10 Nov 2015 13:19:55 +0100, Mario <Mario@w.pl> wrote:


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



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


Kiepskich programistów jest pełno .

--
Marek

Tue Nov 10, 2015 8:18 pm   

On 10.11.2015 10:33, Marek wrote:


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

Tue Nov 10, 2015 9:41 pm   

On Tuesday, November 10, 2015 at 4:15:34 AM UTC+1, Pszemol wrote:

jakosci.


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?

Tue Nov 10, 2015 10:04 pm   

On 2015-11-10 04:15, Pszemol wrote:

Dramatu nie ma, ale warto poczytać może jakis poradnik:

http://tinyurl.com/ns3622p

Książki ogólnie nie polecam z powodu nagłego ataku patriotycznego
tłumaczenia wszystkie co popadnie, ale usb jest wyjasnione na poziomie
nie najgorszym, w tym jest przykład portu szeregowego i na zbliżonej
arch to bazuje.

Wed Nov 11, 2015 12:57 am   

W dniu 2015-11-10 o 20:41, brak pisze:

O jakim kontrolerze piszesz? 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.

--
pozdrawiam
MD

Wed Nov 11, 2015 1:39 am   

"Zbych" <zbych@onet.pl> wrote in message
news:5642430f$0$702$65785112@news.neostrada.pl...

Ach, tu mi uzmysłowiłeś że chciałem zapytać też o coś innego...
A mianowicie identyfikację portów wielokrotnie powtórzonych.
Innymi słowy mam płytkę wtykaną w USB, na płytce dwa UARTy.
W porzo. Teraz chcę takich płytek mieć 5, każda po dwa UARTy.
Jak zidentyfikuję która płytka jest na którym /dev/sda0...8 czy
jak się one tam zwą? A po pierwotnej instalacji, coś się schrzani,
pierun trzaśnie, serwisant płytkę wymieni, i jak wpasować nową
aby widoczna była tak samo jak stara?

Wprowadzić jakiś osobny identyfikator na jakimś obrotowym
przełączniku? Czy da się to przemycić jakoś w samym USB?
Jakiś design pattern dla linuxa i portów szeregowych?
Widziałem np. kostkę XAR co robi USB -> Dual UART, pod
Windows 7 pojawiają mi się na liście sterowników Port A i Port B.
I można im przydzielić COM4 i COM5 na ten przykład...
Czyli wiem że Port A i B to COM4 i COM5 ale gdybym tych
płytek miał więcej, i wetknął wszystkie na raz a nie pokolei to
nie miałbym pojęcia który jest A i B a który jest C i D lub E i F?

Wed Nov 11, 2015 1:42 am   

"brak" <jerzdy@gmail.com> wrote in message
news:c0da44d9-d1de-490e-b077-5a64bab0297d@googlegroups.com...

Ta trwałość nie dotyczy jednorazowej instalacji i konfiguracji.
Jak to w świecie embedded bywa, użytkownik nie ładuje
tam swojego softu, nie zmienia funkcjonalności - user
zamawia to i tamto, ja mu to konfiguruję i wysyłam...
Co nie znaczy że dla każdego usera będę osobne płytki
majstrował dla każdej różnej permutacji możliwości

Wed Nov 11, 2015 1:44 am   

"Mario" <Mario@w.pl> wrote in message news:n1u05r$ad7$1@dont-email.me...

Moze zmyliłem go niefortunnym użyciem słowa "pecet".
Miałem to w luźnym słowa tego znaczniu, w sensie coś co ma
gigowy rdzeń i robi pod linuxem a nie jest embeded 8051 lub PIC
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ł.
Wykorzystam USB, potem HUBa i dalej wciąż USB do modułów.