ATNEL tech-forum

Re: ATmega328P wyszło dziwne

2021-08-02T08:51:44+01:00

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):
[syntax=c]ISR(TIMER1_CAPT_vect) {
static uint32_t current_ts = 0;
static uint32_t prev_ts = 0;
uint16_t current_ICR;

current_ICR = ICR1;
current_ts = 65536 * ovf_cnt + current_ICR;
period_cycles = current_ts - prev_ts;
prev_ts = current_ts;
}[/syntax]
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.

Statystyki: Napisane przez andrews — 2 sie 2021, o 08:51

Re: ATmega328P wyszło dziwne

2021-08-01T20:55:22+01:00

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.

Statystyki: Napisane przez Jachimo — 1 sie 2021, o 20:55

Re: ATmega328P wyszło dziwne

2021-08-01T20:10:39+01:00

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.

Statystyki: Napisane przez andrews — 1 sie 2021, o 20:10

Re: ATmega328P wyszło dziwne

2021-08-01T16:01:52+01:00

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

Statystyki: Napisane przez Jachimo — 1 sie 2021, o 16:01

Re: ATmega328P wyszło dziwne

2021-08-01T15:52:49+01:00

Quote:

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.

Statystyki: Napisane przez tonygryps — 1 sie 2021, o 15:52

Re: ATmega328P wyszło dziwne

2021-08-01T15:46:59+01:00

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.
[syntax=c]ISR(TIMER1_CAPT_vect) {

uint16_t current_ICR;
uint16_t current_ovf_cnt;
static uint16_t prev_ICR;
static uint16_t prev_ovf_cnt;

current_ICR = ICR1;
current_ovf_cnt = ovf_cnt;
period_cycles = 65536 * (current_ovf_cnt - prev_ovf_cnt) + current_ICR - prev_ICR;
prev_ICR = current_ICR;
prev_ovf_cnt = current_ovf_cnt;
}[/syntax]
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ść.

Statystyki: Napisane przez Jachimo — 1 sie 2021, o 15:46

Re: ATmega328P wyszło dziwne

2021-07-31T13:21:00+01:00

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

Statystyki: Napisane przez adamma25 — 31 lip 2021, o 13:21

Re: ATmega328P wyszło dziwne

2021-07-31T11:14:35+01:00

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
[syntax=c]/*
* OBROT_ustaw.h
*
* Created on: 27 lip 2021
* Author: Zbych
*/

#ifndef OBROT_USTAW_H_
#define OBROT_USTAW_H_

//#include "LCD/lcd44780.h"
//#include "I2C_TWI/i2c_twi.h"

#define LED1 (1<#define LED2 (1<
#define LED1_TOG PORTC ^= LED1
#define LED1_OFF PORTC |= LED1
#define LED1_ON PORTC &= ~LED1
#define LED2_TOG PORTC ^= LED2
#define LED2_OFF PORTC |= LED2
#define LED2_ON PORTC &= ~LED2

//void wykonaj_pomiar(void);

#endif /* OBROT_USTAW_H_ */[/syntax]

main.c
[syntax=c]/*
* main.c
*
* Created on: 26 lip 2021
* Author: Zbych
*/

#include
//#include
#include
#include
#include
#include "OBROT_ustaw.h"

volatile uint32_t period_cycles; // liczba policzonych impulsów
volatile uint16_t ovf_cnt = 0;
volatile uint8_t new_measure;

int main(void) {

volatile uint32_t czestotliwosc = 0;
uint32_t local_period_cycles = 0;

DDRC |= (LED1|LED2);
// PORTB |= (1< LED1_OFF;

lcd_init(); //inicjalizacja LCD i napis początkowy
lcd_str("Czestosciomierz");
//Ustawienie Timer1
TCCR1A = 0;
TCCR1B = (1< TIMSK1 |= (1<
sei(); //włącz przerwania globalne

while(1){
if (new_measure) {
LED2_TOG;
ATOMIC_BLOCK(ATOMIC_RESTORESTATE) {
local_period_cycles = period_cycles;
}
if (local_period_cycles) {
czestotliwosc = F_CPU / local_period_cycles;
lcd_locate(1, 0);
lcd_int(czestotliwosc);
lcd_char('.');
lcd_int( ( F_CPU % local_period_cycles)/1000 );
lcd_str(" ");
// lcd_locate(1, 13);
// lcd_int(local_period_cycles);
}
new_measure = 0;
}

}
}

ISR(TIMER1_CAPT_vect) {
static uint16_t prev_ICR = 0;
static uint32_t current_ts = 0;
static uint32_t prev_ts = 0;
uint16_t current_ICR;

current_ICR = ICR1;
current_ts = 65536 * ovf_cnt + current_ICR - prev_ICR;
period_cycles = current_ts - prev_ts;
prev_ts = current_ts;
}

ISR(TIMER1_OVF_vect) {
ovf_cnt += 1; //powiększ licznik przepełnień Timera1
if ( !(ovf_cnt % 122) ) new_measure = 1;
}[/syntax]

Statystyki: Napisane przez andrews — 31 lip 2021, o 11:14

Re: ATmega328P wyszło dziwne

2021-07-31T09:36:15+01:00

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.

Statystyki: Napisane przez Jachimo — 31 lip 2021, o 09:36

Re: ATmega328P wyszło dziwne

2021-07-30T20:37:31+01:00

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.

Statystyki: Napisane przez adamma25 — 30 lip 2021, o 20:37

Re: ATmega328P wyszło dziwne

2021-07-30T20:21:17+01:00

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.

Statystyki: Napisane przez fofex — 30 lip 2021, o 20:21

Re: ATmega328P wyszło dziwne

2021-07-30T18:03:32+01:00

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:
[syntax=c]ilosc_przepelnien -= 1;
ilosc_cykli = (uint32_t)(65536 * ilosc_przepelnien) + (koniec_B - start_A);[/syntax]
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.

Statystyki: Napisane przez Jachimo — 30 lip 2021, o 18:03

Re: ATmega328P wyszło dziwne

2021-07-30T17:39:05+01:00

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.

Statystyki: Napisane przez adamma25 — 30 lip 2021, o 17:39

Re: ATmega328P wyszło dziwne

2021-07-30T12:25:41+01:00

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.

Statystyki: Napisane przez Jachimo — 30 lip 2021, o 12:25

Re: ATmega328P wyszło dziwne

2021-07-30T08:25:52+01:00

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)

Statystyki: Napisane przez adamma25 — 30 lip 2021, o 08:25

Re: ATmega328P wyszło dziwne

2021-07-29T21:23:07+01:00

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ń

Statystyki: Napisane przez fofex — 29 lip 2021, o 21:23

Re: ATmega328P wyszło dziwne

2021-07-29T19:51:04+01:00

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.

Statystyki: Napisane przez Jachimo — 29 lip 2021, o 19:51

Re: ATmega328P wyszło dziwne

2021-07-29T19:15:08+01:00

adamma25 napisał(a):

a po drugie żeby ją "zgasić" to chyba trzeba wpisać tam logiczną jedynkę.

Nie chyba a napewno zatem prawdę powiadasz

Statystyki: Napisane przez mirekk36 — 29 lip 2021, o 19:15

Re: ATmega328P wyszło dziwne

2021-07-29T15:26:02+01:00

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

Statystyki: Napisane przez adamma25 — 29 lip 2021, o 15:26

Re: ATmega328P wyszło dziwne

2021-07-29T13:53:57+01:00

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

Pozdrawiam Zbych

Statystyki: Napisane przez Jachimo — 29 lip 2021, o 13:53

Re: ATmega328P wyszło dziwne

2021-07-29T09:07:49+01:00

[syntax=c]// PORTB |= (1<Statystyki: Napisane przez Jarecki — 29 lip 2021, o 09:07

ATmega328P wyszło dziwne

2021-07-29T08:53:02+01:00

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=c]/*
* OBROT_ustaw.h
*
* Created on: 27 lip 2021
* Author: Zbych
*/

#ifndef OBROT_USTAW_H_
#define OBROT_USTAW_H_

#include
//#include
#include
#include

#include "LCD/lcd44780.h"
#include "I2C_TWI/i2c_twi.h"

#define LED1 (1<#define LED2 (1<
#define LED1_TOG PORTC ^= LED1
#define LED1_OFF PORTC |= LED1
#define LED1_ON PORTC &= ~LED1
#define LED2_TOG PORTC ^= LED2
#define LED2_OFF PORTC |= LED2
#define LED2_ON PORTC &= ~LED2

volatile uint32_t ilosc_cykli;// liczba policzonych impulsów
volatile uint16_t ilosc_przepelnien;// liczba przepełnień w czasie pomiaru
volatile uint8_t start_stop;// flaga początek- koniec pomiaru
volatile uint8_t pomiar_gotowy;// flaga zakończenia pomiaru i wyświetlenia wyniku

volatile uint16_t start_A;// stan licznika ICR1 na początku pomiaru
volatile uint16_t koniec_B;// stan licznika ICR1 na końcu pomiaru

//void wykonaj_pomiar(void);

#endif /* OBROT_USTAW_H_ */
[syntax=c]/*
* main.c
*
* Created on: 26 lip 2021
* Author: Zbych
*/
#include "OBROT_ustaw.h"

int main(void){

uint32_t czestotliwosc = 0;

DDRC |= (LED1|LED2);
//PORTB |= (1<LED1_OFF;

lcd_init(); //inicjalizacja LCD i napis początkowy
lcd_str("Czestosciomierz");
//Ustawienie Timer1
TCCR1A = 0;
TCCR1B = (1<//TCCR1B = (1<
sei(); //włącz przerwania globalne

while(1){
LED2_TOG;
if(pomiar_gotowy){
ilosc_cykli = 65536 * ilosc_przepelnien - start_A + koniec_B;
czestotliwosc = F_CPU / ilosc_cykli;

lcd_locate(1, 0);
lcd_int(czestotliwosc);
lcd_char('.');
lcd_int( ( F_CPU % ilosc_cykli)/1000 );
lcd_str(" ");
lcd_locate(1, 13);
lcd_int(ilosc_przepelnien);
}

start_stop = 1; //ustawiamy początek pomiaru
pomiar_gotowy = 0; //zerujemy flagę końca pomiaru
TIMSK1 |= (1<_delay_ms(500);//pomiary co pół sekundy
}
}

ISR(TIMER1_CAPT_vect){ //Obsługa zdarzenia na ICP1

static uint16_t ICR1_aktualny; //zmienna = wartość ICR1
ICR1_aktualny = ICR1;//odczytaj stan licznika
if ( start_stop == 1){//czy to początek pomiaru?
//uruchamiamy zliczanie przepełnień Timer1
//TIFR1 &= ~(1<TIMSK1 |= (1<ilosc_przepelnien = 0;//zeruj licznik przepełnień Timera1
start_A = ICR1_aktualny; //zapamiętujemy stan licznika na początku pomiaru (start_A)
} else
if ( start_stop == 2){ // początek następnego okresu i koniec pomiaru
TIMSK1 &= ~( (1<koniec_B = ICR1_aktualny; //zapamiętujemy stan licznika na końcu pomiaru
pomiar_gotowy = 1; //zakończono pomiar - pokaż wynik pomiaru
}
start_stop += 1;
}

ISR(TIMER1_OVF_vect){
TIFR1 &= ~(1<ilosc_przepelnien += 1; //powiększ licznik przepełnień Timera1
}[/syntax][/syntax]

Pozdrawiam Zbych

Statystyki: Napisane przez Jachimo — 29 lip 2021, o 08:53