logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

ATmega16 - Odbiór RC5 - za każdym razem inne dane

maly_elektronik 06 Wrz 2013 09:33 1848 11
REKLAMA
  • #1 12706866
    maly_elektronik
    Poziom 23  
    Witam,
    od jakiegoś czasu próbuję rozwiązać problem odbierania kodu RC5 przez avr'ka.
    Ponieważ nie jestem do końca pewny zbudowałem (a raczej zaprogramowałem) prosty nadajnik tego kodu.
    Tak wygląda kod odbiornika:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    a tak kod nadajnika (wiem że delay'e nie są zbyt dobrym rozwiązaniem jednak w tej sytuacji są wystarczające)
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Czy ktoś jest w stanie powiedzieć mi co jest nie tak?[/code]
  • REKLAMA
  • Pomocny post
    #2 12706893
    BlueDraco
    Specjalista - Mikrokontrolery
    Popatrz uważnie na kod nadajnika - nadajesz 14 impulsów z okresem ok. 3.6 ms. Czy o to chodziło?

    Zwykle sterowanie w podczerwieni działa na 38 kHz (lub coś podobnego) - u Ciebie jest ok. 270 Hz
  • #3 12706928
    maly_elektronik
    Poziom 23  
    Rzeczywiście w samym nadajniku zapomniałem o nośnej jednak przyczyną tego jest to iż zamiast diody i odbiornika podczerwieni do testów spiąłem ze sobą pin nadajnika i odbiornika (oczywiście uwspólniając zasilanie) :idea: Jednak zapomniałem o tym że w pętli mam 2 "bity" kodu więc wysyłam za dużo danych :)

    A czy sam kod odbiornika jest poprawny?
  • REKLAMA
  • Pomocny post
    #4 12707666
    piotrva
    VIP Zasłużony dla elektroda
    Pokaż jeszcze schemat odbiornika.
    Na pierwszy rzut oka w ogóle masz to jakoś dziwnie zrobione - poprzez polling pinu odbiorczego?
    Poszukaj w sieci - są bardzo dobre przykłady w oparciu o tryb Capture Timera1.
  • REKLAMA
  • #5 12707935
    maly_elektronik
    Poziom 23  
    W sieci też spotkałem rozwiązania tego typu, że sprawdzany był stan pinu w przerwaniu od timera po wykryciu zbocza bitów startowych :)
    Możesz napisać jaśniej o co chodziło Ci z tym trybem CTC, wtedy będzie mi prościej to zaimplementować :)
  • #6 12708034
    piotrva
    VIP Zasłużony dla elektroda
    Nie CTC, ale ICP - dzięki temu w sprzętowy sposób mierzymy długość impulsów.
  • #7 12708215
    maly_elektronik
    Poziom 23  
    Rozważałem taką opcję, jednak ICP posiada jedynie timer 16bitowy a niestety ten będzie pełnił rolę generatora PWM w finalnym układzie :(
  • #8 12708894
    piotrva
    VIP Zasłużony dla elektroda
    W takim razie rozwiąż to inaczej - skonfiguruj przerwanie zewnętrzne tak, aby było wyzwalane zmianą stanu i osiągnij ten efekt w ten sposób - polling pinu to w tym przypadku moim zdaniem nie jest najlepsze rozwiązanie.
  • REKLAMA
  • #9 12709115
    maly_elektronik
    Poziom 23  
    Teraz zrobiłem według Twoich zaleceń:
    Przerwanie wywołuje zmiana stanu pinu INT0 na przeciwny, rusza timer który w równych odstępach czasu przepisuje wartość pcode (odpowiada stanowi pinu INT0) do CODE, który jest kodem "klawisza" przed zdekodowaniem modulacji MENCHESTER.
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod


    Jednak w dalszym ciągu odebrane dane są niepoprawne (za każdym razem inne - nie używam jednak pilota z RC5 a jedynie układ który generuje prosty sygnał)
    Tak wygląda mój pilot:
    [Timer generuje przerwanie z częstotliwością ok 72kHz zmieniając stan pinu OC2 (przez co uzyskuje nośną 36kHz i odpowiedni wewnątrz przerwania wyliczam sobie co ile przerwań należy modulować nośną)]
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod
  • #10 12709758
    BlueDraco
    Specjalista - Mikrokontrolery
    Przerwania z częstotliwością 72 kHz na AVR to zbytni optymizm. Zaprogramuj timer w tryb PWM na 38 kHz, w obsłudze przerwania odliczaj impulsy i włączaj/wyłączaj sterowanie diodą na kolejny okres - jeśli oprogramujes to przyzwoicie - masz szansę się wyrobić. Ustaw zegar procesora na min. 8 MHz (nie napisałeś, jaki masz ustawiony).
  • #11 12709830
    maly_elektronik
    Poziom 23  
    Pracuje na zewnwtrznym kwarcu 16MHz. Czyli jednak kod pilota jest niezbyt poprawny?

    Odświeżając temat:
    Tak wyglądają przebiegi (stany logiczne) diody nadawczej oraz odbiornika TSOP4836.
    [Pierwszy to sygnał z diody IRED natomiast drugi na odbiorniku]
    ATmega16 - Odbiór RC5 - za każdym razem inne dane
    Jak sprawdziłem w programie mój "pilot" nadaje poprawny kod wraz z poprawną nośną (ok 36kHz), jednak jak widać na załączonym zrzucie sygnał zaobserwowany na pinie odbiornika jest poprawny gdyny nie "szpilki" trwające ok. 27us.
    Co może być ich powodem? (układ podłączony wg zaleceń czyli rezystor do Vcc oraz kondensator na pinach zasilających TSOP)
  • #12 12741223
    maly_elektronik
    Poziom 23  
    Temat do zamknięcia.
    Po podpięciu innego odbiornika TSOP okazalo się ze te szpilki powstawały wyłącznie z winy wadliwego poprzednika.
    Dziękuje wszystkim za pomoc :)
REKLAMA