Elektroda.pl
Elektroda.pl
X

Wyszukiwarki naszych partnerów

Wyszukaj w ofercie 200 tys. produktów TME
Kategoria: Kamery IP / Alarmy / Automatyka Bram
Montersi
Proszę, dodaj wyjątek elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

USB na ATXMEGA128A4U-AU - wątpliwości

MateuszW_ 27 Kwi 2015 20:25 2304 24
  • #1 27 Kwi 2015 20:25
    MateuszW_
    Poziom 7  

    Witajcie
    Mam dwa pytania odnośnie używania USB mikrokontrolera ATXMEGA128A4U-AU w trybie wirtualnego portu szeregowego. Dotychczas korzystałem z FT232 i UART w mikrokontrolerze ATMega, ale postanowiłem iść z duchem czasu i użyć sprzętowego USB w Xmega. Zaoszczędzę kilkanaście zł na układzie i trochę miejsca na płytce, co jest dla mnie bardzo ważne.

    1) Jaka jest jakość tego sprzętowego USB? W sensie, czy jest ono tak niezawodne, jak np FT232? Projektuję urządzenie, które musi być odporne na wszelkie problemy i nie chciałbym, żeby USB się co chwila wywalało. Urządzenie nie potrzebuje dużej prędkości transmisji, ale wysoką odporność na warunki zewnętrzne (niskie temperatury/wilgotność). Wiem, że niektóre konwertery USB/RS232 stwarzają problemy i dlatego używałem niezawodnego FT232 i chciałbym, żeby procek z wbudowanym USB mi tej niezawodności nie popsuł. Rozumiem, że będzie to w 100% zgodne ze standardem USB i RS232?

    2) Planuję posłużyć się tym przykładem: http://mikrokontrolery.blogspot.com/2011/03/X...emulacja-portu-szeregowego-rs-232-na-USB.html Moje urządzenie będzie w przyszłości sprzedawane komercyjnie i zaniepokoił mnie ten fragment:

    Cytat:
    Problem w tym, że urządzenia USB muszą posiadać swój unikalny identyfikator VID/PID. W naszym przykładzie pasożytujemy nieco na firmie Atmel, wykorzystując ich identyfikatory (pamiętaj jednak, że absolutnie nie wolno robić tego w urządzeniach komercyjnych!).

    Pytam się więc, jak ten problem rozwiązać? W którymś z komentarzy ktoś napisał, że uzyskanie swojego identyfikatora to koszt $5000, co jest dla mnie absurdalną ceną. Jest wiec metoda, żeby używać tego wirtualnego RSa na USB bez żadnych opłat i w pełni legalnie? Nie rozumiem, czemu niby można korzystać ze sterowników do FT232, a do Xmega już nie.

    Z góry dziękuję za odpowiedzi.



    ----
    Wydzielono z tematu: USB na ATXMEGA128A4U-AU - wątpliwości
    przez dondu dnia 27 Kwi 2015 21:17

  • #2 27 Kwi 2015 22:09
    tmf
    Moderator Mikrokontrolery Projektowanie

    Tak, w XMEGA USB jest w pełni zgodne ze standardem, inaczej nie mogliby tego nazwać interfejsem USB. Działa stabilnie w trudnych warunkach, żadnych dziwnych rozłączeń i innych problemów. Problemy u mnie dopiero wystąpiły jak w pobliżu kabla USB (razem z nim) szedł kabel do silników, które pobierały po kilkanaście amperów. Wtedy USB padało, ale nie jest to dziwne.
    Co do VID/PID - Atmel pozwala używać swojego, podobnie FTDI pozwala. Problem w tym, że dopóki nie wykupisz unikalnego VID/PID nie masz gwarancji, że coś innego się nie podszyje pod twoje USB. W przypadku VCP problem niewielki, identyfikację możesz jeszcze dodać na poziomie protokołu RS232. Pamiętaj też, że żeby legalnie na swoim urządzeniu umieścić znaczek USB musisz mieć wykupioną licencję/należeć do organizacji USB, a członkostwo kosztuje... Były jakieś próby odsprzedawania niewielkich puli identyfikatorów za rozsądną cenę, ale USB to bardzo zwalcza. Niemniej, jeśli nie do końca po myśli USB wykupisz od innej firmy numery to powinno być ok - co prawda organizacja USB próbowała banować takie numery, ale i tak nie mogą ich nikomu innemu odsprzedać (konflikt z już istniejącymi urządzeniami o takich identyfikatorach) więc wszystko powinno być ok.

  • #3 28 Kwi 2015 11:22
    MateuszW_
    Poziom 7  

    Bardzo dziękuję za odpowiedź, uspokoiłeś mnie. Czyli jak rozumiem, z tymi identyfikatorami chodzi o to, żeby chronić moje urządzenie przed jakimiś np podróbkami, ale jak mi to nie przeszkadza, to mogę w pełni legalnie używać tego od Xmega? W moim przypadku raczej nie będzie problemów z jakimś podszywaniem itp, więc na razie będę działać na identyfikatorze z Xmega.

  • #4 28 Kwi 2015 16:13
    tmf
    Moderator Mikrokontrolery Projektowanie

    Nie chodzi o podszywanie się. System operacyjny identyfikuje urządzenie USB po VID i PID, na tej podstawie wczytuje odpowiedni sterownik. Bez wykupionych identyfikatorów nie masz gwarancji jaki sterownik wybierze OS - jeśli użytkownik sobie wcześniej testował na tych numerach jakiś swój projekt i pod to ma sterownik w OS to twoje urządzenie nie będzie działało. Oczywiście w 99% pzypadków nie będzie problemu. Poza tym bez wykupionych numerów (członkostwa w organizacji USB) nie masz prawa na swoich produktach, ani w instrukcji umieszczać loga USB.

  • #5 28 Kwi 2015 20:22
    MateuszW_
    Poziom 7  

    Ok, teraz rozumiem. A dokładnie jaka grupa urządzeń będzie miała ten sam identyfikator? To będą wszystkie procesory Xmega, czy może wszystkie produkty Atmela?
    Czyli rozumiem, że jak ktoś używa swojego Xmega np ze swoim sterownikiem, a ode mnie ma moje urządzenie, to nie będzie w stanie na raz używać dwóch różnych sterowników do tych urządzeń (będą się gryzły)?
    Rozumiem też, że Atmel dostarcza swojego sterownika wirtualnego prostu szeregowego (i innych trybów USB też) i ja już w tym grzebać nie muszę - na kompie mam normalny port COM, tak?
    Ten sterownik jest częścią Atmel Software Framework, Atmel Studio, FLIP, czy może jest jeszcze gdzieś indziej?

    A wiesz może, ile realnie kosztuje takie członkostwo w USB? To pewnie nie jest dla zwykłych śmiertelników?

  • #6 28 Kwi 2015 21:06
    Marek_Skalski
    Poziom 33  

    Mam wrażenie, że nie wiesz jak działa USB, ani czym są numery VID i PID.
    Atmel dostarcza driver portu szeregowego, który mówi systemowi tylko tyle, że urządzenie o pewnym VID i PID to jest urządzenie usb klasy VCP czy inne CDC. Szczegóły znajdziesz na przykład tutaj: http://www.atmel.com/Images/doc8447.pdf
    Jeżeli chcesz korzystać z logo USB oraz legalnie korzystać z VID, to opłata wynosi 3500 USD. Tutaj szczegóły: http://www.usb.org/developers/logo_license/
    Jeżeli chcesz dołączyć do grupy firm rozwijających standard, to opłata wynosi 4000 USD/rok. Wtedy masz bezpłatny VID, opłata za logo zostaje zniesiona, masz też kilka innych przywilejów. Tutaj źródło: https://www.usb.org/members_landing#howtojoin
    Aby na produkcie mogło pojawić się logo USB, to nie tylko musisz zapłacić za VID + logo, ale musisz też pozytywnie zaliczyć testy zgodności.

    Proponuję, zrób najpierw prototyp, przetestuj, przygotuj kolejną wersję, przetestuj i zobacz czy nadal jest potencjalny rynek na Twój produkt. Jeżeli 5000 USD jest dla Ciebie kwotą absurdalną, to raczej nie jesteś gotowy na sprzedaż komercyjną. Sprawdź też czy w Chinach tego nie produkują. Tak, dla pewności.

  • #7 28 Kwi 2015 21:08
    tmf
    Moderator Mikrokontrolery Projektowanie

    Sterownik jest już w systemie operacyjnym, to co dostarcza Atmel to podpisany plik inf, informujący OS, że jak napotka określoną kombinację VID/PID to ma to traktować jako urządzenie CDC i wczytać sterownik wirtualnego portu szeregowego. Podobny problem jest z FT232 - nie mając swoich numerów bazujesz na tych z FTDI, czyli nie masz gwarancji unikalności. W efekcie jeśli do kompa podłączonych jest parę urządzeń z FT232 to mogą się gryźć - problem obchodzi się wprowadzając dodatkową identyfikację na podstawie nazwy urządzenia zwróconej w deskryptorze - nazwa jest unikalna i nadawana wg uznania przez programistę.
    A członkostwo w USB to raczej nie pieniądze dla śmiertelnika/hobbysty, kwota, która się pojawiła rzędu kilku tys. $ jest realna, ale ostatnio sprawdzałem to jakieś 2 lata temu. Jak pisałem są firmy, które niezgodnie z licencją USB odsprzedają subpule identyfikatorów, wtedy cena jest do przełknięcia. Ale konsorcjum USB się od tego odcina i ciągle nie masz prawa używania loga USB.

  • #8 29 Kwi 2015 02:45
    MateuszW_
    Poziom 7  

    Marek_Skalski napisał:
    Mam wrażenie, że nie wiesz jak działa USB, ani czym są numery VID i PID.

    Niestety masz rację. Z tego też powodu chciałbym skorzystać z wirtualnego portu szeregowego, aby nie zagłębiać się zbytnio w samo USB. Komunikację w ten sposób mam już opanowaną, mam kod na PCta - działało to dotychczas na konwerterze FT232. Połączenie z PC nie musi być jakieś bardzo szybkie, w zupełności wystarczają tu możliwości portu szeregowego, choć wiem, że nie jest to rozwiązanie idealne, np użytkownik musi się bawić w numery COM, z którymi ogarnięciem sam mam czasem problem.
    Chciałbym zacząć z wirtualnym portem szeregowym i może z czasem opanować samo USB i wtedy zmienić sposób komunikacji.
    Marek_Skalski napisał:
    Proponuję, zrób najpierw prototyp, przetestuj, przygotuj kolejną wersję, przetestuj i zobacz czy nadal jest potencjalny rynek na Twój produkt. Jeżeli 5000 USD jest dla Ciebie kwotą absurdalną, to raczej nie jesteś gotowy na sprzedaż komercyjną. Sprawdź też czy w Chinach tego nie produkują. Tak, dla pewności.

    Moje urządzenie ma trafić na dość specyficzny i niewielki rynek - akcesorii astronomicznych. Jest tutaj wiele firm "lokalnych" tworzonych przez pojedyncze osoby, czyli podobnego typu, jak sam zamierzam stworzyć. Tutaj nawet "poważne"/duże firmy robią urządzenia na poziomie spokojnie osiągalnym przez hobbistę, a w cenie znacznie wyższej, niż nakazuje zdrowy rozsądek. Dlatego też mam nadzieję, że na mój produkt będzie zainteresowanie. W astronomii w zasadzie cały czas wszyscy bazują na wirtualnym porcie szeregowym, a czasem nawet na fizycznym RS232. Jest to wiec technologiczne dość zacofane.
    Trudno określić, jakie będzie zainteresowanie moim produktem. Szacuję, że maksymalnie będzie to kilka sztuk na miesiąc, minimalnie kilka na rok (przy cenie urządzenia rzędu kilkuset zł). Nie będzie z tego dużych kokosów, wiec taka jednorazowa opłata dla USB pochłonęła by zyski z wielu lat, a ta ciągła opłata co roczna spowodowałaby już nieopłacalność całości.

    Dziękuję wam za informacje, coraz bardziej mi się to rozjaśnia. Mam jeszcze jedno pytanie. Bo rozumiem, że VID/PID (np kamery internetowej) jest przypisane do jakiegoś modelu urządzenia, ale jest takie samo dla każdego egzemplarza, tak? No bo i tak każdy egzemplarz używa tego samego sterownika. Nie ma tu żadnych konfliktów?
    O ile w przypadku Atmela rozumiem, że ich uniwersalny VID/PID może być problemem (bo wiele urządzeń Atmela może używać potencjalnie różnych sterowników), o tyle nie widzę, gdzie miałby być problem z FT232. Przecież każdy FT232 używa tego samego sterownika - wirtualnego portu szeregowego, więc wiele urządzeń może mieć ten sam numer. A identyfikacja urządzenia spada już w zasadzie na użytkownika - to on musi wskazać port COM.
    Chyba, że da się odczytać nazwę z deskryptora i skojarzyć ją z nr COM, tak aby użytkownik nie musiał się tym zajmować?

  • #9 29 Kwi 2015 09:53
    kamyczek
    Poziom 33  

    FTDI kolego tmf się nie gryzą , bo podczas enumeracji układy dostają unikalne adresy , a system operacyjny przydziela im kolejny wolny port wirtualny więc jedyne co trzeba zrobić to przydzielić urządzeniu odpowiedni port com . W większości przypadków w amatorskich rozwiązaniach stosuje się FTDI lub inne podobne funkcjonalnie układy bo zwalnia to programistę z konieczności obsługo USB po stronie urządzenia mamy uarta i tak samo do uarta odnosimy się po stronie komputera resztę załatwia FTDI i sterownik .

  • #10 29 Kwi 2015 12:33
    tmf
    Moderator Mikrokontrolery Projektowanie

    kamyczek napisał:
    FTDI kolego tmf się nie gryzą , bo podczas enumeracji układy dostają unikalne adresy , a system operacyjny przydziela im kolejny wolny port wirtualny więc jedyne co trzeba zrobić to przydzielić urządzeniu odpowiedni port com . W większości przypadków w amatorskich rozwiązaniach stosuje się FTDI lub inne podobne funkcjonalnie układy bo zwalnia to programistę z konieczności obsługo USB po stronie urządzenia mamy uarta i tak samo do uarta odnosimy się po stronie komputera resztę załatwia FTDI i sterownik .


    Dostają unikalne identyfikatory urządzenia USB, jak każde urządzenie. Lecz to na aplikacji ciąży wtedy określenie czym tak naprawdę jest dane urządzenie. Albo robi się to przez wybór wirtualnego portu COM, albo, załadowanie biblioteki FT2DXX i konfigurację urządzenia przez tą bibliotekę na podstawie unikalnego deskryptora - stringu zawierającego nazwę urządzenia i producenta. Problem w tym, że spoczywa to na odpowiednio napisanej aplikacji. Jeśli aplikacja jest skopana to podłączenie więcej niż jednego urządzenia FTDI ją wysypie, podobnie jak wybór niewłaściwego portu. Generalna idea USB nie polega na tym, żeby coś ręcznie konfigurować, chociażby wybierając port COM w przypadku VCP. Ma się wszystko dziać samo, a do tego potrzebny jest własny VID/PID lub obejścia jakie proponuje FTDI. Porządnie napisana aplikacja powinna sama rozpoznawać i komunikować się z urządzeniem. Wiele aplikacji wykorzystujących FTDI o nic użytkownika nie pyta - po prostu wyszukują kompatybilne urządzenie po VID/PID lub w przypadku współdzielenia VID/PID po dodatkowych stringach - np. VendorID. Tyle tylko, że te pola nie podlegają rejestracji i każdy sobie może je używać jak chce.

  • #11 29 Kwi 2015 13:10
    kamyczek
    Poziom 33  

    W zasadzie Atmel może udawać każde urządzenie w zależności od tego jak się przedstawi w magistrali USB w taki sposób może użyć dowolnego podpisanego cyfrowo sterownika którego funkcje nam odpowiadają FTDI , cypress , Atmel czy insze dziadostwo .)

  • #12 29 Kwi 2015 14:06
    tmf
    Moderator Mikrokontrolery Projektowanie

    Oczywiście, że może, tyle, że nie jest to legalne. A mówimy o produkcie komercyjnym. Dla urządzeń budowanych dla siebie możemy sobie te numery wziąć z kosmosu, ale jak wprowadzamy na rynek to już niekoniecznie.

  • #13 07 Maj 2015 22:50
    MateuszW_
    Poziom 7  

    Witajcie
    Jestem już blisko zrobienia komunikacji po USB, ale na drodze stanął mi głupi problem. Otóż kupiłem taki moduł: http://www.leon-instruments.pl/2013/03/x3-dil64.html z XMEGA128A3U, która ma już wgrany bootloader. Podłączam do USB, windows zaczyna instalować sterowniki, stwierdza, że znalazł, ale instalacja kończy się niepowodzeniem. W menedżerze urządzenie ma wykrzyknik, a we właściwościach jest tekst: Zainstaluj ponownie sterowniki dla tego urządzenia. (Kod 18). No to klikam aktualizuj sterownik, wybieram folder usb w plikach programu FLIP i windows stwierdza, że: "oprogramowanie sterownika dla tego urządzenia jest aktualne".
    Oczywiście chodzi mi na razie o sterowniki do komunikacji z bootloaderem. Na razie nie robiłem niczego z własną komunikacją po USB.

    Co robić?

    Edit:
    Przepraszam, że zawracałem głowę. Problem rozwiązany. Okazuje się, że na kompie musiał być jakiś sterownik niedziałający, który się chciał instalować i nie pozwalał na zainstalowanie dobrego. Po usunięciu sterownika (zaznaczeniu opcji usuń przy odinstalowywaniu) mogłem wreszcie zainstalować sterownik z folderu FLIP. Nie mam pojęcia skąd się wzięło to niedziałające dziwadło, ani gdzie było.

  • #14 13 Maj 2015 23:56
    MateuszW_
    Poziom 7  

    Witajcie
    Próbuję własnie odpalić to USB na tym module: http://www.leon-instruments.pl/2013/03/x3-dil64.html i nie mogę sobie poradzić.
    Oczywiście przykład z: http://mikrokontrolery.blogspot.com/2011/03/X...emulacja-portu-szeregowego-rs-232-na-USB.html działa bez zarzutu, ale miałem problemy z dodaniem do tego projektu innych potrzebnych mi rzeczy (biblioteki do TWI z ASF), kompilator sypał dziwacznymi błędami. Prawdopodobnie problem jest w tym "okrojeniu" biblioteki, o którym pisze autor, które powoduje jakieś niekompatybilności z innymi modułami ASF.

    Tak więc postanowiłem użyć zwykłej biblioteki do USB, tej oryginalnej z ASF. No i nie mogę doprowadzić kodu ko kompilującej się postaci. Zrobiłęm wszystko dokładnie wg tej instrukcji: http://asf.atmel.com/docs/3.23.1/xmegaau/html/udi_cdc_quickstart.html..
    Dodałem moduł USB Device (service) cdc, oraz utworzyłem pliki board na podstawie szablonu (ASF krzyczał). Zmieniłem konfigurację zegara i USB, wg wskazówek w instrukcji.
    No i coś mu nie pasuje w deklaracji funkcji w pliku conf_usb.h:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    Rzuca błąd:
    Cytat:
    Error 2 expected '=', ',', ';', 'asm' or '__attribute__' before 'extern'

    Nie mam pojęcia o co mu chodzi. Będę niezmiernie wdzięczny za pomoc, bo już udało mi się odpalić TWI, ale nie umiem go połączyć z obsługa USB. Mam jedno albo drugie.
    W załączniku przesyłam cały projekt Atmel Studio.[/code]

  • #16 14 Maj 2015 18:28
    MateuszW_
    Poziom 7  

    Też tak myślę, ale cały kod, który zmieniałem, był zmieniany na podstawie tego przewodnika i nie widzę żadnego miejsca, które mogłoby być niepoprawne. To musi być coś specyficznego dla tej biblioteki, a nie jakiś prosty błąd składniowy moim zdaniem. Dlatego też wysłałem cały projekt, może znajdziesz chwilkę i spróbujesz go przeglądnąć. Byłbym bardzo wdzięczny, bo to zapewne głupota, której nie mogę zauważyć. Ten projekt to w zasadzie zaimportowane moduły ASF i zmiany tam, gdzie mówi instrukcja. Żadnego mojego kodu.

  • #17 26 Maj 2015 20:35
    MateuszW_
    Poziom 7  

    Ok, uporałem się jakoś z tym projektem, tak że wreszcie działa. W końcu użyłem tego gotowego przykładu: http://mikrokontrolery.blogspot.com/2011/03/X...emulacja-portu-szeregowego-rs-232-na-USB.html i jakoś "ręcznie" dodałem biblioteki ASF od TWI. Było kilka niezgodności, ale się z tym uporałem.

    Tak więc program działa i wymienia dane z kompem. Mam jednak inny problem. Na razie działa prymitywna komunikacja w głownej pętli programu polegająca na użyciu funkcji udi_cdc_getc oraz udi_cdc_putc, a więc takich, które czekają na możliwość odbioru, czy wysyłu danych. Jest to zdecydowanie zły pomysł, bo program ma docelowo robić wiele rzeczy "na raz", a tutaj komunikacja go blokuje.

    W poprzedniej wersji projektu, opartej na ATmega16 używałem interfejsu USART i konwertera FTDI na USB. Miałem tam mniej więcej taki kod, który działał na przerwaniach i spisywał się świetnie:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Teraz chciałbym ten kod przenieść do wirtualnego portu szeregowego w Xmega.
    W pliku konfiguracyjnym są dostępne definicje:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Którym mogę przypisać swoje funkcje. Wydawało mi się, że są to funkcje, które "symulują" klasyczne przerwania od odbioru i wysłania danych w sprzętowym USART. Jednakże po umieszczeniu tam (odpowiednio zmodyfikowanego) starego kodu całość nie działa poprawnie. Mam też wątpliwość co do UDI_CDC_TX_EMPTY_NOTIFY. Czy przypisana tu funcja będzie uruchamiana bez przerwy, gdy bufor do wysyłania jest pusty? To chyba trochę bez sensu, bo nie ma tu możliwosć zablokowania tego "przerwania", a bez tego ta funkcja będzie wołana bez przerwy i zablokuje cały program.
    Kod wirutualnego protu z tego, co zrozumiałem buforuje dane, wiec mógłbym teoretycznie wysłać od razu całą ramkę (5 bajtów). Ale czy mogę to zrobić od razu w funkcji przypisanej do UDI_CDC_RX_NOTIFY, czy ta funkcja nie musi się najpierw zakończyć, żeby wszystko działało?

    Byłbym bardzo wdzięczny za wyjaśnienie, jak tych funkcji użyć, albo jak to zrobić w inny sposób. Cały mój problem polega na tym, że wirtualny port nie posiada klasycznych przerwań, no bo jest wirtualny i ich posiadać nie może. Ale może kombinuję w dobrym kierunku z tymi funkcjami.
    W każdym razie opis w dokumentacji atmela do CDC niczego sensownego mi nie mówi.

  • #18 26 Maj 2015 20:42
    tmf
    Moderator Mikrokontrolery Projektowanie

    Ale dokumentacja ASF już mówi wszystko. A jak masz wątpliwości to zajrzyj do wspomnianych funkcji wysyłających i odbierających bajty. Implementacja CDC Atmela oparat jest o bufory i przerwania, więc bez problemu można zrobić nieblokującą obsługę. Zajrzyj do kodu źródłowego, a szybko zrozumiesz jak to działa.

  • #19 26 Maj 2015 22:23
    MateuszW_
    Poziom 7  

    tmf napisał:
    Ale dokumentacja ASF już mówi wszystko.

    Jeśli mówimy o tym: http://asf.atmel.com/docs/3.23.1/xmegaau/html...roup.html#ga64d9a6a6c3404b2d7362ced2d36fe7b0,, to nie umiem tam znaleźć niczego wiecej, niż jednozdaniowe opisy funkcji, które niewiele mi mówią. A o UDI_CDC_RX_NOTIFY(port) i UDI_CDC_TX_EMPTY_NOTIFY(port) już ani słowa tam nie ma.
    Zobaczyłem na źródła, ale nie mogę tego za bardzo rozgryźć - strasznie to skomplikowane.

    Dodano po 11 [minuty]:

    Nie mogę zrozumieć, czemu próba odebrania danych w UDI_CDC_RX_NOTIFY (a dokładniej w funkcji uart_rx_notify) skutkuje zawieszeniem się terminala na komputerze. Czy to nie jest własnie właściwe miejsce do odbierania danych? Pierwszą rzeczą, którą robię w tym miejscu jest użycie funkcji udi_cdc_get_nb_received_data. I wychodzi na to, że program wchodzi do uart_rx_notify, ale zawiesza się na udi_cdc_get_nb_received_data.

  • #20 12 Cze 2015 01:38
    MateuszW_
    Poziom 7  

    Mam kolejny problem. Otóż bardzo nie lubię, jak nie panuję nad swoim programem, ale tak niestety jest w wypadku obsługi USB - biblioteka jest zbyt skomplikowana, żebym ją ogarnął. Dlatego też muszę jej zaufać.
    No i nie mam pojęcia, co się dzieje z zegarem procesora. W pliku konfiguracyjnym jest taki fragment:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    Z tego, co wiem, to w Xmega są następujące sygnały zegarowe: CLKper4, CLKper2, CLKper i CLKcpu.
    Pierwsze pytanie: co to jest CLKsys?
    Drugie pytanie: z którego sygnału taktowane jest USB?
    Trzecie pytanie: Jakim cudem wybrany RC32MHz wytwarza 48MHz (o ile tyle wytwarza), skoro nie jest tu używany PLL (przynajmniej tak sądzę po analizie funkcji sysclk_init() uruchamianej w mainie)?
    Czwarte pytanie: jaka jest w końcu częstotliwość taktowania CPU i całej reszty?

    Ja tam widzę tylko wybranie źródła 32MHz i pierwszego preskalera na 2, czyli powinno być 16MHz.

    Coś z tym zegarem jest nie tak, bo jak próbowałem użyć licznika TCC0 w najprostszej konfiguracji, to po prostu stoi w miejscu. Wybrałem mu źródło zegara i nie odlicza. Po wywaleniu sysclk_init() licznik działa poprawnie. A wiec, co się dzieje w tej magicznej funkcji i jak te zegary są skonfigurowane?

  • #21 12 Cze 2015 02:18
    kamyczek
    Poziom 33  

    Niestety komunikacja po USB nie jest tak prosta jak w przypadku I2C czy SPI chcąc zrozumieć obsługę usb musisz sięgnąć po książkę opisującą komunikację USB , enumerację i różne rodzaje transferów jakie oferuje ten standard . Sygnał zegarowy 48MHz jest wymagany do uruchomienia USB i do jego wytworzenia używa się dostępnych źródeł sygnału zegarowego i pętli PLL .

  • #22 07 Kwi 2016 20:02
    WMKN2205
    Poziom 6  

    MateuszW_Napisał:

    Cytat:
    Z tego, co wiem, to w Xmega są następujące sygnały zegarowe: CLKper4, CLKper2, CLKper i CLKcpu.
    Pierwsze pytanie: co to jest CLKsys?
    Drugie pytanie: z którego sygnału taktowane jest USB?
    Trzecie pytanie: Jakim cudem wybrany RC32MHz wytwarza 48MHz (o ile tyle wytwarza), skoro nie jest tu używany PLL (przynajmniej tak sądzę po analizie funkcji sysclk_init() uruchamianej w mainie)?
    Czwarte pytanie: jaka jest w końcu częstotliwość taktowania CPU i całej reszty?


    Szukając rozwiązań swoich wątpliwości natrafiłem na możliwość ustawienia w rejestrze DFLLCTRL opcji dla 32MHz.....Calibration Reference: 0x02 "USB Start of Frame" co może tłumaczyć cud rozmnożenia 32MHz do 48MHz, więc CPU po podziale na 2 "CLK.PSCTRL.A"(SYSCLK_PSADIV_2) daje speed na poziomie 24MHz nie mam jednak na to zbitych dowodów bo mój program dalej nie działa (USART + 1-wire). Cała reszta to inna bajka.
    MateuszW_Napisał:
    Cytat:
    Oczywiście przykład z: http://mikrokontrolery.blogspo...szeregowego-rs-232-na-USB.html działa bez zarzutu, ale miałem problemy z dodaniem do tego projektu innych potrzebnych mi rzeczy (biblioteki do TWI z ASF), kompilator sypał dziwacznymi błędami. Prawdopodobnie problem jest w tym "okrojeniu" biblioteki, o którym pisze autor, które powoduje jakieś niekompatybilności z innymi modułami ASF.


    O ile pamiętam bo też przez to przechodziłem to były modyfikacje dotyczące rejestrów PR.PRGEN oraz PR.PRPA ... PRPF wyłączjące taktowanie peryferjów celem oszczędzania energii. Stosunkowo łatwo można to przeanalizować używając symulator wystarczy rozwijać podejrzane gałęzie rejestrów - analiza kodu ASF przynosi efekty jeśli szukamy konkretów ... lub mamy dużo czasu.
    Osobiście na start, zamiast adaptacji "rs-232-na-USB" na własne potrzeby polecam przykłady "ESP-PC.zip" i "ESP-ESP-PC.zip" niby inny temat ale ... TMF miej trochę litości :D dla Ciebie to chwila a My ślęczymy dni, tygodnie a może i lata.

  • #23 07 Kwi 2016 20:50
    tmf
    Moderator Mikrokontrolery Projektowanie

    Jakoś ominąłem ten wątek i nie zauważyłem, że pojawiły się kolejne odpowiedzi. Jeśli odpalimy USB, to potrzebny jest zegar 48 MHz (lub 12 MHz). Powstaje on z podkręconego zegara 32 MHz (wpisanie innych wartości kalibracyjnych dla generatora umożliwia jego przestrojenie z 32 na 48 MHz). Zegar jest stabilizowany ramkami USB. Ponieważ max dla rdzenia to 32 MHz, więc trzeba zastosować podział przez 2 i wtedy rdzeń jest taktowany zegarem 24 MHz. Oczywiście możemy przełączyć zegar systemowy (CLKsys) na inne źródło i wtedy nie będzie ograniczenia do 24 MHz. Można też (zasadniczo nie można, bo to poza specyfikacją) taktować CPU zegarem 48 MHz. Jedyne przy czym procesor mógłby się wysypać to zapis do EEPROM przy tym taktowaniu. W praktyce we wszystkich XMEGA jakiem miałem taktowanie 48 MHz nie sprawiało problemów. Dla zabawy robiłem taktowanie 66 MHz i też mi XMEGA działała, dopiero przy 68 MHz (136 MHz EBI) wysypywał mi się interfejs do pamięci zewnętrznej. Oczywiście trzeba na to patrzeć z przymróżeniem oka, nikogo nie namawiam do przekraczania specyfikacji producenta.
    W kodach przykładów ze strony mikrokontrolery blog (http://mikrokontrolery.blogspot.com/2011/03/Xmega-emulacja-portu-szeregowego-rs-232-na-USB.html) należy pamiętać, że wyłączają one inne peryferia poprzez rejestry kontroli poboru energii (PRGEN) i jeśli planujemy z nich skorzystać to należy zmodyfikować kod lub ponownie je włączyć. Ptrzy okazji warto się przyjrzeć przykładom, które są w artykułach dotyczących ESP8266, które realizują złożone urządzenia USB na XMEGA (dwa lub więcej portów szeregowych emulowanych na USB).
    Sama obsługa USB nie jest taka skomplikowana (w sensie programu obsługi). Kod USB można zmieścić w 2-3 kB, tak, że spokojnie mieści się np. w bootloaderze.

  • #24 08 Kwi 2016 00:12
    WMKN2205
    Poziom 6  

    TMF napisał:

    Cytat:
    W kodach przykładów ze strony mikrokontrolery blog (http://mikrokontrolery.blogspot.com/2011/03/Xmega-emulacja-portu-szeregowego-rs-232-na-USB.html) należy pamiętać, że wyłączają one inne peryferia poprzez rejestry kontroli poboru energii (PRGEN) i jeśli planujemy z nich skorzystać to należy zmodyfikować kod lub ponownie je włączyć.

    Właśnie o tym pisałem, może drobna korekta, ostrzeżenie na stornie pomoże zaczynającym przygodę z Xmegą, najczęściej odpalamy USB - hura. podłączmy jakieś led'y przyciski a tu - łeeee.
    Sam polecałem stronkę znajomym ostrzegając jednocześnie o czyhających niespodziankach. Wiem że to drobna sprawa no ale....
    Przykłady o ESP znajdą pewnie Ci co szukają ESP8266 (ja mam kilka) a szkoda bo ładnie demonstrują możliwości Xmegi. Siedzę sobie czytam coś tam o ESP a tu łał Xmega + USB i UART a może DWA? czemu nie cztery? więcej też się da

 
Promocja -20%
Zamknij 
Wyszukaj w ofercie 200 tys. produktów TME
tme