Witam. Aktualnie realizuję projekt obrotomierza oparty na zliczaniu impulsów pochodzących z transoptora (z wcięciem), w którym sygnał wejściowy jest modulowany poprzez poczwórne śmigiełko, które z kolei obraca się na silniku DC. Dla jasności wrzucę schemat elektryczny PCB oraz zrzuty z oscyloskopu dla przebiegu na nóżce 4 ATmegi8 dla różnej prędkości obrotowej:



Bibliotekę LCD wykorzystałem z bluebooka z niewielkimi (nieznaczne obcięcie funkcjonalności oraz dostosowanie do wyświetlacza 24x2) zmianami dlatego też wrzucam tylko main.c:



Dla jasności - wyświetlacz działa poprawnie, program bez problemu się kompiluje (brak nawet ostrzeżeń) ale wyniki, które wyrzuca są idiotyczne. Jak widać na zrzutach f_max to ok 400Hz a program wyrzuca liczby które nijak się mają do stanu faktycznego. Wydaje mi się, że jest to związane z przekraczaniem zakresu i przekręcaniu się (wartości ujemne się pojawiały), ale chyba nie tylko.

Ktoś mógłby mieć problem ze zrozumieniem jak ogólnie miałoby to działać więc wrzucę krótki opis w którym przedstawię na jakiej zasadzie miało to działać:
1. timer1 służy do odświeżania wyświetlacza co ok. 3s (to się udało)
2. timer0 służy do zliczania impulsów (czasu) pomiędzy dwoma kolejnymi zboczami narastającymi
3. w oparciu o ten czas funkcja calc () wyznacza prędkość obrotową wyrażoną w tysiącach obrotów na minutę - 250 bo na 1000 stanów wysokich tylko 1/4 to obroty (patrz wyzej wzmianka o śmigiełku)


Nie mam żadnego doświadczenia w programowaniu mikrokontrolerów więc mógł przydarzyć mi się nawet najprostszy błąd ale ja nie potrafię go znaleźć. Być może problem leży również w czasie potrzebnym na inicjalizację timerów lub w jakichś innych zależnościach czasowych, o których nie pomyślałem.

Gdyby ktoś mógł spojrzeć na kod i przeanalizować go oraz wskazać miejsca ewentualnych błędów oraz w jaki sposób można je poprawić byłbym bardzo wdzięczny.

Z góry dziękuję za odpowiedź.

Pozdrawiam

Kody wklejamy przy pomocy syntax=c - Różowy J.

Po kolei odniosę się do każdej opinii:
1.Po pierwsze nie widzę informacji o taktowaniu a to ma wpływ na sprawdzenie twoich przeliczeń.
ATmega jest taktowana 1MHz z wewnętrznego oscylatora RC

2.P drugie patrząc na oscylogramy to narastanie sygnału jest bardzo bardzo słabe (co może mieć wpływ na pomiary) zobacz że nawet nie dobija do okolic 5V. Zmniejszył bym ten rezystor 10k żeby poprawić narastanie.
Widze że jest słabe dla maksymalnej częstotliwości, ale czy to może mieć fundamentalny wpływ na zliczanie zboczy? Co do tego, że nie osiąga 5V - zawsze osiąga min. 4V a przy 4V procek chyba powinien złapać że już stan jest wysoki?

3.Jeżeli chodzi o kod. Wywołujesz funkcję display z parametrem choć jej definicja jego nie zawiera. Wydaje mi się że to kompilator powinien wyłapać a piszesz że kompiluje się bez warningów.
Fakt, teraz to zauważyłem. Jednak ECLIPSE nie protestował (też mnie to dziwi).

4.Nie wnikam w przeliczenia ale jeśli nie spodziewasz się wartości ujemnych (bo w tym przypadku to ciężko o nie) to stosuj uint16_t (int bez znaku) licznik w timerze ma zakres 0-65535 ale jeśli przypiszesz jego wartość do zmiennej int (ze znakiem) to spodziewaj się dziwnych efektów po przekroczeniu "górnego" zakresu dla int.
OK, ale w tym timerze (jak mniemam masz na myśli timer1) problemów żadnych nie mam - jego jedynym zadaniem jest dbanie o odświeżanie ekranu co 3 sekundy i to robi poprawnie.

5.Kolejna sprawa, samo w sobie nie powinno mieć wpływu ale lepiej tego pinować. Timer0 jest 8bitowy 0-255 a Ty wartość tego licznika przypisujesz do int (ze znakiem), jak wspomniałem nie powinno mieć wpływu ale jest marnotrawieniem pamięci i czasu procesora
Zmieniłem int na uint8_t ale efektu nie ma.

6.Lecz największy problem widzę w samym zliczaniu obrotów.
Nie wiem czym się sugerowałeś ale jakoś nie widzę tego mechanizmu. Dla mnie na chłopski rozum musisz policzyć ilość "zajść" w jednostce czasu i potem to przemnożyć lub podzielić by uzyskać wynik w odpowiedniej "skali". Czyli np. w przerwaniu INT zliczasz ilość wystąpień (instrumentujesz zmienną bufor) a w przerwaniu timera który odmierza określony czas dokujesz obliczeń po czym zerujesz zmienną bufor by znowu mogła być liczona. W takim przypadku mozęsz też uśredniać wyniki i co 3 sek. pokazywać uśredniony wynik.
Zgodziłbym się z tym, że uśredniony wynik będzie ok, ale jeśli przy stałej niskiej prędkości obrotowej wyrzuca liczby typu: 125, 686, 437 (jak losowe) i robi coś o bardzo podobnego dla dużej prędkości to trudno oczekiwać że wartość średnia będzie miała sens. A poza tym wydaje mi się, że mój sposób tzn. mierzenie czasu między dwoma kolejnymi zboczami narastającymi nie jest zły (przynajmniej w założeniu) i wyświetlacz będzie pokazywał prędkość chwilową (można uznać, że spróbkowaną) a nie uśrednioną. Jeśli jednak prędkość będzie przez kilka sekund stała powinien pokazać dokładnie to samo.

7.A pomijając już to wszystko to kod jest nieprzemyślany i niepotrzebnie wiele rzeczy się w nim dziej, już teraz masz z nim problemy a jest krótki.
Możesz powiedzieć w czym jest nieprzemyślany i co niepotrzebnego się w nim dzieje? Rzucenie sloganem "masz zagmatwany kod" jest proste ale ja osobiście nie widzę, żeby był on niepotrzebnie skomplikowany i złożony w stopniu większym niż konieczny.

Liczę na kolejne komentarze i rady.