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

[/syntax]

Pozdrawiam Zbych

_________________
drugstore-onlinecatalog.com

Czemu wyłączyłeś podciąganie?

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

Pozdrawiam Zbych

_________________
drugstore-onlinecatalog.com

Zastanawia mnie po co "gasić" flagę przerwania w procedurze obsługi, 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 ]

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.

_________________
drugstore-onlinecatalog.com

Bez nadmiernego zagłębiania się w kod:

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


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.

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)

Witam


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.

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.

_________________
drugstore-onlinecatalog.com

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ł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:

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.

_________________
drugstore-onlinecatalog.com

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.

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.

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

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.

_________________
drugstore-onlinecatalog.com

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


main.c

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

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.

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ść.

_________________
drugstore-onlinecatalog.com

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

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

_________________
drugstore-onlinecatalog.com

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.

Gdyby nie brała udziału, to wynik nie byłby prawidłowy.

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.

Ta granica może się zmniejszyć, jeśli w programie użyjesz jeszcze innych przerwań.


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.

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.

_________________
drugstore-onlinecatalog.com

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

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.