ATNEL tech-forum

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-19T12:18:15+01:00

andrews napisał(a):

... że procesor jest jak niefrasobliwa, rozrzutna żona, która pożycza, nie wiedząc, czy będzie z czego oddać.

no tego jeszcze nie słyszałem ! dobre

Statystyki: Napisane przez mirekk36 — 19 maja 2019, o 12:18

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-19T09:59:18+01:00

Dobrze, że jesteś dociekliwy i zadajesz pytania. Nie sposób jednak napisać takiej odpowiedzi (przynajmniej w formie postu na forum), aby zawierała całą wiedzę potrzebną do jej zrozumienia. Dlatego też, aby zrozumieć odpowiedź, należy już jakąś wiedzę i znajomość pewnych terminów posiadać. W innym przypadku odpowiedź na jedno pytanie rodzi kolejne pytania i tak w kółko.

Jeśli bardzo Ci zależy, żeby to dogłębnie zrozumieć, powinieneś najpierw poznać następujące tematy:

co to są pozycyjne systemy liczbowe
co to jest binarny system liczbowy,
jakie są sposoby reprezentacji liczb w systemie binarnym (przynajmniej liczby całkowite bez znaku, liczby całkowite ze znakiem, kod uzupełnień do 2),
w jaki sposób procesor (a konkretnie jego jednostka arytmetyczno-logiczna) wykonuje operacje arytmetyczne na liczbach binarnych,
jakie instrukcje asemblera dany procesor ma do realizacji takich obliczeń, jaki jest efekt ich działania i czym się od siebie różnią,
nie zaszkodziłoby też zapoznać się z terminem z dziedziny matematyki o nazwie odejmowanie modularne.

To dość obszerne tematy i nie sposób ich szczegółowych opisów zawrzeć w odpowiedzi. Niektóre z nich być może znasz, niektórych nie znasz, a niektóre znasz niezbyt dobrze. Wydaje mi się, że gdybyś znał dobrze wszystkie powyższe tematy, nie miałbyś problemu ze zrozumieniem mojego opisu (prawdopodobnie nawet nie musiałbyś zadawać tego pytania).

Myślę, że tymczasem wystarczyłoby, gdybyś rozumiał to tak (w dużym uproszczeniu), że procesor jest jak niefrasobliwa, rozrzutna żona, która pożycza, nie wiedząc, czy będzie z czego oddać. To mąż (czytaj: programista) musi się o to martwić. Kiedy więc procesor odejmuje liczbę większą od mniejszej (mowa o zmiennych uint16_t), najpierw pożycza sobie "jeszcze nie wiadomo skąd" 2^16 (czyli 2 do potęgi takiej, jak rozmiar zmiennej w bitach) i dodaje do mniejszej liczby. Dopiero później wykonuje operację odejmowania. Wynik oczywiście jest nieprawidłowy, bo zostajemy z debetem, którego nie mamy czym pokryć.

Jednak w przypadku timera, jeśli obecnie odczytana wartość wynosi przykładowo 200, a poprzednio odczytana wartość była większa i wynosiła przykładowo 64 200, to oznacza, że timer musiał się przepełnić. Jego faktyczna nowa wartość w rzeczywistości nie będzie więc wynosiła 200, tylko będzie większa o pojemność licznika, czyli o 2^16. Licznik doliczył bowiem do 65536 (2^16) i potem jeszcze do 200, jednak nie zostało to policzone, bo zabrakło bitów w liczniku/timerze. I to jest ta wartość, która dokładnie pokrywa nam debet przy odejmowaniu (200-64200), dzięki czemu w tym przypadku okazuje się, że wynik odejmowania liczby większej od mniejszej będzie prawidłowy, cnd. Należy przy tym pamiętać o pewnych ograniczeniach, o których pisałem wcześniej, pod koniec tego postu.

Lepiej już chyba nie potrafię. Jeśli nadal nie rozumiesz, zapoznaj się z tematyką podaną powyżej, a na pewno wszystko się rozjaśni. Ewentualnie może ktoś inny wytłumaczy Ci to lepiej.

Statystyki: Napisane przez andrews — 19 maja 2019, o 09:59

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-18T23:27:59+01:00

11jacekj napisał(a):

Tylko że ja jestem taki typ że będzie mnie to gryzło do puki nie zrozumiem tego, może nawet do "grobowej deski".

ale co cię będzie gryzło - jeśli dostałeś już wyjaśnienia.

Widzę że nadal nie rozumiesz jakby do czego są TYPY danych w C.

Po to m.in powołujesz zmienną uint16_t żeby kompilator właśnie dokonywał na niej obliczenia na dwóch jej bajtach - rozumiesz ?

A andrews wyjaśnił ci od podszewki pokazując nawet jak te obliczenia binarnie wyglądają - tylko, że z kolei pewnie też musisz jeszcze sobie gdzieś doczytać o prostych operacjach binarnych jak dodawanie i odejmowanie - bo to takie absolutne podstawy.

Statystyki: Napisane przez mirekk36 — 18 maja 2019, o 23:27

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-18T21:38:13+01:00

Z tego wnioskuję że nie mam się czym martwić i że kompilator w takim przypadku jak dekodowanie RC5 z przykładu z BB zrobi wszystko za mnie. Jeżeli tak to bardzo fajnie. Tylko że ja jestem taki typ że będzie mnie to gryzło do puki nie zrozumiem tego, może nawet do "grobowej deski".

Statystyki: Napisane przez 11jacekj — 18 maja 2019, o 21:38

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-18T09:41:51+01:00

11jacekj napisał(a):

Czy w przypadku odejmowania wartości licznika 16 bitowego odejmujemy najpierw młodszy bajt a później starszy?

Mój opis to tylko próba wytłumaczenia, dlaczego w tej konkretnej sytuacji odejmowanie liczby większej od mniejszej daje prawidłowy wynik. Jeśli piszesz w języku C, to nie musisz się martwić o kolejność odejmowania bajtów. Wystarczy zdefiniować zmienne jako typ uint16_t i odjąć je od siebie, a kompilator dobierze odpowiednią sekwencję poleceń asemblera, żeby tę operację wykonać. Niczego nie musisz rozbijać na bajty, to tylko miało służyć wyjaśnieniu pewnych mechanizmów.

Statystyki: Napisane przez andrews — 18 maja 2019, o 09:41

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-17T23:57:22+01:00

11jacekj napisał(a):

Czy w przypadku odejmowania wartości licznika 16 bitowego odejmujemy najpierw młodszy bajt a później starszy?

Nie kombinuj - wczytaj się w to co andrews opisał - bo tego już lepiej wyjaśnić się nie da

Statystyki: Napisane przez mirekk36 — 17 maja 2019, o 23:57

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-17T21:20:29+01:00

Czy w przypadku odejmowania wartości licznika 16 bitowego odejmujemy najpierw młodszy bajt a później starszy?

Statystyki: Napisane przez 11jacekj — 17 maja 2019, o 21:20

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-13T11:22:57+01:00

mirekk36 napisał(a):

kto jak kto ale Ty byś takiego błędu nie popełnił

Nie żartuj sobie ze mnie Faktycznie dokładam wszelkich starań, aby błędów nie popełniać (lub może raczej, żeby popełniać ich jak najmniej), ale nie jestem nieomylny.
Dlatego cieszę się, kiedy ktoś czyta ze zrozumieniem to, co napisałem i zwraca uwagę na poprawność, bo zawsze jednak najtrudniej jest zauważyć błędy we własnym tekście.

Statystyki: Napisane przez andrews — 13 maja 2019, o 11:22

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-13T10:42:01+01:00

andrews napisał(a):

Już lepiej pewnie byłoby np. 65436, bo ta 4 jest mniej do 5 podobna niż 3

Dokładnie ja nawet w pierwszym momencie napisałem post, że coś mi się nie zgadza z tym 400 - ale no kurczę mówię sobie, kto jak kto ale Ty byś takiego błędu nie popełnił, więc wpatruję się znowu w to wszystko jak sroka w kość i nagle olśnienie - 3 zamiast 5 które moje oczy sobie jednak tylko wyobraziły

Statystyki: Napisane przez mirekk36 — 13 maja 2019, o 10:42

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-13T10:21:11+01:00

mirekk36 napisał(a):

Ja bym tylko podkreślił na czerwono że chodzi o 65336 bo przyznam, że jak pierwszy raz czytałem to widziałem 65536 no i mi się nie zgadzało

Masz rację. W sumie mogłaby to być (prawie) dowolna liczba, ale skoncentrowałem się na tym, żeby wynik był okrągły. Nie pomyślałem o tym, że taka subtelna różnica pomiędzy 65536 a 65336 będzie mało zauważalna. Już lepiej pewnie byłoby np. 65436, bo ta 4 jest mniej do 5 podobna niż 3

Teraz zmieniłem nieco obliczenia, może będzie czytelniej.

Statystyki: Napisane przez andrews — 13 maja 2019, o 10:21

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-13T07:57:52+01:00

andrews napisał(a):

Jeśli odczytane przez nas aktualne wskazanie licznika (zapamiętane w ICR1) jest mniejsze od poprzednio zapamiętanego wskazania, to musi oznaczać, że licznik się przepełnił. Możemy więc przyjąć, że jego faktyczna wartość jest większa o 65536. Zakładając więc, że obecne wskazanie jest równe 200, a poprzednie było 65336, nie odejmujemy 200-65336 tylko de facto musimy odjąć (65536+200)-65336:

Ja bym tylko podkreślił na czerwono że chodzi o 65336 ;) bo przyznam, że jak pierwszy raz czytałem to widziałem 65536 no i mi się nie zgadzało

Statystyki: Napisane przez mirekk36 — 13 maja 2019, o 07:57

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-13T07:34:34+01:00

Super wytłumaczenie.
Ale ósma rano to za wcześnie na takie dokładne opisy... trzeci raz czytam, a i tak nie do końca rozumiem

Statystyki: Napisane przez Marhef — 13 maja 2019, o 07:34

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-13T10:14:02+01:00

Quote:

Nie rozumiem jak mam to policzyć
65000 + 10000
Licznik TCNT jest 16 bitowy więc zliczy do 65535, przepełni się i zacznie liczyć od 0.

Czyli 65000+10000=75000. Na przedstawienie tej liczby potrzeba już 17 bitów, a licznik ma tylko 16 bitów. Bit o wadze 65536 nie mieści się już w tym liczniku, więc zostanie pominięty, co oznacza, że wartość licznika będzie mniejsza o wartość tego bitu:
65000+10000-65536=9464

Trochę trudno to wszystko zrozumieć, nie znając sposobów reprezentacji liczb w systemie binarnym oraz zasad wykonywania przez procesor obliczeń na liczbach całkowitych bez znaku.
Kiedy odejmujesz pisemnie dwie liczby, przykładowo:

Code:

  63
-  5
-----
  58

W tym przykładzie najpierw musimy odjąć 5 od 3, ale 5 jest większe od trzech, więc musimy dokonać tzw. pożyczki z liczby dziesiątek, czyli pożyczamy 1 dziesiątkę dodajemy do 3 i od tego odejmujemy 5 (13-5=8). Oczywiście liczba dziesiątek zmniejsza się o jeden, czyli będzie teraz równa 5. W efekcie otrzymujemy 58.

Procesor liczy podobnie, tylko (w przypadku procesora 8-bitowego) odejmuje bajtami, np.:

Code:

  0010 0110  (38)
- 0001 1001  (25)
------------------
  0000 1101  (13)

Może się jednak zdarzyć, że odjemnik jest większy od odjemnej (jak w powyższym przykładzie 5 było większe od 3). Procesor w tej chwili nie wie jeszcze, jaka będzie wartość kolejnego odejmowanego bajtu i czy w ogóle jakiś bajt będzie odejmowany, po prostu pożycza sobie 1*256 z kolejnego bajtu (ponieważ najmniej znaczący bit kolejnego bajtu ma wagę 256), sygnalizując to flagą przeniesienia (flaga C w rejestrze SREG, nie mylić z flagą przepełnienia licznika). W efekcie wykonywana operacja wygląda tak:

Code:

  1 0001 1001  (25+256=281)
-   0010 0110  (38)
--------------------
    1111 0011  (243) + flaga C ustawiona

Odejmując kolejny bajt należy tę ustawioną flagę odjąć od wyniku odejmowania i wszystko będzie OK, przykładowo:

Code:

  0000 0001
- 0000 0000
-         1 (C =1 = wartość flagi przeniesienia)
------------
  0000 0000

Jeśli jednak nie odejmujemy więcej bajtów (np. odejmowane liczby są jednobajtowe) lub wyższe bajty są równe 0 i nie ma od czego tej flagi odjąć, otrzymujemy wynik nieprawidłowy.

Dlaczego w przypadku operacji na wskazaniach licznika zignorowanie flagi przeniesienia (C) nie jest błędem?

Jeśli odczytane przez nas aktualne wskazanie licznika (zapamiętane w ICR1) jest mniejsze od poprzednio zapamiętanego wskazania, to musi oznaczać, że licznik się przepełnił. Możemy więc przyjąć, że jego faktyczna wartość jest większa o 65536. Zakładając więc, że obecne wskazanie jest równe 200, a poprzednie było 64200, nie odejmujemy 200-64200 tylko de facto musimy odjąć (65536+200)-64200:

Code:

  1 0000 0000 1100 1000  (200+65536)
-   1111 1010 1100 1000  (64200)
--------------------------------
    0000 0110 0000 0000  (1536)

W kodzie wprawdzie nie dodajemy tych 65536 impulsów, odejmując pozornie liczbę większą od mniejszej (dzięki temu obliczenia, które procesor musi wykonać, są nieco krótsze), w zamian za to ignorujemy flagę przeniesienia, której waga - w przypadku liczb 16-bitowych - będzie równa także 65536. Taki mały trick.

Nie rozumiejąc powyższych mechanizmów można faktycznie dojść do wniosku, że wynik odejmowania 200-64200=1536 jest nielogiczny i niepoprawny.

Ważne:
Powyższy mechanizm sprawdza się tylko wtedy, gdy odstęp pomiędzy impulsami na pinie ICP1 nie jest dłuższy niż 65536 impulsów taktujących licznik. Jeśli przykładowo zapisaliśmy wskazanie licznika równe 250, a licznik przed następnym impulsem na ICP1 policzy np. 65936, to wystąpi przepełnienie, licznik się wyzeruje i zdąży policzyć jeszcze do 650. Nowe wskazanie będzie większe od poprzedniego, jednak wynik odejmowania (650-250=400) nie będzie odzwierciedlał faktycznego odstępu czasowego między odczytami. Jeśli istnieje taka możliwość, że odstępy na pinie ICP1 będą dłuższe od cyklu zliczania licznika, należy np. wprowadzić dodatkową zmienną zliczającą przerwania od przepełnienia licznika, która rozszerzy pojemność licznika.

Takie rozwiązanie nie zda również egzaminu w przypadku konfiguracji licznika w trybie CTC i Fast PWM, w których regulujemy okres zliczania poprzez rejestr OCR1A, a także w trybach Phase Correct, ale zwykle nie używa się tych trybów, jeśli chcemy korzystać z Input Capture.

Statystyki: Napisane przez andrews — 12 maja 2019, o 11:41

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-12T08:37:08+01:00

Nie rozumiem jak mam to policzyć

Quote:

65000 + 10000

Licznik TCNT jest 16 bitowy więc zliczy do 65535, przepełni się i zacznie liczyć od 0.

Statystyki: Napisane przez 11jacekj — 12 maja 2019, o 08:37

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-12T01:58:34+01:00

będzie ok - postaraj się obliczyć np wynik

65000 + 10000

Statystyki: Napisane przez mirekk36 — 12 maja 2019, o 01:58

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-11T21:03:38+01:00

I mam kolejne pytanie. Co się stanie kiedy w którymś przerwaniu TCNT będzie miało wartość 65000 i wystąpi kolejne przerwanie po 889us? Licznik się przepełni a długość próbki nie zmieści się granicy tolerancji.

Statystyki: Napisane przez 11jacekj — 11 maja 2019, o 21:03

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-07T11:39:09+01:00

11jacekj napisał(a):

A co jeżeli długość próbki jest równa 889us? W tej sytuacji długość połówki bitu też chyba jest poprawna a mimo to dekodowanie ramki nie powinno zadziałać.

i zadziała - zwróć uwagę w kodzie i w opisie w książce przede wszystkim, jak zrealizowane są TOLERANCJE pomiarów dla czasów półbitów itp

Statystyki: Napisane przez mirekk36 — 7 maja 2019, o 11:39

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-07T15:54:45+01:00

Hmmm głupio pytam czy nikt nie wiee o co chodzi?

Statystyki: Napisane przez 11jacekj — 7 maja 2019, o 10:54

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-05T21:36:31+01:00

Mam kolejne pytanie do piliku ir_decode.c, a dokładnie chodzi mi o dwie pierwsze linijki po sprawdzeniu zakłóceń. Jeżeli sprawdzenie poprawności rami przebrnie przez pierwszy bit startu i wystąpi zbocze narastające na początku drugiego bitu startu rc5cnt jest równe 1 o ile się nie mylę. Nie wystąpiły żadne zakłócenia to wyrażenie [syntax=c]f (frame_status == FRAME_OK)[/syntax] jest prawdziwe. To kolejny warunek if sprawdza czy długość próbki jest większa niż maksymalny czas połowy bitu+tolerancja, jeżeli jest, to rc5cnt powinno przyjąć 2 i dopiero wtedy kolejny warunek (rc5cnt>1) jest prawdziwy i mogą zostać wykonane instrukcje potrzebne do dekodowania ramki. A co jeżeli długość próbki jest równa 889us? W tej sytuacji długość połówki bitu też chyba jest poprawna a mimo to dekodowanie ramki nie powinno zadziałać.

Statystyki: Napisane przez 11jacekj — 5 maja 2019, o 21:36

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-05T06:22:22+01:00

nie, ICR1 nie zwiększa się o jeden, to jest pomiar czasu impulsu w mikrosekundach, a zatem zwiększa się o tyle ile czasu upłynęło pomiędzy dwoma przerwaniami - a nie o jeden.

Statystyki: Napisane przez mirekk36 — 5 maja 2019, o 06:22

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-04T23:17:13+01:00

Może nie jasno napisałem. Chodziło mi o to że każdy impuls wywołuje przerwanie, i przy każdym odebranym impulsie zwiększa wartość ICR1 o jeden. Jeżeli w całej odebranej ramce było by impulsów 19 to ramka spowoduje zwiększenie ICR1 o 19.

Statystyki: Napisane przez 11jacekj — 4 maja 2019, o 23:17

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-04T23:12:31+01:00

a dlaczego defakto o jeden ? skąd taki pomysł ?

o tyle ile zliczy timer1 impulsów - przecież ma mierzyć czas

Statystyki: Napisane przez mirekk36 — 4 maja 2019, o 23:12

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-04T23:01:50+01:00

Czyli defakto jest zwiększany o jeden przy każdym wywołaniu przerwania.

Statystyki: Napisane przez 11jacekj — 4 maja 2019, o 23:01

Re: Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-04T22:44:26+01:00

11jacekj napisał(a):

A jaką wartość ma ICR1?

No przecież to jest licznik Timera1 zliczone impulsy

Statystyki: Napisane przez mirekk36 — 4 maja 2019, o 22:44

Nie rozumiem fragmentu kodu dekodowania RC5

2019-05-04T22:01:30+01:00

Witam. Czytam właśnie rozdział z BB o dekodowaniu RC5 i utknąłem na w pliku ir_decode.c na fragmencie obliczania długości bitu[syntax=c]PulseWidth = ICR1 - LastCapture;
LastCapture = ICR1;[/syntax] O ile dobrze rozumiem to zmienna LastCapture zadeklarowana jako static przyjmuje wartość 0, przy pierwszym wejściu w przerwanie, później LastCapture = ICR1. Do PulseWidth jest przypisana wyliczona wartość. A jaką wartość ma ICR1?

Statystyki: Napisane przez 11jacekj — 4 maja 2019, o 22:01