Elektroda.pl
Elektroda.pl
X

Search our partners

Find the latest content on electronic components. Datasheets.com
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Odbiornik podczerwieni na ATmega8 jako myszka USB

10 Feb 2007 11:08 2156 1
  • Level 15  
    Pracuję właśnie nad takim projektem, aby kontrolować kursor myszki w kompie za pomocą pilota..
    Oprogramowałem odbiór/dekodowanie podczerwieni - działa.
    Oprogramowałem połączenie z PC tej myszki jako urządzenie klasy HID - działa.
    Niestety dwa w/w działają, ale tylko oddzielnie, tzn.:
    - testowanie podczerwieni na zasadzie migania diód (odbiór pakietu IR - jedna dioda, kod pasuje do zdefiniowanych w programie - druga dioda), oraz debugowania po RS do PC działa
    - testowanie połączenia z PC, z tym że do sterowania używam przycisków (kierunki + lewy/prawy przycisk myszy) - działa

    Mikroprocesor to ATmega8.
    Do komunikacji z PC używam sterownika AVR-USB (http://www.obdev.at/products/avrusb/index.html).

    Niestety nie mogę tego uruchomić razem..
    Host do urządzeń (nie wiem czy wszystkich, na pewno HID) co 1ms wysyła pakiet na który urządzenie musi odpowiedzieć z co najwyżej niewielkim opóźnieniem.. I urządzenie (sterownik AVR-USB) odpowiada, ale tylko do momentu jak nie zacznę nadawać doń pilotem.. W tym momencie uC zaczyna się 'gubić' w obsłudze przerwań i w końcu system wyłącza to moje urządzenie..
    Po (przydługawym ;) ) zapytaniu na forum AVR-USB (http://forums.obdev.at/viewtopic.php?t=243) dowiedziałem się, że pomogło by (fixme?) przepisanie moich przerwań od IR na ASM z sei jako pierwszym rozkazem.
    USB jest dołączone do INT0, natomiast moje przerwania to 'Input Capture 1' oraz 'Output Compare 1A' w timerze1, więc USB ma większy priorytet, ale z tego, co autor AVR-USB napisał w w/w wątku forum, może mi dochodzić do zapętlenia przerwań..
    Niestety to przerasta moją wiedzę na temat AVRów..
    Prawdopodobnie gotowca nie otrzymam ;), ale nakierujcie przynajmniej, co robię źle, o czym mam szczególnie poczytać w datasheecie czy innych notach..?

    Czy np ewentualnie (dziś na to wpadłem, stąd ten post w sumie częściowo :) ) zbudować to na dwóch uC (nawet tiny2313), jeden do podczerwieni, drugi do USB..? Przy tym najprawdopodobniej będzie mniej zabawy, szczególnie, że co najwyżej słabo znam ASMa (fixme?).. Jeśli takie rozwiązanie, to jaką komunikację proponujecie między procesorami? UART? Równolegle 8bitów używając jednego całego portu? Jeszcze inaczej..? Przerwania od UARTa raczej nie 'wykrzaczą' urządzonka z USB (fixme?)..

    Dzięki wielkie z góry!
    Tylko ten problem pozostał mi do pokonania.. :|

    PS Sorry for my english again ;)
    PPS Sorry za następny przydługawy post :)

    Pozdrawiam
    Krzysiek
    [Szkolenie 22.06.2021, g.9.00] Zabezpieczenia Internetu Rzeczy (IoT) programowe i sprzętowe. Zarejestruj się za darmo
  • Level 33  
    Witam,
    to co chcesz zrobić wymaga moim zdaniem 2 procesorów, bo obydwa procesy są czasowo zależne, a zwłaszcza usb. Procesor jest zajęty kontrolą odbioru pakietów i jak opisuje ciekawy artykuł o destuffigu nie należy mu w tym przeszkadzać. sei w przerwaniu to tzw. zagnieżdżone przerwanie, bardzo ryzykowne i moim zdaniem nie do stosowania w C, bo nie ogarniesz opóźnień tworzonych potrzeba czy nie przez kompilatory. Ja gdybym się zabierał do tworzenia modułu usb to tylko w asemblerze a nie tracił czasu na dociekanie co jakiś obcy programista C zrobi z moimi rejestrami, moimi przerwaniami i moim stosem.
    Połącz oba procesory 8 liniami plus zgłoszenie odbioru albo uartem albo usi albo poczekaj aż Atmel wypuści wersję 24MHz.
    Pzdr. N.
pcbway logo