Sterownik USB dla mikrokontrolerów - sonda.

Witam,

Zastanawiam się, czy ze strony elektroników było by zainteresowanie sterownikiem do PC (Windows/Linux) umożliwiającym wymianę danych między mikrokontrolerem a PC. W mikrokontrolerze trzeba by było skonfigurować dwa endpointy i obsługę transmisji usb, po stronie PC mielibyśmy do dyspozycji funkcje wyślij/odbierz dane i tyle.

Gdy zaczynałem przygodę z USB w mikrokontrolerach sterownik był tym czego nie potrafiliśmy przeskoczyć. Teraz jest on gotowy, a programista jest otwarty na współpracę.

Jak myślicie, czy warto poświęcić czas by go udostępnić, czy to się komuś przyda?

Reply to
Andrzej W.
Loading thread data ...

Jakich mikrokontrolerów? Bo obecność USB w peryferiach mikrokontrolera nie jest rzeczą powszechną.

Jasne. Gotowiec na start to świetna sprawa. Potrafi zaoszczędzić kilka dni pracy. Kiedys przegryzałem się przez USB dla kontrolerów Cypressa i ładnych kilka dni siedziałem zanim coś rozsądnie zaczeło działać.

Reply to
Piotr "PitLab" Laskowski

Andrzej W. pisze:

Na czym oparte? LibUSB (przenośność Linux/cygwin) czy tylko windowsowe? Jak duże bloki danych

Jeśli soft otwarty te pewnie byliby zainteresowani. Na przykład ja.

Reply to
Mario

Piotr "PitLab" Laskowski pisze:

Projekt ma obejmować oprogramowanie do PC oraz opis formatu w jakim dane będą docierać do mikrokontrolera i konfiguracji USB. Odpowiedz więc brzmi właściwie dla wszystkich obsługującego USB. Obsługę USB w samym mikrokontrolerze trzeba będzie już zrobić sobie samemu.

Reply to
Andrzej W.

Mario pisze:

Sterowniki napisane są w C. (Windows/DDK, Linux/gcc)

Protokół transmisji pomyślany jest tak, by nie limitował ilości przesyłanych danych. Dane przesyłane są w paczkach 32 bajtowych, z tego co pamiętam.

Tak, planujemy by soft był dostępny za darmo również do zastosowań komercyjnych.

Reply to
Andrzej W.

Rozumiem ze to softwarowy sterownik wykorzystujacy jakies 2 piny GPIO do transmisji ?

Reply to
MT

MT pisze:

Ja zrozumiałem, że to ma być uniwersalny sterownik dla PC aby ułatwić elektronikom uruchamianie mikrokontrolerów z USB na pokładzie. Ale może się mylę?

Reply to
Mario

Andrzej W. pisze:

Jak będziecie gotowi udostępnić stronkę projektu to dajcie info na grupę.

Reply to
Mario

Mario pisze:

Tak, dokładnie o tym myślę.

Reply to
Andrzej W.

My?l? ?e to bardzo dobry pomys?

Reply to
Mewsik

W DDK jest kilka gotowych sterowników pod usb jako sampli więc nic nie trzeba pisać :) tylko przekompilować.

Co to za protokół ? EP w FS ma 64B w HS 512 więc czemu ograniczasz do 32 B? Bufor OHCI/ EHCI jest bodajże 4KB więc jak chcesz słać paczki 32B w rozsądnej szybkości?

Pytanie pozostaje otwarte : jakiego rzędu transfery spodziewasz się uzyskać?

Jak rozwiążesz sprawę VIDu ? szczególnie w zastosowaniach komercyjnych?

MiSter

Reply to
Mister

Mister pisze:

Jeśli ktoś to robi na co dzień to pewnie bułka z masłem, pytanie tylko ile osób na tej grupie używa DDK.

Rozwiązanie ma być przeznaczone raczej dla ludzi zaczynających zabawę z USB w mikrokontrolerach, ma ono ułatwić start, nie aspiruje do bycia lekiem na całe zło.

Czy aby się trochę nie zapędzasz, co to ma wspólnego z biblioteką dla PC? Równie dobrze mógłbyś mi zarzucić, że nie przedstawiłem pomysłu na zdobycie funduszy potrzebnych na zakup odpowiedniego mikrokontrolera...

Reply to
Andrzej W.

Andrzej W. pisze:

To ma sens jedynie jeżeli będą (docelowo) dostępne sterowniki windozowe podpisane przez WHQL, m.in. do Visty 32- i 64-bitowej. W innym przypadku lepiej wykorzystać już gotowy, sprawdzony sterownik (np. do układu FT245, udostępniający wirtualny port COM) i skupić się na przygotowaniu biblioteki dla mikrokontrolera "udającej" układ FT245. Można też jeszcze prościej - oprogramować w mikrokontrolerze klasę CDC ACM i skorzystać z dobrodziejstwa standardowego sterownika usbser.sys (w Windows) lub wbudowanego sterownika Linuxa.

Podsumowując: zabawa z własnymi sterownikami dla PC jest fajna, ale najpierw lepiej się skupić na oprogramowaniu od strony mikrokontrolera i użyciu gotowego certyfikowanego sterownika. Bo gadać z portem COM (choćby wirtualnym) w pececie to chyba każdy umie.

Reply to
Adam Dybkowski

Adam Dybkowski pisze:

Czy jest dostępna gdzieś dokumentacja jak zorganizować obsługę FT245 lub usbser.sys po stronie mikrokontrolera?

Jeśli tak, to jest to chyba najprostsze rozwiązanie, choć sam RS nie jest dla mnie dobrym pomysłem na organizację komunikacji.

Reply to
Andrzej W.

Jak dla mnie, najprostsze rozwiązanie to wykorzystanie klasy HID. Sterownik gotowy w systemie, oprogramowanie tylko klienckie. Jaka prostota instalacji!

Co prawda obsługa HID w Windows jest taka hm... barokowa, ale w końcu - co takie nie jest w Windows. Mi się udało napisać na podstawie samej dokumentacji MSDN, ale "letko" nie było.

Maksymalny transfer, jaki udało mi się wyciągnąć to 64000B/s, czyli dokładnie teoretyczny zasięg (64 bajty w pakietach co 1ms).

Oczywiście pozostaje wciąż zrobienie klasy HID w mikroprocesorze

- ja miałem szczęście i procesorek, który wybrałem (SiLabs) miał tę klasę oprogramowaną w jednej z not aplikacyjnych. Oczywiście trzeba było poprzerabiać, ale było z czego zacząć.

Pozdrowienia, MKi

Reply to
MKi

Witam,

W zasadznie cos takiego juz jest dostepne - nazywasie libusb. Jest to sterowniki, ktory umozliwia obsluge USB z poziomu aplikacji. Jakby jeszcze mial podpis pod Viste 64-bity to bylo by super :) Moze wiec warto by bylo wspomoc ten projekt ?

Pozdr AK

Reply to
AK

AK pisze:

Urządzenie od którego chcemy zaadaptować ten sterownik przeszło przez wszystkie stadia, które tu są opisywane. Zaczęło się od HID, potem było Libusb, teraz dedykowany sterownik. Czemu HID i Libusb okazały się niewystarczające, nie wiem, musiał bym zapytać programistę. Był jednak jakieś powody skoro robił to trzy razy.

Reply to
Andrzej W.

Dla ludzi zaczynających zabawę z usb proponuję klasę HID ewentualnie CDC. Zmiana systemu operacyjnego raczej nie spowoduje zmiany sterownika.

Może się zapędziłem, ale staram się myśleć całościowo :-) szczególnie w zastosowaniach komercyjnych.

Reasumując przy zastosowaniu sterowników systemowych: HID umożliwia transfer max do 64KB/s, CDC nawet do900KB/s (dla trybu FS). Czy jest więc sens pisania własnego sterownika? Odpowiedz pozostawiam czytającym. Przy okazji dodam że na palcach jednej ręki można policzyć firmy zajmujące się pisaniem sterowników usb.

Pozdrawiam Mister

Reply to
Mister

Mister pisze:

HID do zastosowań "ogólnych"? Chyba lekka przesada, to jest dobre raczej do klawiatury czy joysticka.

CDC ACM natomiast to dobra ścieżka, klasa wspierana praktycznie przez każdy współczesny system operacyjny bez potrzeby pisania własnych sterowników.

Transfer 900 KB/s przy prędkości 12 Mb/s to i tak chyba max, co da się osiągnąć (niezależnie od klasy USB). Tak więc rozwiązanie wystarczające.

BTW: Dużymi krokami po cichu wchodzi specyfikacja USB 3.0, z ciekawostek można nadmienić transfer do 4,8 Gb/s i kabel oparty o światłowód (z dodatkowymi żyłami miedzianymi do zasilania i współdziałania ze starymi urządzeniami):

formatting link

Reply to
Adam Dybkowski

Andrzej W. pisze:

Wystarczy zajrzeć do kodu źródłowego sterownika układu FT245 dla Linuxa

- widać wyraźnie, jakie polecenia są przesyłane i jak ramkowane są dane. Nie wiem natomiast w praktyce, jak sam FTDI zapatruje się na takie projekty (narobili się chłopcy ze sterownikami, zapłacili za certyfikację po to, aby zarabiać na sprzedaży scalaka - a tu ktoś symuluje ich scalak w całkiem innym uC i FTDI nie ma z tego kasy).

Sterownik usbser.sys jest wbudowany w każdy system Windows (AFAIR od Windows 2000 w górę) i aby z nim zagadać, wystarczy w mikrokontrolerze oprogramować klasę CDC /ACM/. CDC to klasa komunikacyjna, a ACM dodaje szczegóły "modemowe" (np. kontrola linii DTR, DCD, RI itp). Z tą klasą potrafi też zagadać Linux i pewnie inne systemy operacyjne także.

Przykładowy kod implementacji klasy CDC w mikrokontrolerze można znaleźć m.in. w notach aplikacyjnych Atmela opisujących obsługę USB procesorów AT91SAM7S64 oraz AT91RM9200.

Reply to
Adam Dybkowski

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.