Po raz kolejny patrzę na kod, a błędu doszukać się nie mogę...

Sytuacja wygląda następująco:
Buduję prosty licznik Geigera do monitoringu promieniowania tła (dodatkowo będzie też posiadał elektroniczny barometr i termometr). Wyniki mają być raportowane za pośrednictwem sieci LAN. Druga strona otrzymuje żądaną wartość po wysłaniu komendy AT a pakiecie UDP. W przyszłości dodam też obsługę protokołu HTTP.
ATmega jest taktowana sygnałem zegarowym o częstotliwości 12,5 MHz, pochodzącym z ENC28J60.

Od strony sprzętowej wszystko działa. Przetwornica wytwarza właściwe napięcie, tuba reaguje na przelatujące cząstki, wzmacniacz wysyła impulsy na wejście T1 ATmegi328. Rejestr TCNT1 inkrementuje się po każdym impulsie. Działa też komunikacja po Ethernecie. Zabrałem się więc za pisanie właściwych procedur obsługujących pomiar promieniowania. Na początek poszło zliczanie wartości CPM (zliczenia na minutę).

Kod zaprezentowany poniżej.

Konfiguracja Timera0, tryb CTC, przerwanie mniej-więcej co 1 milisekundę.


Samo przerwanie wygląda następująco:


Zmienne millis i seconds są zdefiniowane jako volatile w pliku main.c, natomiast sześćdziesięcioelementowa tablica geiger_pulses w osobnym pliku geiger.c. Oczywiście w geiger.h znajduje się jej deklaracja jako extern. Oczywiście sama tablica również jest volatile.

Do pobierania aktualnej wartości CPM służy następująca funkcja z pliku geiger.c:


Globalna obsługa przerwań jest włączona za pomocą sei()

Wszystko wydaje się być w porządku, a jednak nie działa. Wszystko wskazuje na to, że nie wykonuje się albo samo przerwanie, albo zawarty w nim warunek. Funkcja cpm() za każdym razem zwraca 0, natomiast rejestr TCNT1 inkrementuje się cały czas, zliczając kolejne impulsy, tymczasem powinien być zerowany co sekundę.

Skoro kolega zastanawia sie czy nie działa mu przerwanie czy warunek w środku to może należało by spróbować najprostszej formy sprawdzania kodu: http://mirekk36.blogspot.com/2014/04/puapki-programowe-debuger-na-jednej.html

Za chwilę sprawdzę z diodą. Na chwilę obecną i tak nie ma to wielkiego znaczenia, bo bez względu na to czy ustalę jedną czy drugą sytuację, nie mam zielonego pojęcia gdzie szukać przyczyny.

Na razie jednak zauważyłem inną rzecz.
Mianowicie z ciekawości zajrzałem do datasheeta ATmegi 328P, a dokładnie do tabelki z rozpiską wektorów przerwań.
Widzę tam, że "TIMER0 COMPA" odpowiada wektor nr. 15.
Atmel Studio wyświetla mi natomiast następującą definicję:
#define TIMER0_COMPA_vect _VECTOR(14)

Zgodnie z dokumentacją układu, wektor 14 odpowiada przepełnieniu Timera1.

Błąd jest w dokumentacji? Autorzy Atmel Studio aż tak bardzo by namieszali? A może po prostu numerki są inne niż w datasheecie, ale odnoszą się do tych samych zdarzeń?

UPDATE:
Już prawdopodobnie widzę przyczynę. Pomieszała mi się lokalizacja bitów w rejestrach konfiguracyjnych. Wgrywam nowy wsad i zobaczę, czy to jedyny bug.
Przepraszam za zamieszanie.