Kanał - ATNEL tech-forum
Wszystkie działy
Najnowsze wątki



Teraz jest 28 mar 2024, o 20:55


Strefa czasowa: UTC + 1





Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 25 ] 
Autor Wiadomość
PostNapisane: 4 maja 2019, o 22:01 
Offline
Użytkownik

Dołączył(a): 03 lut 2016
Posty: 126
Pomógł: 0

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
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
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?



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 4 maja 2019, o 22:44 
Offline
Moderator
Avatar użytkownika

Dołączył(a): 03 paź 2011
Posty: 27212
Lokalizacja: Szczecin
Pomógł: 1041

11jacekj napisał(a):
A jaką wartość ma ICR1?

No przecież to jest licznik Timera1 ;) zliczone impulsy

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 4 maja 2019, o 23:01 
Offline
Użytkownik

Dołączył(a): 03 lut 2016
Posty: 126
Pomógł: 0

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



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 4 maja 2019, o 23:12 
Offline
Moderator
Avatar użytkownika

Dołączył(a): 03 paź 2011
Posty: 27212
Lokalizacja: Szczecin
Pomógł: 1041

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

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

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 4 maja 2019, o 23:17 
Offline
Użytkownik

Dołączył(a): 03 lut 2016
Posty: 126
Pomógł: 0

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.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 5 maja 2019, o 06:22 
Offline
Moderator
Avatar użytkownika

Dołączył(a): 03 paź 2011
Posty: 27212
Lokalizacja: Szczecin
Pomógł: 1041

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.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 5 maja 2019, o 21:36 
Offline
Użytkownik

Dołączył(a): 03 lut 2016
Posty: 126
Pomógł: 0

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
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
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ć.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 7 maja 2019, o 10:54 
Offline
Użytkownik

Dołączył(a): 03 lut 2016
Posty: 126
Pomógł: 0

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



Ostatnio edytowano 7 maja 2019, o 15:54 przez 11jacekj, łącznie edytowano 1 raz

Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 7 maja 2019, o 11:39 
Offline
Moderator
Avatar użytkownika

Dołączył(a): 03 paź 2011
Posty: 27212
Lokalizacja: Szczecin
Pomógł: 1041

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

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 11 maja 2019, o 21:03 
Offline
Użytkownik

Dołączył(a): 03 lut 2016
Posty: 126
Pomógł: 0

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.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 12 maja 2019, o 01:58 
Offline
Moderator
Avatar użytkownika

Dołączył(a): 03 paź 2011
Posty: 27212
Lokalizacja: Szczecin
Pomógł: 1041

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

65000 + 10000

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 12 maja 2019, o 08:37 
Offline
Użytkownik

Dołączył(a): 03 lut 2016
Posty: 126
Pomógł: 0

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



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 12 maja 2019, o 11:41 
Offline
Użytkownik

Dołączył(a): 07 cze 2016
Posty: 563
Pomógł: 143

Cytuj:
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:
Kod:
  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.:
Kod:
  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:
Kod:
  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:
Kod:
  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:
Kod:
  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.



Ostatnio edytowano 13 maja 2019, o 10:14 przez andrews, łącznie edytowano 1 raz

Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 13 maja 2019, o 07:34 
Offline
Użytkownik
Avatar użytkownika

Dołączył(a): 26 sty 2016
Posty: 1146
Lokalizacja: Kraków
Pomógł: 93

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



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 13 maja 2019, o 07:57 
Offline
Moderator
Avatar użytkownika

Dołączył(a): 03 paź 2011
Posty: 27212
Lokalizacja: Szczecin
Pomógł: 1041

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 ;)

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 13 maja 2019, o 10:21 
Offline
Użytkownik

Dołączył(a): 07 cze 2016
Posty: 563
Pomógł: 143

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.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 13 maja 2019, o 10:42 
Offline
Moderator
Avatar użytkownika

Dołączył(a): 03 paź 2011
Posty: 27212
Lokalizacja: Szczecin
Pomógł: 1041

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 ;)

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 13 maja 2019, o 11:22 
Offline
Użytkownik

Dołączył(a): 07 cze 2016
Posty: 563
Pomógł: 143

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.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 17 maja 2019, o 21:20 
Offline
Użytkownik

Dołączył(a): 03 lut 2016
Posty: 126
Pomógł: 0

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



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 17 maja 2019, o 23:57 
Offline
Moderator
Avatar użytkownika

Dołączył(a): 03 paź 2011
Posty: 27212
Lokalizacja: Szczecin
Pomógł: 1041

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

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 18 maja 2019, o 09:41 
Offline
Użytkownik

Dołączył(a): 07 cze 2016
Posty: 563
Pomógł: 143

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.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 18 maja 2019, o 21:38 
Offline
Użytkownik

Dołączył(a): 03 lut 2016
Posty: 126
Pomógł: 0

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".



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 18 maja 2019, o 23:27 
Offline
Moderator
Avatar użytkownika

Dołączył(a): 03 paź 2011
Posty: 27212
Lokalizacja: Szczecin
Pomógł: 1041

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.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 19 maja 2019, o 09:59 
Offline
Użytkownik

Dołączył(a): 07 cze 2016
Posty: 563
Pomógł: 143

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.


Autor postu otrzymał pochwałę


Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 19 maja 2019, o 12:18 
Offline
Moderator
Avatar użytkownika

Dołączył(a): 03 paź 2011
Posty: 27212
Lokalizacja: Szczecin
Pomógł: 1041

andrews napisał(a):
... że procesor jest jak niefrasobliwa, rozrzutna żona, która pożycza, nie wiedząc, czy będzie z czego oddać.


:lol: :lol: :lol: no tego jeszcze nie słyszałem ! :lol: dobre

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
Wyświetl posty nie starsze niż:  Sortuj wg  
Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 25 ] 

Strefa czasowa: UTC + 1


Kto przegląda forum

Użytkownicy przeglądający ten dział: Brak zidentyfikowanych użytkowników i 1 gość


Nie możesz rozpoczynać nowych wątków
Nie możesz odpowiadać w wątkach
Nie możesz edytować swoich postów
Nie możesz usuwać swoich postów
Nie możesz dodawać załączników

Szukaj:
Skocz do:  
Sitemap
Technologię dostarcza phpBB® Forum Software © phpBB Group phpBB3.PL
phpBB SEO