Działało by już dawno.

Akurat w tym przypadku będzie wywoływana często. Jeśli czujniki są odczytywane co 0,8s i wpływają, a wpływają, na regulację obrotów, to w ciągu godziny funkcja będzie użyta jakieś 4 tyś razy.
Wszystko zależy od algorytmu przetwarzającego odczyty na prędkość.
Zasadne byłoby wprowadzenie porównywania poprzedniego odczytu z nowym.

Nie dziwo, że nie działa. Inne rejestry.
To jeszcze opisz z grubsza swój program, jak wcześniej sugerowałem.

oprawcafotografii pisze:Sprawdziłem drugą płytkę solo - bez podłączonego czegokolwiek i to samo.

Trochę dziwne, że na dwóch. Kiedyś nabyłem tanie "arduino" pod GRBL i miesiąc szarpałem się z niedziałającym krańcówkami. Uszkodzone dwa piny w procku - wymiana na nowy A328 i działa.

tuxcnc pisze:Jeśli ktoś nie kuma

No właśnie. Tryb CTC licznika znacznie różni się od normalnego - przepełnienie i przerwanie. Zresztą i ten tryb też można modyfikować.
I tak się właśnie kończy używanie kiepskich bibliotek i goo..ego kodu - zawsze brakuje mocy. W końcu przejście na cortex-y: M0, M3 itd.
Jak ściganie się na zaciągniętym ręcznym. Idąc tym tropem, to się okaże, że głupią pompkę trzeba sterować "potężnym Ryzenem i RTos-em".
Funkcja kol. TOP67 wydaje się być prawidłowa - choć nie doskonała. Nie mam wolnego Arduino ( ani komu podciągnąć ), aby sprawdzić.
Co do niedoskonałości:
-pozbyłbym się wszystkich zmiennych typu float. AVRy nie mają koprocesora matematycznego. Co prawda kompilator sobie z tym poradzi, ale generuje bardzo długi kod.
-Zmiana wartości licznika i ew. podzielnika powinna następować w ściśle określonym momencie - przy zerowaniu.
Ponieważ program dla pompki jest raczej prosty i liniowy, zastosowałbym flagę przepełnienia - nie przerwanie, i w pętli oczekiwał na jej wystąpienie. Ewentualne opóźnienie wysłania danych na wyświetlacz nie będzie miało żadnego znaczenia.

Przy 1 Hz powinien być 0,5 sek.
Podłączyć leda albo oscyloskop i sprawdzić, czy na pinie jest sygnał.
Na przerwaniach już było i się kleszczy.

Mam te ( i nie tylko te ) książki.
Wszystko zależy od potrzeb. Już widzę, jak pakuję mały program sterujący- jakieś 300b - do xmegi. Tiny 13 było za duże.
Zegar to nie wszystko - przy kiepskim kodzie niewiele pomoże. Wg mnie lepiej poznać "wnętrzności" i wykorzystywać je do maksimum. A łatwiej nauczyć się na prostszych układach.
Ilu amatorów jest w stanie zapełnić choćby te 32kb flasha - programem, nie danymi ?

Avalyah pisze:Atmega już bez sensu, dużo lepsze są Xmegi. W programowaniu różnica prawie żadna, a możliwości nieporównywalne.

Chyba nie wiesz, co piszesz .
Dla amatora - hobbysty, zwłaszcza początkującego, to jak zderzenie ze ścianą ( albo brzozą ).
Fascynacja możliwościami a ich wykorzystanie to lata świetlne.
Sama tylko obsługa portów I/O to jakieś 20 rejestrów.

TOP67 pisze:Zabrałem synowi Arduino ledwo tydzień temu.

Oddaj dziecku zabawkę .

Ciągle jeszcze myślisz " arduinowo " i ograniczasz się do jednego układu. Spójrz na nową wersję - ATmega 328 PB.

Avalyah pisze:W przypadku takiego prostego zastosowania raczej nie ma to sensu

Chociażby usypianie procka na czas oczekiwania na kolejne pomiary. Kolejny timer regularnie wybudzający - stałość czasowa pomiarów. Może akurat tu nie jest to aż tak istotne, ale warto o tym wiedzieć.

TOP67 pisze:Starałem się napisać funkcję jak najprostszą w użyciu.

Absolutnie nie mówię, że funkcja jest zła. Ale jak już zaszedłeś tak daleko, można ją udoskonalić. Wyobraź sobie, że używasz trzech timerów.
Wystarczy jedna funkcja "obliczająca", a wyniki wpiszesz do odp. timerów.

TOP67 pisze:Z tego co pisał zainteresowany, wywołuje to co kilka godzin.

Niestety nie. Program działa kilka godzin. Odczyt z czujników temp. i zakres obrotów sugeruje ..
Zresztą autor sam wspomina o regulacji obrotów ( kilka stron wcześniej ). I to co ok 0,8 sek .

Fajna funkcja, taka typowo arduinowa .
Rozdzieliłbym na dwie - osobno część obliczeniową, osobna funkcja wykonawcza.
W przypadku układów z większą ilością liczników, jedna funkcja wylicza, inne wpisują do rejestrów.
Dodałbym też funkcję awaryjnego, szybkiego zatrzymania licznika.
Deklaracje trybu pracy, użytych pinów wyjściowych dałbym na początku programu. W trakcie pracy timer raczej nie zmienia trybu.
W tej postaci funkcja jest dobra dla jednorazowego uruchomienia timera, jeśli trzeba zmieniać częstotliwość, niepotrzebnie włącza te same funkcje za każdym użyciem.
Dodałbym jeszcze, ale nie wszystko od razu.

Przydałby się ogólny zarys programu, co robi, co z czym, kolejność. Może coś jeszcze da się przenieść z warstwy programowej na sprzętową.