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

Jak zdekodować kod RC5 na At902323 do sterowania komputerem pilotem?

kopernik8 15 Kwi 2005 10:38 12229 37
Najlepsze odpowiedzi LABEL_AI_GENERATED

Jak zdekodować RC5 na mikrokontrolerze AVR, żeby uruchamiać komputer pilotem?

Najprościej zrobisz to przez przerwanie od wejścia z odbiornika IR i pomiar odstępów czasowych między zboczami timerem, zamiast odpytywać pin co stały interwał. W praktyce warto oprzeć się na notach Atmela AVR410 i AVR415 oraz opisie standardu RC5 / układu SAA3010, bo tam są podane czasy graniczne i zasada rozpoznawania bitów [#1407316][#1408253] Do synchronizacji trzeba uwzględnić bity AGC/start, bo bez tego część pilotów nie będzie działać poprawnie [#1409675][#1409741] Odbiornik TSOP1736 daje wyjście aktywne w stanie niskim, więc można go podłączyć do INTx i obsłużyć w przerwaniu, a potem sprawdzać kolejne bity ramki [#1409741][#1409389] W wątku pojawił się też działający dekoder RC5 w C dla AVR-GCC z obsługą przez przerwania; autor zwracał uwagę na poprawną częstotliwość kwarcu, parametr RC5SAMPLE i podłączenie TSOP1736 do INT1 [#1418113][#1419648]
Podsumowanie AI na podstawie dyskusji. Może zawierać błędy.
  • #1 1406912
    kopernik8
    Poziom 21  
    Posty: 631
    Pomógł: 10
    Ocena: 18
    Witam!
    Chcem zrobić mały układ na At902323 (nie 2313) który uruchomi kompa z pilota.
    Z tym że nie wiem jak sie zabrać do zdekodowania kodu RC5 ,z napisaniem programu nie ma problemu.
    Pisze w C.
  • #2 1407237
    PioTherm
    Poziom 16  
    Posty: 134
    Pomógł: 11
    Ocena: 19
    Jakbyś pisał w Bascomie, to podpowiedziałbym Ci bo rzecz jest banalna.
  • #3 1407316
    robson_s-ec
    Poziom 15  
    Posty: 98
    Pomógł: 7
    Ocena: 4
    PioTherm napisał:
    Jakbyś pisał w Bascomie, to podpowiedziałbym Ci bo rzecz jest banalna.

    Ja bym powiedział że nie jest, bascom na tym polu reprezentuje piękny wachlarz bugów. Zbiera sygnał z dowolnych pilotów i nie tylko. Wystarczyło że dotknąłem odbiornika palcem i już procedurka bascomowa dekodowala to jako rozkaz. Efektem tego była gorączka, nerwica, i ogólne pogorszenie samopoczucia.
    Anyway. Ściągnij noty katalogowe do SAA3010, ew jakies opisy do standardu RC5 i pisz wstawke w asmie. Nie proponowałbym pisac tego w C, pomimo ze AVR sa dość wydajne. Ale powinno sie dac napisac w C. Mierzysz czasy pomiędzy poszczególnymi przejściami z wyjśćia odbiornika i później porównujesz je z czasami granicznymi (p. datasheet SAA3010) czy to byla krutka czy długa przerewa.

    Proszę poprawić pisownię!
    Robak
  • #4 1407381
    pubus
    Poziom 30  
    Posty: 1289
    Pomógł: 139
    Ocena: 32
    A to dość ciekawie się składa...
    Jam mam problem z programem...
    Rzuć okiem na temat "Atmega8 RC5 i pilot od TV"...
    Sam odbiornik jest prosty jak konstrukcja cepa...
    Ja użyłem gotowego odbiornika TSOP1736...
    U mnie działa to tak jak na schemacie...
    Tylko z programem jest jakiś zonk...
    Reaguje prawidłowo na bit startu ale nie reaguje na kody...
    Jak by ci się chciało to zobacz program który wymonciłem...
    Może razem to jakoś rozkminimy...
    Aha dołożyłem jeszcze 6 LEDów na których można by sprawdzać czy dobrze dekoduje...
    Tzn zapalały by się w zależności od bitów komendy...
    Tu jest stronka o RC5 - http://www.ustr.net/infrared/index.shtml

    Daj znać co o tym myślisz...

    PS
    Opornik na rysunku ma 11k...
    Załączniki:
    • Jak zdekodować kod RC5 na At902323 do sterowania komputerem pilotem? IRDA.JPG (8.21 KB) Musisz być zalogowany, aby pobrać ten załącznik.
  • #5 1407551
    smalski
    Poziom 17  
    Posty: 317
    Pomógł: 2
    Ocena: 8
    Taka mala dygresja do robson_s-ec
    ...a ja mam wrecz przeciwne doswiadczenia jesli chodzi o Bascom i dekodowanie sygnalu z pilota podczerwieni. Napisalem w Bascomie program do dekodowaniu z pilota JVC bez zadnych wstawek asemblerowych i wszystko dziala do dzis pieknie a calosc kodu to zaledwie ok 30 linijek. Kiedys z ciekawosci pisalem do Kodu RC5 i tez dzialalo(nie uzywalem konstrukcji Getrc5). Jesli chodzi o C to nie wypowiem sie bo sie nie znam...
    Pozdro/smalski
  • #6 1407860
    kozak_sc
    Poziom 23  
    Posty: 752
    Pomógł: 25
    Ocena: 117
    moim zdaniem bascomowe getrc5 jest beznadziejne. bardzo czesto zawodne i nie nadaje sie absolutnie do do niczego moze poza jakimis zabawkami. w powaznych uzadzeniach gdzie jest potrzebna nbiezawodnosc basoma mozemy odrazu wyrzucic do kosza. i nierzako sie przekoanalem ze tak rzeczywiscie jest. bascoma uwazam za zabawke dla ludzi nie znajacych sie kompletnie na elektronice i programowaniu. wlasnie pisze program ktory odbiera dane z magistrali dcc i nie wyobrazam sobie tego piasaxc w bascomie bo bascom i pomiary czasu to juz kompletna bajka. a ze w rc5 czas tez ma duze znaczenie to podziekuje.
  • #8 1408253
    Nawigator
    Poziom 33  
    Posty: 1923
    Pomógł: 167
    Ocena: 160
    Rzut okiem na:
    http://www.atmel.com/dyn/products/app_notes.asp?family_id=607

    a w szczególności:

    Cytat:
    - AVR410: RC5 IR Remote Control Receiver (10 pages, revision B, updated 5/02) This Application Note describes a receiver for the frequently used Philips/Sony RC5 coding scheme

    - AVR415: RC5 IR Remote Control Transmitter (5 pages, revision A, updated 5/03) In this application note the widely used RC5 coding scheme from Philips will be described and a fully working remote control solution will be presented. This application will use the ATtiny28 AVR microcontroller for this purpose.

    powinno pomóc.

    Uwaga ogólna - wszystkie proceduru dotyczące dekodowania dowolnych kodów szeregowych lepiej od razu pisać w asemblerze niz potem szukać przyczyn błędnego działania.
    Pozdr. N.
  • #9 1408538
    kozak_sc
    Poziom 23  
    Posty: 752
    Pomógł: 25
    Ocena: 117
    nareszcie glos rozsadku sie odezwal. jak wogole pisac w bascomie to tylko ze wstawkami asm. ja jak bawilem sie bascomem zaczalem coraz wiecej wstawiac asm az w koncu calkiem przeszedlem na assemblera. bo to jest wedlug mnie dopiero wtajemniczenie w procki. a bascom to tylko i co najwyzej zabawa.
  • #10 1408979
    LordBlick
    VIP Zasłużony dla elektroda
    Posty: 5438
    Pomógł: 549
    Ocena: 69
    Dla mnie pisanie w asemblerze to bardzo pasjonująca zabawa, w dodatku dochodowa... ;) Mam całkowitą pewność, że jedyne błędy w programie to moje własne... ;)
    A co do RC5, to dużo do napisania nie ma, chyba, że przerobić na swoją modłę, np. obsługa przez ICP.
    Pozdrawiam, Light'I
  • #11 1409361
    kopernik8
    Poziom 21  
    Posty: 631
    Pomógł: 10
    Ocena: 18
    Czyli przy odczycie RC5 trzeba uzyc timera do odmierzania czasu i co 1.73(?)ms sprawdzać stan pinu?
  • #12 1409389
    LordBlick
    VIP Zasłużony dla elektroda
    Posty: 5438
    Pomógł: 549
    Ocena: 69
    kopernik8 napisał:
    Czyli przy odczycie RC5 trzeba uzyc timera do odmierzania czasu i co 1.73(?)ms sprawdzać stan pinu?
    Zdecydowanie szybciej, dla zachowania niskiego poziomu błędów. Poza tym bity AGC służą do dokładnego "wstrojenia się" w sygnał. Jeszcze zależy co używasz jako odbiornik.
    Light'I
  • #13 1409675
    kozak_sc
    Poziom 23  
    Posty: 752
    Pomógł: 25
    Ocena: 117
    ja mam napisany przez kumpla program do odbioru rc5 w asmie. niestety nie moge dostepnic bo kolega nie wyraza zgody. powiem tylko ze synchronizacja na podsawie bitow agc jest niezbeda inaczej polowa pilotow nie bedzie chodzic z nasza procedurka.
  • #14 1409741
    kaseihome
    Poziom 14  
    Posty: 74
    Pomógł: 4
    Ocena: 9
    Co do testu pinu w odstępach 1.72... to faktycznie powinno być to znacznie częściej, lecz jest inny pewniejszy sposób. Co prawda nie robiłem tego na tym µC ale na '51 daje dobre rezultaty, mianowicie wyjście odbiornika jest podłączone do pinu INT (w 2323 linia PB1), więc po odebraniu czegokolwiek, w dowolnym czasie startuje procedura przerwania i jeśli był to tylko fałszywy alarm to pomija to. Jak wiesz dwa piewsze bity z 14 to bity startu, bity adresu itd. Rozpiskę znajdziesz na stronie podanej przez PUBUS'a
    http://www.ustr.net/infrared/index.shtml

    Pozdrawiam
  • #15 1417759
    robson_s-ec
    Poziom 15  
    Posty: 98
    Pomógł: 7
    Ocena: 4
    Pubus dobrze ze zwrociles uwage swoim schematem na ten rezystor podciagajacy. Nawed w '51 musialem dac cos ok 7k4 bo bez tegojakos cienko dzialalo, a 2051 na INT0 ma pullup. Po dodaniu tego pullupa troche sie poprawilo ale, to jeszcze nie to (bascom).
    Nie moge znalesc tego topica, zreszta sa zrodla na stronce Atmela.
    Swoja droga kochany Atmel niezle promuje swoje AVR i to mi się podoba, ale mimo to jakoś wciąz pisze na stara '51. Ech!
  • #16 1418113
    Konto nie istnieje
    Konto nie istnieje  
  • #17 1418240
    kopernik8
    Poziom 21  
    Posty: 631
    Pomógł: 10
    Ocena: 18
    j0 <- Było by miłlo, bo z braku czasu musiałem zawiesić wszystkie badania nad tym :P
    pozdrawiam elektrodowiczów
  • #18 1419648
    Konto nie istnieje
    Konto nie istnieje  
  • #19 3117247
    migod
    Poziom 21  
    Posty: 462
    Pomógł: 29
    Ocena: 8
    Hej,

    odgrzewam temat.. czy jest szansa podpiąć wyjście TSOPa bezpośrednio do RX procesora (ATmega16L). Po drugiej stronie mam "pilota" na ATmega8L, z generatorem 36kHz na OC2 i diodą IR-LED wpiętą między OC2 i TX. Transmisję jaką chciałem osiągnąć to 2400 baud. Oba procesory pracują na wewn. RC.

    Jak zdekodować kod RC5 na At902323 do sterowania komputerem pilotem?


    Z doświadczenia to nie bardzo chce działać, tylko nie do końca wiem dlaczego.. Nie wiem, czy mam coś nie tak w kodzie (sprawdzałem już na piątą stronę..), czy to po prostu nie ma prawa działać z powodu hardware-u..?

    Z góry dzięki za podpowiedzi. Spędziłem już nad tym i googlami 3 dni bez powodzenia.. :|

    PS. na schemacie pilota jest oczywiście błąd, dioda IR powinna być do Tx (jest do Rx). Pilot mruga poprawnie w soczewce cyfrówki..

    pozdrawiam,
    --
    migod
  • #20 3117345
    euromatic
    Poziom 21  
    Posty: 422
    Pomógł: 17
    Ocena: 14
    może lepiej dodaj układzik NE555 i nim taktuj te 36kHz?
  • #21 3117411
    migod
    Poziom 21  
    Posty: 462
    Pomógł: 29
    Ocena: 8
    hehe.. zostawmy może tą dyskusję Bascom / C na boku.. niech każdy pisze w tym, w czym lubi i szanuje innych ;-)

    A wracając do tematu - w większości schematów odbiorników IR / RC5 spotkałem się z podpięciem odbiornika do INTx, a tylko w jednym projekcie zrealizowany był "bezprzewodowy" UART na IR-LED + TSOP1736 z podpięciem TSOP-a do Rx. Nie wiem, czy to sciema była, bo u mnie po 3 dniach walki to nadal nie działa..

    Przebiegi na OC2 w ATmega8L są prawie idealne (F_CPU=1Mhz, PRESCALER=1, 35.7 kHz), dioda 950nm, czyli zgodna z rekomendacją Vishay odnośnie TSOP-a.

    Będę wdzięczny za podpowiedź, czy to ma szansę działać.

    Dodano po 10 [minuty]:

    euromatic napisał:
    może lepiej dodaj układzik NE555 i nim taktuj te 36kHz?


    myślałem o tym, ale one (TSOPy) podobno mają pewną tolerancję, z wyliczeń wychodzi błąd f rzędu 0.8%, wtedy by miał mniejszy zasięg.. a póki co oba urządzenia się całkowicie nie widzą nawet z odległości 2-3 mm..

    Czy F to jedyna możliwość błędu? Korzystam ze standardowego UART, U2X = 1, 8N1, 2400baud, a generator to CTC na TIMER2 (multimetr wskazuje na OC2 falę ~36kHz).

    Fusy fabryczne.
  • #22 3117498
    euromatic
    Poziom 21  
    Posty: 422
    Pomógł: 17
    Ocena: 14
    Moim zdaniem poważnym błędem jest zassilenie diody IR z wyjścia procesora, jej moc nadawcza jest znikoma.
    daj kolego stopień wyjściowy taki jak w pilotach TV gdzie układ wyjściowy zapewnia mikrosekundowe impulsy o dużej energii ( prąd np. 3A) bo po co Ci układ przesyłu danych na odległość 5 cm? następnie podłącz oscyloskop po stronie odbiornika wi sprawdź jakość odbieranego sygnału. Może się także okazać , że trzeba będzie zanegować sygnał po odbiorniku.
    Osobiście bawiłem się kiedyś w przesyłanie po IR i miałem stabilne 2400, szybciej się nie dało ze względu na niską częstotliwość 36kHz.
    pozdrawiam
  • #23 3117987
    cikol
    Poziom 27  
    Posty: 983
    Pomógł: 61
    Ocena: 38
    zdecydowanie wstawił bym kwarce w obu atmegach.
  • #24 3118036
    euromatic
    Poziom 21  
    Posty: 422
    Pomógł: 17
    Ocena: 14
    Kolega Cikol ma absolutną rację, różnica prędkości na rezonatorach wewnętrznych może być czynnikiem decydującym o poprawnym odbiorze przez rs
  • #25 3118089
    migod
    Poziom 21  
    Posty: 462
    Pomógł: 29
    Ocena: 8
    W odbiorniku uruchomiłem kwarc 8Mhz, w nadajniki zaraz coś wymyślę (nie mam pod ręką kwarcu, który by się fajnie dzielił przez 72k).

    Jeśli zmienię medium transmisji z IR na kabelek między UART-ami - wszystko jest Ok. Czyli problem albo w modulacji, albo po stronie odbiornika. Faktycznie trzeba negować sygnał za TSOP?

    A, i jeszcze jedno - przed nawiązaniem transmisji robię 8-bitową rozbiegówkę (10101010b).
  • #26 3118244
    M. S.
    Poziom 34  
    Posty: 2107
    Pomógł: 259
    Ocena: 680
    A u mnie Bascomowe Getrc5 śmiga bez problemu na wewnętrznym generatorze 1MHz ATMEGI8. Muszę mieć słaby sygnał zegara i o małej częstotliwości bo inaczej słyszę uC w skanerze, którym on steruje. W końcu Bascom napisany jest w asm.
    Pozdrawiam wszystkich: profesjonalistów i amatorów.
  • #27 3118700
    migod
    Poziom 21  
    Posty: 462
    Pomógł: 29
    Ocena: 8
    Ok, kwarce dodane (nadajnik dostał 4MHz, odbiornik 8MHz). Nadajnik zrobiłem od nowa - diodę IR-LED wpiąłem bez opornika, świeci sporo mocniej.

    Oba UART-y przetestowane za pomocą PC (nadajnik poprawnie realizuje prosty program echo na Rx/Tx i tak samo z odbiornikiem). Oba poprawnie skonfigurowane na 2400baud.

    Multimetrem (nie mam niestety oscyloskopu) zmierzyłem przebiegi na OC2 w nadajniku - pokazuje 36.4kHz. OCR2 = 54, PRESCALER = 1, CTC.

    
    #define IR_TIMER2 54
        TCNT2 = 0;
        OCR2 = IR_TIMER2; 
        TCCR2 = _BV(WGM21) | _BV(COM20) | _BV(CS20);
    


    Prosty debug diodowy w odbiorniku pokazuje, że program "wisi" na operacji:
    
    int USART_Receive(void) {
      while ( !(UCSRA & _BV(RXC)) ) {};             /* Wait for data to be received */
      return UDR;                           /* Get and return received data from buffer */
    }
    

    czyli na odbiorze pojedynczej ramki danych.. :(

    Jak testuję: nadajnik wysyła poprzez UART co sekundę kod 0x20 (TIMER2 chodzi w nadajniku non-stop). Jeśli odbiornik (ATmega16L) cokolwiek zdekodował na Rx - dioda testowa zmienia kolor na przeciwny + uruchamia krótką zwłokę czasową, aby oko mogło to zobaczyć.

    Co jeszcze mogę sprawdzić lub inaczej testować?

    Odbiornik to TSOP1736, testowałem też z pilotami Sharp, Sony, Pace - bez rezultatu.

    PS. optymalizacje kodu typu -O3, -Os wyłączone
  • #28 3120401
    migod
    Poziom 21  
    Posty: 462
    Pomógł: 29
    Ocena: 8
    euromatic napisał:
    Może się także okazać , że trzeba będzie zanegować sygnał po odbiorniku.


    TSOP ma "Output active low", z czego wnioskuję, że stan "1" odpowiada LOW (chyba, że tutaj popełniam błąd. Nie jestem elektronikiem).

    Nie doszukałem się wprost podobnego sformułowania w dok. ATmega8/16, ale na diagramach START BIT = LOW, a IDLE = HIGH, więc chyba identycznie jak w przypadku TSOP. Czy zatem źle kombinuję, czy też inwerter nie jest konieczny..?

    PS. nadal nie działa :| please help.. :)
  • #29 3126771
    migod
    Poziom 21  
    Posty: 462
    Pomógł: 29
    Ocena: 8
    Dziękuję wszystkim za cenne wskazówki ;)

    Suma sumarum chodziło o zbyt niskie napięcie zasilania TSOPa. Dla nap. 4,8V śmiga jak głupie. Zasięg w całym pokoju. Odbija się od wszystkiego. Dioda IR zasilana wprost z portów ATmega8L napędzanego 4MHz. Napięcie zasilania nadajnika 5V. W odbiorniku stabilne 8MHz.

    Zgubiła mnie pierwsza tabelka w PDF Vishay-a dot. TSOP17xx, którą zinterpretowałem jako zakres napięciowy -0,3 ... 6V.

    Jeszcze raz dzięki!
  • #30 3171739
    marek_Łódź
    Poziom 36  
    Posty: 3103
    Pomógł: 208
    Ocena: 66
    Pomysłowe to sterowanie z OC2. Rozumiem, że na powyższym schemacie chodziło o podłączenie nadajnika do TX, nie do RX?

    Mimo wszystko podobnie jak ktoś w jednym z powyższych postów mam spore wątpliwości co do skuteczności układu nadajnika sterowanego poniżej 20mA (niezawodność transmisji?), ale skoro działa to pozostaje pogratulować..

Podsumowanie tematu

LABEL_AI_GENERATED
Dyskusja dotyczy implementacji dekodera kodu RC5 na mikrokontrolerze Atmel AT90S2323 (nie ATmega2313) do sterowania komputerem pilotem IR. Poruszono kwestie wyboru języka programowania – większość uczestników zaleca pisanie dekodera w asemblerze ze względu na precyzyjne pomiary czasów i niezawodność, choć niektórzy chwalą Bascom za prostotę, podkreślając jednak jego ograniczenia i błędy w dekodowaniu. Zalecane jest korzystanie z dokumentacji i not aplikacyjnych Atmela (np. AVR410) oraz standardu RC5, a także pomiar czasów między impulsami sygnału odbieranego z odbiornika IR (np. TSOP1736). Wskazano, że sygnał odbiornika powinien być podłączony do przerwania zewnętrznego (INTx) dla lepszej synchronizacji. Dyskutowano o konieczności stosowania rezystorów podciągających oraz o napięciu zasilania odbiornika TSOP, które powinno być stabilne i odpowiednio wysokie (np. 4,8 V), aby zapewnić odpowiedni zasięg i niezawodność. Wątek obejmował także problemy z transmisją IR między mikrokontrolerami, modulacją nośnej 36 kHz, oraz kwestie sprzętowe, takie jak zasilanie diody IR i stosowanie kwarców zamiast generatorów RC dla stabilności taktowania. Udostępniono przykładowy kod w C dla ATmega2313 z wykorzystaniem przerwań i odbiornika TSOP1736. Poruszono również temat dwukierunkowej komunikacji RC5, która jest możliwa, ale nie jednoczesna, oraz sugestie dotyczące separacji nośnych dla pełnego dupleksu. Na koniec wskazano projekt z obsługą RC5 w C dostępnym online.
Podsumowanie AI na podstawie dyskusji. Może zawierać błędy.
REKLAMA