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



Teraz jest 22 wrz 2021, o 21:47


Strefa czasowa: UTC + 1





Utwórz nowy wątek Odpowiedz w wątku  [ Posty: 22 ] 
Autor Wiadomość
PostNapisane: 29 lip 2021, o 08:53 
Offline
Nowy

Dołączył(a): 04 sie 2019
Posty: 22
Pomógł: 0

Witam
Na płytce stykowej skleciłem układ wg schematu. Napisałem krótki program mający na celu pomiar częstotliwości podłączonego sygnału. Edytor sygnalizuje błędy przy ustawianiu rejestru TIMSK1 ale kompilacja jest bezbłędna. Nie wiem dlaczego ale takie sygnalizacje błędów występują w jednym kadzie a w innym nie. Po wgraniu do procka LCD wyświetla mi liczby losowe tak na pozycji "częstotliwość" jak i "ilość przepełnień". Stosowałem LED-debadżery jak i osyloskop ale nie odkryłem przyczyny takiego działania programu. W tym momencie program zaliczam do kategorii "dziwne".
Może ktoś w wolnej chwili spojrzy na program i odkryje to czego mi nie udało się.

Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
[/syntax]

Pozdrawiam Zbych


Załączniki:

Aby zobaczyć załączniki musisz się zalogować. Tylko zalogowani użytkownicy mogą oglądać i pobierać załączniki.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 29 lip 2021, o 09:07 
Offline
Użytkownik

Dołączył(a): 23 sty 2014
Posty: 1050
Pomógł: 73

Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
Czemu wyłączyłeś podciąganie?



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 29 lip 2021, o 13:53 
Offline
Nowy

Dołączył(a): 04 sie 2019
Posty: 22
Pomógł: 0

To akurat ma najmniejsze znaczenie ponieważ steruję z generatora TTL.

Pozdrawiam Zbych



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 29 lip 2021, o 15:26 
Offline
Użytkownik

Dołączył(a): 01 mar 2021
Posty: 28
Pomógł: 2

Zastanawia mnie po co "gasić" flagę przerwania w procedurze obsługi, a po drugie żeby ją "zgasić" to chyba trzeba wpisać tam logiczną jedynkę.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 29 lip 2021, o 19:15 
Offline
Moderator
Avatar użytkownika

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

adamma25 napisał(a):
a po drugie żeby ją "zgasić" to chyba trzeba wpisać tam logiczną jedynkę.

Nie chyba a napewno ;) zatem prawdę powiadasz

_________________
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: 29 lip 2021, o 19:51 
Offline
Nowy

Dołączył(a): 04 sie 2019
Posty: 22
Pomógł: 0

Witam
Obojętnie czy gaszę flagę wpisując "1" czy "0" lub likwidując to ustawienie nic nie zmienia się. LCD nadal wyświetla liczby losowe za wyjątkiem pierwszego pomiaru. Czasami można zauważyć, że jest wyświetlona wartość poprawna ale to może raz na 50-100 pomiarów. Zauważyłem również, że wszystkie wyświetlone liczby są w prawie 100% większe od mierzonej częstotliwości. Tak jest dla częstotliwości ok. 9Hz. Jeśli ustawię 900Hz mam dwa wyniki. Czasem jest 900Hz a reszta to 192 Hz. dla 9kHz sporadycznie pojawia się wartość poprawna a wyświetlone jest 237Hz.
Odnoszę wrażenie, że procesor nie reaguje na każde zbocze pojawiające się na wejściu ICP1. Może o tym świadczyć za duża liczba przepełnień licznika T1.

Pozdrawiam

------------------------ [ Dodano po: 49 minutach ]

Nawiązując do mojego poprzedniego postu "za duża liczba przepełnień".
Generator ustawiłem na 9180Hz. LCD pokazuje - f = 237.55Hz liczba przepełnień = 1 a F_CPU = 16MHz.
Kalkulator pokazuje: 16000000Hz/9180Hz = 1744 impulsów i powinno być 0 przepełnień. ( może wystąpić 1 przepełnienie jeśli licznik T1 zacznie liczyć w pobliżu swojej maksymalnej [TOP] wartości).
Teraz 16000000Hz/237.55Hz = 67354 impulsów - 65536[TOP] = 1818 impulsów. Czyli dla wyświetlenia 237.55Hz potrzebne jest jedno przepełnienie i 1818 impulsów. Tu powstaje pytanie skąd wzięło się to przepełnienie i liczba impulsów 1818 jeśli do wyświetlenia prawidłowej wartości potrzeba tylko 1744 impulsów.

------------------------ [ Dodano po: 57 minutach ]

Zapomniałem dodać, że powyższe obserwacje i obliczenia wykonano bez ustawiania/kasowania flagi w przerwaniu.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 29 lip 2021, o 21:23 
Offline
Użytkownik
Avatar użytkownika

Dołączył(a): 29 lis 2019
Posty: 125
Pomógł: 31

Bez nadmiernego zagłębiania się w kod:
Jachimo napisał(a):
ilosc_cykli = 65536 * ilosc_przepelnien - start_A + koniec_B;

Dostęp do współdzielonych zmiennych 16 bitowych musi być w sekcji krytycznej. Tu dodatkowo jest kilka zmiennych współdzielonych.

Jachimo napisał(a):
                if(pomiar_gotowy){
 //...
                }
 
//...
                pomiar_gotowy = 0;                              //zerujemy flagę końca pomiaru

Gaszenie współdzielonej flagi poza blokiem uwarunkowanym tą flagą. Tu z pewnością można się spodziewać nieprawidłowego działania.

No i na koniec - przy tej metodzie raz na jakiś czas można się spodziewać fałszywego wyniku z powodu zliczenia za małej/za dużej liczby przepełnień

_________________
Think for yourself and question authority.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 30 lip 2021, o 08:25 
Offline
Użytkownik

Dołączył(a): 01 mar 2021
Posty: 28
Pomógł: 2

Witam. Nie miej za złe że zwróciłem uwagę na sposób gaszenia flagi, ponieważ może ci się to kiedyś przydać i warto wiedzieć jak to zrobić poprawnie. Kolega fofex rzucił kilka trafnych spostrzeżeń. Jeszcze ten _delay_ms(500) na końcu nie sprawia że pomiar jest robiony co pół sekundy, bo pomiar wykonuje się natychmiast po włączeniu przetrwania od ICP, tylko wyświetla się co pół sekundy.

------------------------ [ Dodano po: 6 minutach ]

Nie wiem czy to będzie miało znaczenie, ale może zmień sposób obliczania ilosc_cykli = uint32(65536 * ilosc_przepelnien ) + (koniec_B - start_A)



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 30 lip 2021, o 12:25 
Offline
Nowy

Dołączył(a): 04 sie 2019
Posty: 22
Pomógł: 0

Witam

adamma25 napisał(a):
Nie miej za złe że zwróciłem uwagę na sposób gaszenia flagi

Nie mam nikomu za złe za odpowiedzi i podpowiedzi. Jak gasić tą flagę - po prostu nie doczytałem PDFa. Twoja uwaga pozwoliła stwierdzić, że jej ustawienie/skasowanie nie ma wpływu na pomiar. Jednak pomiar jest wykonywany co pół sekundy. Rzeczywiście start pomiaru następuje po ustawieniu przerwania ICP ale kończy się po skasowaniu przerwań w wektorze "TIMER1_CAPT_vect" a później jest delay. Po wyświetleniu wyniku następny start.
Zmiana sposobu obliczania ilości cykli nic nie zmienia.
fofex napisał(a):
No i na koniec - przy tej metodzie raz na jakiś czas można się spodziewać fałszywego wyniku z powodu zliczenia za małej/za dużej liczby przepełnień

Ne rozumiem na jakiej podstawie "można spodziewać się fałszywego wyniku". Przecież po załączeniu przerwania "TIMER1_CAPT_vect" wykonuje się procedura obsługi. Jeśli są jakieś przepełnienia to powinny być zliczone.
Przy takim stwierdzeniu nie można być pewnym co , kiedy i jak wykona procesor.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 30 lip 2021, o 17:39 
Offline
Użytkownik

Dołączył(a): 01 mar 2021
Posty: 28
Pomógł: 2

Acha czyli większość czasu w pętli głównej program spędza w funkcji _delay_ms.
Może to prymitywne pytanie, ale czy na pewno wszystko dobrze styka, wyłapuje wszystkie zbocza prawidłowo?

------------------------ [ Dodano po: 22 minutach ]

Może spróbuj przy pierwszym wejściu gdy start_stop==1 wyzerować licznik tak aby liczył od zera, wtedy obliczenia ilości taktów będą prostsze , odpadnie zmienna start_A zostanie tylko ilosc_cykli = 65536 * ilosc_przepelnien + koniec_B; ale to tylko taka moja uwaga.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 30 lip 2021, o 18:03 
Offline
Nowy

Dołączył(a): 04 sie 2019
Posty: 22
Pomógł: 0

Głowy nie dam ale po ostatnim eksperymencie wygląda na to, że jest Ok. A eksperyment - przed obliczeniem liczby impulsów wstawiłem instrukcję odejmowania. Teraz wygląda to tak:
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.

Okazało się, że teraz pomiary w zakresie 100Hz - 10kHz są prawie prawidłowe. Przy czym im niższa mierzona częstotliwość to ilość błędnych pomiarów wzrasta. Przy 10kHz błąd jest sporadyczny ale przy 100Hz ilość błędnych pomiarów to 50-60 %.
Przy 100Hz powinny być 2 przepełnienia i tak jest gdy wyświetlany jest prawidłowy pomiar. Przy błędnych pomiarach liczba przepełnień jest 1 albo 3.
Wygląda na to, że jest błąd przy liczeniu przepełnień tylko nie mogę wyczaić gdzie.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 30 lip 2021, o 20:21 
Offline
Użytkownik
Avatar użytkownika

Dołączył(a): 29 lis 2019
Posty: 125
Pomógł: 31

Jachimo napisał(a):
na jakiej podstawie "można spodziewać się fałszywego wyniku"

Możliwe, że nic takiego nie zajdzie. Sprawa jest dosyć "krucha", w grę wchodzi współzależność priorytetów przerwań, momentu "łapania" danych i wykonywania obliczeń. Trzeba by to uważnie przeanalizować.

Widzę, że uwagi o zabezpieczeniu dostępu do danych współdzielonych zignorowałeś. Cóż...z tym kodem (delay i inne takie) możliwe, że nic się nie stanie, ale z bardziej zbornym algorytemem z pewnością to zaniedbanie wybuchnie Ci prosto w twarz.

_________________
Think for yourself and question authority.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 30 lip 2021, o 20:37 
Offline
Użytkownik

Dołączył(a): 01 mar 2021
Posty: 28
Pomógł: 2

Według mnie jest błąd w obliczeniach, bo zauważ, że gdy start_A= np. 6553, czyli wypadnie przy końcu zakresu, a koniec_B wypadnie gdzieś na początku i będzie mniejszy niż Start_A to ich różnica będzie równa Zero, i tu już jest błąd. Spróbuj wyzerować licznik przy pierwszym wejściu. Wpisz po prostu do TCNT1 zero i wtedy wyeliminujesz Start_A ze wzoru i jeśli wypadnie gdzieś przy końcu zakresu, to wyeliminujesz również pierwsze niepotrzebne przepełnienie.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 31 lip 2021, o 09:36 
Offline
Nowy

Dołączył(a): 04 sie 2019
Posty: 22
Pomógł: 0

Witam.
Ten program wykorzystuje "Input Capture Unit". Wg PDFa licznik TNCT1 jest niejako poza modułem a do przechwytywania jego wartości służy rejestr ICR1. Więc do obliczenia częstotliwości trzeba przechwycić stan licznika TCNT1 przy pierwszym zboczu narastającym/opadającym na ICP1 i stan licznika przy następnym zboczu. W PDF-ie stoi (przynajmniej ja tak to rozumiem), że nie należy ingerować w pracę modułu "Input Capture Unit".
adamma25 napisał(a):
Acha czyli większość czasu w pętli głównej program spędza w funkcji _delay_ms.

Program tak ale w tym czasie pracują liczniki przygotowując dane do wyświetlenia. Przypuszczam (sprawdzę to) ,że jeśli mierzona częstotliwość będzie mniejsza niż 1/delay() to zostanie zdezorganizowana praca całego programu. Po prostu liczniki nie zdążą w tym czasie zaliczyć dwóch przerwań od pierwszego i następnego zbocza.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 31 lip 2021, o 11:14 
Offline
Użytkownik

Dołączył(a): 07 cze 2016
Posty: 555
Pomógł: 142

Kolega adamma25 ma rację, że problemem będzie tutaj niewłaściwa ilość przepełnień, jednak pomysł z zerowaniem TCNT1 nie jest zbytnio trafiony, ze względu na wprowadzenie pewnego błędu pomiaru. Z drugie strony autor wątku nie zadeklarował ani oczekiwanego zakresu pomiaru, ani oczekiwanej dokładności pomiaru. Być może taki błąd będzie akceptowalny.

Ja pokażę, jak ja próbowałbym to zrobić. Timer 1 pracuje cały czas, a przerwania zliczają impulsy kolejnych okresów (w zmiennej period_cnt znajduje się zawsze ostatnio zmierzony okres w taktach). W procedurze obsługi przerwania od przepełnienia odmierzany jest okres odświeżania wyświetlacza (zmienna/flaga new_measure). Okres odświeżania powinien wynieść ok.0,5s dla częstotliwości taktowania 16MHz.

Okres obliczany jest w ten sposób, że tworzone są dwa znaczniki czasowe 32-bitowe - aktualny i poprzedni, a następnie są od siebie odejmowane.

Nie jest to gotowy program, jeszcze wiele kwestii trzeba rozwiązać. Przykładowo w przypadku zaniku sygnału na wejściu przerwania ICP nie będą wykonywane, a wyświetlacz będzie pokazywał ostatnio obliczoną wartość zamiast 0 (zresztą problem ten dotyczy chyba również programu autora wątku). Same wartości częstotliwości powinny być obliczane prawidłowo. Program po skompilowaniu powinien działać prawidłowo, jednak ze względu na czas wykonywania przerwań poprawnie mierzona częstotliwość może być ograniczona do ok. 50kHz. Można ewentualnie spróbować przenieść część obliczeń do pętli głównej, ale to raczej niewiele zmieni, ponieważ część operacji i tak musi być wykonywana atomowo, czyli z wyłączonymi przerwaniami.

OBROT_ustaw.h
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.


main.c
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 31 lip 2021, o 13:21 
Offline
Użytkownik

Dołączył(a): 01 mar 2021
Posty: 28
Pomógł: 2

No tak, błąd będzie, ale można go skorygować (nie trzeba zerować, ale wpisać początkowe wartości metodą prób)).

Kolego Jahimo nie mówię tu o ingerencji w rejestr przechwytywania, tylko w rejestr licznika. Rejestr licznika możesz w każdej chwili wyzerować, lub wpisać tam dowolną wartość. Pozdrawiam. ✋



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 1 sie 2021, o 15:46 
Offline
Nowy

Dołączył(a): 04 sie 2019
Posty: 22
Pomógł: 0

Witam
Zerowanie TNCT1 nic nie dało - a wręcz przeciwnie wzrosła liczba błędnych pomiarów.
Kolega "andrews" zaproponował nową metodę. Kod zawiera błędy ale ma potencjał. Umożliwia pozbycie się instrukcji "if else" i usuwa problemy z liczeniem przepełnień.
Błędy to: zerowanie zmiennych przy deklaracji w "ISR(TIMER1_CAPT_vect)", zmienna "prev_ICR" nie bierze udziału w obliczeniach, natomiast zmienna "period_cycles = current_ts - prev_ts;" tak naprawdę równa się Δ(ovf_cnt)*65536 ponieważ reszta wyzeruje się.
Uwzględniając powyższe funkcja obsługi przerwania wygląda jak niżej.
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.

W pierwszej wersji obliczenie wartości "period_cycles" wyciągnąłem do "main" ale po próbach okazało się, że obliczenie wartości w przerwaniu nie wprowadza błędów.
Przy próbach wyświetlałem na LCD wartość licznika "ovf_cnt". Nie wiem dlaczego wartość narasta od zera do 32768 zmienia znak -32768 i dalej narasta do zera. A przecież zadeklarowana jest jako uint16_t.
Maksymalna mierzona częstotliwość ok. 32kHz. Minimalnej nie znam bo mój generator daje najmniej 1.5Hz. Sądzę, że przy najwyższych mierzonych częstotliwościach będą największe błędy wynikające z niewielkiej liczby impulsów policzonych w jednym okresie. Np. dla częstotliwości 32kHz liczba impulsów to tylko 500 (F_MCU=16MHz) Jeśli liczba impulsów zmaleje do 499 to obliczona częstotliwość będzie 32064Hz. Skok o 64 Hz. Błąd ok. 0,2%. Jednak taki błąd nie pozwala na użycie takiego miernika przy precyzyjnych pomiarach.
Taki licznik można wykorzystać jako fragment większej całości do pomiarów niskich częstotliwości a do pomiarów wyższych częstotliwości trzeba stosować inne metody.
Teraz zostaje dorobienie wodotrysków aby powstała całość.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 1 sie 2021, o 15:52 
Offline
Użytkownik

Dołączył(a): 02 gru 2015
Posty: 471
Pomógł: 24

Cytuj:
Przy próbach wyświetlałem na LCD wartość licznika "ovf_cnt". Nie wiem dlaczego wartość narasta od zera do 32768 zmienia znak -32768 i dalej narasta do zera. A przecież zadeklarowana jest jako uint16_t.

Jeśli używasz Mirka funkcji lcd_int to to normalne zachowanie ponieważ ta funkcja wyświetla liczby z zakresu int.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 1 sie 2021, o 16:01 
Offline
Nowy

Dołączył(a): 04 sie 2019
Posty: 22
Pomógł: 0

Masz rację - nie zwróciłem uwagi. Zagadka wyjaśniona.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 1 sie 2021, o 20:10 
Offline
Użytkownik

Dołączył(a): 07 cze 2016
Posty: 555
Pomógł: 142

Jachimo napisał(a):
Kolega "andrews" zaproponował nową metodę. Kod zawiera błędy ale ma potencjał.
To ciekawe, bo u mnie kompilowało się bez błędów i symulacja przebiegała prawidłowo. Nie bardzo rozumiem, skąd stwierdzenie, że kod zawiera błędy.

Jachimo napisał(a):
... zmienna "prev_ICR" nie bierze udziału w obliczeniach...
Gdyby nie brała udziału, to wynik nie byłby prawidłowy.

Jachimo napisał(a):
...zmienna "period_cycles = current_ts - prev_ts;" tak naprawdę równa się Δ(ovf_cnt)*65536 ponieważ reszta wyzeruje się...
Nie chce mi się teraz tego analizować dokładnie. Pisząc kod koncentrowałem się na tym, żeby był przejrzysty i łatwy do analizy. Nie mam jednak zbyt dużo wolnego czasu na takie zadania, więc przepraszam najmocniej, że tego zadania nie wykonałem należycie. Ale OK, nawet jeśli znalazłeś sposób, żeby skrócić obliczenia, to wcale nie oznacza, że mój kod był błędny, może co najwyżej nieco mniej optymalny (za to być może łatwiejszy do zrozumienia). Jestem za to pewien, że działał prawidłowo.

Jachimo napisał(a):
Maksymalna mierzona częstotliwość ok. 32kHz.
Ta granica może się zmniejszyć, jeśli w programie użyjesz jeszcze innych przerwań.

Jachimo napisał(a):
Taki licznik można wykorzystać jako fragment większej całości do pomiarów niskich częstotliwości a do pomiarów wyższych częstotliwości trzeba stosować inne metody.

Do pomiaru niższych częstotliwości używa się pomiaru czasu trwania okresu, do pomiaru większych częstotliwości raczej należy zliczać ilość okresów w jednostce czasu.


Autor postu otrzymał pochwałę


Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 1 sie 2021, o 20:55 
Offline
Nowy

Dołączył(a): 04 sie 2019
Posty: 22
Pomógł: 0

Witam
To prawda - kompilacja była poprawna ale jak wpisałem Twój kod do procesora wynik był:
-1.16000 i nie zmieniał się bez względu na mierzoną częstotliwość.

Zmienna "prev_ICR" nie brała udziału w obliczeniach ponieważ przy definicji nadano jej wartość zero i nigdzie nie zmieniono.
Analizujmy dalej:

"period_cycles = current_ts - prev_ts;"

Podstawmy wartości pod zmienne "current_ts" i "prev_ts".
Ponieważ mierzona częstotliwość jest stała różnica "current_ICR - prev_ICR" nie zmieni się w kolejnym przerwaniu. Zmieni się tylko "ovf_cnt" co zaznaczyłem nadając indeksy 1 i 2.

current_ts = 65536 * ovf_cnt_1 + (current_ICR - prev_ICR);
prev_ts = 65536 * ovf_cnt_2 + (current_ICR - prev_ICR);

Więc po wpisaniu wartości "curent_ts" i "prev_ts" dostaniemy

"period_cycles = 65536 * (ovf_cnt_1 - ovf_cnt_2)

i nie jest to raczej pożądana wartość.
Tobie jednak należy się cześć i chwała za inny sposób podejścia do tematu pozwalający na napisanie bezbłędnego kodu.



Góra
 Zobacz profil  
cytowanie selektywne  Cytuj  
PostNapisane: 2 sie 2021, o 08:51 
Offline
Użytkownik

Dołączył(a): 07 cze 2016
Posty: 555
Pomógł: 142

Przyznaję, że z tym prev_ICR masz chyba rację, ale nie do końca. Przyznaję, że się pomyliłem się (prawdopodobnie z pośpiechu - lepiej chyba nie wdawać się w dyskusję będąc na urlopie ;) ).Tak naprawdę ta zmienna jest zbędna i należy ją pominąć. Gwarantuję Ci, że poniższa wersja ISR musi dać prawidłowe wyniki (i dla mnie jest czytelniejsza):
Składnia: [ Pobierz ] [ Ukryj ]
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.

Jeśli natomiast chodzi o czas trwania procedury obsługi przerwania, to będzie porównywalny z Twoim. Zresztą ten czas ma znaczenie tylko przy wyższych częstotliwościach, przy których (jak sam zauważyłeś) błąd i tak jest dość spory, więc lepiej zastosować inną metodę pomiaru.



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: 22 ] 

Strefa czasowa: UTC + 1


Kto przegląda forum

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


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