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

[Atmega32][ASM] odbieranie wiadomości w RC5

marcinxat 14 Gru 2008 13:50 2565 9
REKLAMA
  • #1 5857427
    marcinxat
    Poziom 11  
    witam

    Temat być może jest trochę mylący. Ale do rzeczy. Bawię się zestawem zl3avr i jestem na etapie obsługi transmisji w kodzie RC5 w asemblerze. W książce "Mikrokontrolery AVR ATmega w praktyce" podane są gotowe programy do nadawania i odbierania wiadomości w RC5. O ile procedurka nadawania nie budzi żadnych moich wątpliwości, o ile w przypadku odbierania danych mam pewne pytania.

    Autor opisuje swój program następująco: "Jest to podprogram obsługi przerwania INT1, wywoływany przez opadające zbocze zdemodulowanego sygnału odbieranego (do końcówki INT1 dołączone jest wyjście odbiornika IR).W związku z tym, że układ zegarowy pilotów jest mało dokładny konieczna jest jego ciągła synchronizacja z nadajnikiem. W programie dokonuje się tego poprzez oczekiwanie na środkowe zbocza, występujące przy transmisji każdego bitu. Tu zachodzi zawsze zmiana z 1 na 0 lub z 0 na 1.
    Fakt wykrycia zbocza środkowego (poczynając od pierwszego bitu startu) autor wykorzystał do zerowania układu licznikowego (8-bitowego licznika 2 w trybie CTC), wykorzystywanego jako czasomierz. Licznik taki powinien odmierzać czas równy 3/4 okresu transmisji jednego bitu czyli 0,75*1,8ms (900us+900us=1,8ms czyli długość jednego bitu). W chwili jego przepełnienia stan sygnału odbieranego jest badany, ponieważ na jego podstawie określić można wartość kolejnego bitu (testowanie zachodzi w środku pierwszego półokresu jego transmisji). Następnie układ powinien oczekiwać na zbocze środkowe (co powinno trwać 1/4 okresu przesyłu bitu) i opisywana procedura powinna się powtarzać (z cykliczną synchronizacją pracy licznika) aż do chwili odebrania ostatniego bitu rozkazu. W przedstawionym podprogramie zachodzi również testowanie, czy nie przekroczono czasu oczekiwania na zbocze środkowe(także tutaj odmierzany jest dla wygody czas 3/4 okresu, choć teoretycznie powinien on wynosić o połowę mniej). Zdarzenie to oznacza, że wystąpił błąd- popdprogram zostaje wówczas zakończony. W przeciwnym razie przepisuje on odebraną wiadomość do odpowiednich zmiennych."

    1. W stanie "spoczynku" wejście INT1 od odbiornika IR jest w stanie wysokim bo wejście ma włączone podciąganie. Układ zareaguje na pierwsze zbocze opadające?
    2. Od kiedy odliczany jest pierwszy czas 3/4 okresu? Wydaje mi się że według podprogramu włączany licznik jest od razu po przejęciu przerwania. Ale jeśli tak to dalej mi się coś nie zgadza. Zgadzałoby się wszystko ażeby licznik zaczynał liczyć w momencie pierwszego zbocza rosnącego pierwszego bitu startu. Zresztą tak autor napisał w cytowanym wyżej opisie: "Fakt wykrycia zbocza środkowego (poczynając od pierwszego bitu startu) autor wykorzystał do zerowania układu licznikowego"
    3. Dlaczego odbierany jest dopiero drugi bit startu?

    W załączniku dołączyłem odpowiednie podprogramy.

    dzięki z góry
  • REKLAMA
  • #2 5858363
    asembler
    Poziom 32  
    nie moze byc drugi bit startu skoro pierwszy wystartował to drugi juz nie mozna nazwac startowym.
  • #3 5858531
    marcinxat
    Poziom 11  
    za bardzo nie zrozumiałem co masz na myśli; przecież pierwsze dwa bity to bity startu, a kolejny to bit T itd
  • REKLAMA
  • Pomocny post
    #4 5858682
    mirekk36
    Poziom 42  
    mogą być 2 bity startu, bo standard RC5 właśnie tak jest "skonstruowany", że posiada 2 bity startu. Natomiast jego rozszerzenie czyli RC6 wykorzytuje drugi bit startu jako normalny bit danych.

    Ok - teraz odpowiedź dla autora, wydaje mi się, że uda się to wyjaśnić bo sam kiedyś miałem podobny problem ze zrozumieniem tego etapu dekodowania.

    Cały problem z błędnym rozumieniem bierze się z tego, że z jednej strony myślenie zacząłeś od nadajnika i od pierwszego bitu startu, który jak wiadomo w nadajniku rozpoczyna się NARASTAJĄCYM zboczem a potem w środku ma opadające - prawda?

    ale po stronie odbiornika to już wygląda inaczej, wszystko jest zanegowane i jak sam wspomniałeś w stanie oczekiwania cały czas na wejściu INT jest stan wysoki prawda? ;) tak więc nie mamy jak wykryć momentu "początku" tego pierwszego bitu startowego - prawda? ;)

    .... i tu leży właśnie leży pies pogrzebany, dlatego też prawidłowe rozpoczęcie dekodowania RC5 rozpoczyna się od "środka" pierwszego bitu startu, dzięki czemu kolejny bit może już być w całości odebrany (pamiętamy tylko, że wszystko dalej też jest zanegowane w stosunku do nadawanego sygnału)

    oczywiście można do odbierania i dekodowania RC5 podejść jeszcze na nieco inne sposoby (jeśli chodzi o algorytm - ja np najchętniej do dekodowania używam wejścia ICP Timera)
  • REKLAMA
  • #5 5858850
    marcinxat
    Poziom 11  
    Za bardzo nie mogę zrozumieć dlaczego po stronie odbiornika wszystkie dane mają postać zanegowaną w stosunku do nadajnika.

    Nadajnik wysyła najpierw dwa bity startu w postaci 1 czyli 900us stan 0 i 900us stan 1 i kolejny w takiej samej postaci. To te bity nie dojdą w takiej samej postaci do odbiornika? Przecież postać wiadomości wygląda następująco:

    [Atmega32][ASM] odbieranie wiadomości w RC5
    pozdrawiam
  • #6 5858903
    asembler
    Poziom 32  
    nazywajcie to jak chcecie ale jak cos juz wystartuje jednym bitem to drugi bit nie moze byc juz startowym (nie ma sensu logicznie)Moze chodzi o zbocza a nie o bity?
  • REKLAMA
  • Pomocny post
    #7 5859402
    Dr.Vee
    VIP Zasłużony dla elektroda
    marcinxat napisał:
    Za bardzo nie mogę zrozumieć dlaczego po stronie odbiornika wszystkie dane mają postać zanegowaną w stosunku do nadajnika.

    Nie musi tak być - po prostu większość (wszystkie?) dostępne demodulatory podczerwieni w przypadku braku sygnału mają na wyjściu stan wysoki. Pojawienie się paczki impulsów generuje stan niski na wyjściu takiego odbiornika.

    Tu masz obrazek poglądowy:
    [Atmega32][ASM] odbieranie wiadomości w RC5

    assembler, po prostu dwa pierwsze bity są zawsze równe 1. Kwestia nazewnictwa - tak samo w RS-232 możesz mieć 1, 1,5 albo 2 bity stopu - niby też bez sensu, a jednak tak się przyjęło.

    Pozdrawiam,
    Dr.Vee
  • Pomocny post
    #8 5859664
    mirekk36
    Poziom 42  
    no teraz Dr.Vee tym obrazkiem animowanym to chyba bardzo dobitnie pokazał - dlaczego po drugiej stronie, czyli w odbiorniku wszystko jest zanegowane. Tak się po prostu przyjęło i tak się robi.

    i nawet nie ma sensu wyważać głową drzwi i próbować robić jakieś własne układy do sprzętowego odbioru, które będą jeszcze odwrotnie dawać sygnał na wyjściu bo po co? skoro można to już spokojnie w programie zrobić - a wystarczy tylko troszkę zmienić myślenie o odebrenym sygnale - właśnie jako o zanegowanym - to już żaden problem i żaden dodatkowy koszt
  • Pomocny post
    #9 5859844
    asembler
    Poziom 32  
    Co do programu przedstawionego w załączniku.
    Strasznie marnujesz czas procesora, powinienes w przerwaniu wykonac kilka instrukcji a ty wykonujesz wszystko. Uboczną stroną jest jescze to ze musisz zapisywac wykorzystywane rejestry na stosie i "uziemiasz sobie licznk 0"
    Proponowałbym taki sposób:
    czujnik dołaczasz do wejscia into lub int1 ustawiasz na wykrywanie zmiany na wejsciu. Puszczasz licznik dowolny bez zerowania. Oczywiscie trzeba dobrac odpowiednio preskaler.
    Musisz zadeklarowac nastepujące zmienne

    licznik bitow
    pamiec licznika
    adres
    kod
    licznik przepelnien

    Teraz zasada dzialania
    po przyjeciu przerwania od INT0 odejmujemy pamiec licznika od aktualnego stau np Counter 0. Porównujemy czy wynik jest wiekszy od 1.5 impulsu bazowego i na tej podstawie wykrywamy stan odebranego bitu notujemu od zmiennej ades lub kod w zaleznosci od stanu licznika bitów. zwiekszamy licznik bitów i zapisujemy aktualny stan np Counter0 zerujemy licznik przepelnien.
    Bity startowe jak zwał to zwał zaliczamy do adresu.

    w przerwaniu od np Counter 0 liczymy ilosc przepelnien jezeli ilosc przepelnien bedzie wieksza od 1 znaczy ze zostal odebrany kod i mozna go np zapisac do bufor lub od razu podjac akcje. jednoczesnie zerujemy wszystkie liczniki tak aby nastepne zbocze mogłobyc odczytane jako poczatek nastepnego kodu co zabewni synchronizacje.

    W tym przykladzie w kazdym z przerwan wykonasz kilkanascie +/- rozkazów. Jak widac na przykładzie nigdzie nie uzywam zadnych pętli opóźniających ani tez oczekujących.
    To by było na tyle.
    Długość impulsu bazowego wpisujesz jako stałą lub tez jak szerokość miedzy pierwszym a drugim zboczem odebranego sygnału.
  • #10 5860051
    marcinxat
    Poziom 11  
    no i wszystko jasne; a już myślałem że coś źle zrozumiałem działanie tego programu.

    do asembler: ten sposób obsługi zaproponowany przez autora książki służył mi jedynie do nauki asemblera, poznawania kolejnych jego tajników.

    Dzięki za algorytm. Kiedyś przetestuję.

    Wszystkim Wielkie dzięki za pomoc. Dokładnie o to mi chodziło.
REKLAMA