Witam!
W "Dawcy czasu - mikrostacja pogodowa" wykorzystuję czujnik BMP180 i DHT22. Gdy ich obsługę powierzam zdarzeniu RTC_EVENT() wszystko działała dobrze. Postanowiłem napisać zdarzenie dla każdego z nich ( BMP180_EVENT() i DHT22_EVENT() ) i zaczęły się schody tzn. zdarzenia działają, ale bardzo opóźniają pętlę główną programu co wydłuża czas do następnej synchronizacji np. ma być co 10min., a jest co 13 i im. dłuższe czasy tym opóźnienia większe. Proszę o sprawdzenie zdarzeń i prawidłowości wywołania funkcji callback.

bmp180.c

dht22.c

main.c


Funkcje własne wywoływane przez zdarzenie:


Pozdrawiam

Witam.
Proszę o sprawdzenie prawidłowości rejestracji i wywołania w/w funkcji callback. Czy takie podejście do obsługi tych czujników jest słuszne i ma szansę działać prawidłowo. BMP180_EVENT() i DHT22_EVENT() wywoływane są w pętli while(1) bardzo wolno jak na szybkość obiegu tej pętli (nie wiem dlaczego). Dioda wstawiona w ciało eventa zmienia stan co ok. 0.5s. (powinna świecić non-stop tylko trochę słabiej). Próbowałem timerami programowymi zwolnić częstość odczytu z czujników w evencie do co 3s, ale to nic nie zmienia. W związku ze zwolnieniem pętli zmniejsza się tempo wywołań w pętli while(1)
co bezpośrednio rzutuje na odliczanie czasu do synchronizacji. Miało być nie blokująco, a blokuje
Pozdrawiam

Ja bym zaczął od sprawdzenia na którym EVENT'cie jest opóźnienie
Masz ich dodatkowo trzy
IR_EVENT();
BMP180_EVENT();
DHT22_EVENT();
Od tego bym zaczął.
najpierw wywal wszystkie 3 - sprawdź co ile odświeża czas potem dołóż pierwszego, itd.
Ograniczy to w szybki sposób zakres poszukiwania błędu.

Dzięki. Wprowadzenie dwóch eventów BMP180_EVENT() i DHT22_EVENT() rozłożyło synchronizację. Pozostałe eventy są bez wpływu na nią:
RTC_EVENT(), UART_RX_STR_EVENT(uart_buf), IR_EVENT().

a spróbuj jeszcze sam BMP180_EVENT()??
oraz potem sam DHT22_EVENT() - bo jeden z nich spowalnia a nie oba na raz.

Próbowałem wczoraj. Obie spowalniają, ale pojedynczo dużo bardziej DHT22_EVENT() niż BMP180_EVENT(). Jedynie ich zakomentowanie w while(1) przywraca sprawność programu. Może jest jakiś problem z wywoływanie callbacków, którego nie widzę?

tak mi się nasuwa jeszcze pytanie - a co jest jak zostawisz sam EVENT DTH22 i zakomentujesz tą linię
// dht_gettemperaturehumidity(&temperature, &humidity);

co prawda nie pobierze Ci wyników, ale pokaże czy callback spowalnia czy nie

Dziękuję Ci bardzo za zainteresowanie. To jest dobry pomysł z zakomentowaniem operacji dokonania pomiaru. Gdy wrócę do domu wieczorem (ok. 21) przetestuję i dam znać. Nie bardzo mi się podoba sekwencja: DHT22_EVENT() -> pomiar -> callback -> odczyt. Musi być przecież odpowiedni czas na start pomiaru i odczyt. Dobrze by było może zainicjować pomiar w czasie eventu, ale wywołanie funkcji callback odwlec w czasie, aby czujnik zmierzył (potrzebuje ok. 2, sekund tak wyczytałem). Ale eventy nadchodzą tak szybko... Zmiany wilgotności czujnik rejestruje, ale z dużym opóźnieniem są wyświetlane gdy czynnik sprawczy już nie działa co może świadczyć o problemach z czasami pomiar-odczyt. Przykładowy blokujący kod w c dla tego czujnika obejmuje pomiar i opóźnienie 1500ms w pętli while(1).

Sprawdziłem. Oba eventy spowalniają program, niezależnie co jest w ich ciele. Zakomentowanie pomiarów ciśnienia i wilgotności nic nie zmienia.

Po 1: Wprowadź sobie kilka timerów programowych lub jeden wielki 32 bitowy i w eventach czytaj czujniki co określony czas (niewiem jakiego potrzebujesz może być 10ms może być 10s) teraz wszystko jest aktualizowane "ile pętla dała "
Po 2: DHT22 wymaga aktualizacji jak już wspomniałeś co nie mniej niż 1.5s - to wieczność. Wywal je i jak już mówiłem odczyty rób z uwzględnieniem timera. Można też bardzo ładnie te czujki obsłużyć przerwaniami i jednym globalnym timerem programowym - ale o to już nie męczę bo to bardziej skomplikowane.
Po 3: Typy zmiennoprzecinkowe też zwalniają jednak gdy będzie całość czytana co określone interwały czasowe to nie powinno być to wielkim problemem.

_________________
sig off ;(

Bardzo dziękuję. Zaraz ogarnę eventy timerami i dam znać. Napisz proszę o tej bardziej skomplikowanej obsłudze DHT22 - mam otwarty umysł i myślę, że ogarnę temat z Twoją oczywiście pomocą (będę wdzięczny). Rozumiem, że LED_TOG co 300-500ms w pętli while(1) obciążonej kilkoma eventami to normalne zjawisko?

Co do DHT to działało to w ten sposób że timer 1 był skonfigurowany jako ICP i wyzwalany zboczem opadającym. W obsłudze przerwania porównywałem wartość aktualną timera z poprzednią, dzięki czemu wiedziałem ile trwał jeden bit i czy był on 1 czy 0. Właściwie po sekwencji startu całość działała "automatycznie" i po odebraniu 40 bitów była ustawiana flaga i w pętli już można było odczytać gotową temperaturę.
Co do 1 obiegu pętli to raczej nie jest to ok. chyba że tak zmula ci obsługa NTP. Po co pobierać czas non stop starczy raz na kilka sekund czy nawet minut.

_________________
sig off ;(

Dziękuję. Czas nie jest pobierany non-stop tylko w odstępach określonych w funkcji GetNTPEvent(...). Niestety po włączeniu do pętli while(1) eventów BMP i DHT22 timer programowy, który napędzał odliczanie w tej funkcji czasu do synchronizacji całkowicie się rozjechał. Postanowiłem nie walczyć z tym problemem (po wielu próbach) i do odliczania czasu wdrożyłem timer sprzętowy.
Pozdrawiam