Witam.

Jestem bardzo początkującym jeżeli chodzi o język C. Całe lata bawiłem się na bascom-ie tworząc różne projekty.
Dość dawno nabyłem bluebooka oraz greenbooka. I nadszedł ten czas kiedy chcę całkowicie przejść na C.
Wszystkie układy które wykonałem, postanowiłem przerobić na C, aby podnieść swoje umiejętności.
Układami są sterowniki domu tj. sterowniki rolet, oświetlenia, pieca CO, bram, markizy. Wszystkie sterowniki gadają po RS485 dodatkowo jest moduł, który komunikuje się ze smartfonem. (B4A)
Komunikacja po RS485 udała się bez problemów dzięki bibliotece MkMultiUart od Mirka za co wielkie dzięki

I teraz przejdę do tematu na którym utknąłem totalnie. Może to banał, ale dla mnie jako początkującego niekoniecznie.

Chodzi o obsługę przycisków.
Do układziku są podłączone przyciski dotykowe (osobny układzik) w ilości 8 przycisków (2x4 przyciski)
I teraz sedno sprawy. Każdy z tych przycisków działa na przytrzymanie lub kliknięcie. Dodatkowo, gdy przycisnę parę (czyli dwa na raz) również jest dodatkowa funkcja.
W bascomie rozwiązałem to tak, że przy naciśnięciu na przycisk program przechodził do podprogramu i tam liczył czas w milisekundach. (brak drgań styków gdyż przyciski mają dodatkowy układ z wyjściem OC)
1. Naciskam i puszczam przycisk (naciskając przycisk wchodzi w podprogram, ale wychodzi z pętli gdy przycisk jest puszczony
2. Naciskam i trzymam przycisk (gdy trzymam przycisk, program liczy do 200ms i gdy dojdzie do 200ms wychodzi z pętli)
3. Naciskam przycisk i przed upływem tych 200ms, wciskam drugi przycisk (gdy są 2 wychodzi z pętli)

Nie wiem czy dość dokładnie wytłumaczyłem.
Chciałbym, aby było to dobrze napisane, bo z tego co mi wychodzi to kilkadziesiąt linijek kodu.

Proszę o pomoc jak mam wybrnąć z tematu.
Dzięki i pozdrawiam.

Witam w świecie C.

Hmm, jakie masz jeszcze założenia co do głównej pętli, ma pracować czy możesz porzucić główna pętle i niczego nie sprawdzać wykonywac i całkiem z programem do przycisków uciec w inną petle/program.
Jesli ma pracować główna pętla (główny program) to przyciski na flagach zrób.
Dla zachowania czytelności głównej petli obsługę przycisków wsadź do funkcji i sprawdzaj w poolingu, możesz dołożyć licznik programowy żeby odliczać czas(ilość obiegow petli) długości wciśnięcia przycisków. Itp...

@rybok_999 tak jak zrobiłeś w Bascom tak samo może zrobić w C ale to złe rozwiązanie. Blokowanie programu na 200ms to zdecydowanie zły pomysł. Zrób sobie przerwanie od timera co 1 lub 10ms i w nim sprawdzaj jak długo przycisk jest naciśnięty. Program główny będzie tylko sprawdzał jaki był czas przyciśnięcia przycisku. Tak to się powinno realizować, nie ważne w C, Bascom, Pascal, Asm czy inny język.

Pętla główna może być z opóźnieniem gdyż mam jeszcze do obsługi dane po RS485 ale tam jest bufor więc nie ma problemu.
Napisałem coś takiego


Nie testowałem czy to działa ale uważam że jest to złe. Nie wiem jak to dobrze zrobić żeby to wyglądało i działało

Co do kodu to kompletnie złe podejście. Zrób na przerwaniach bo prosisz się o kłopoty. Możesz mieć błąd, którego będziesz szukał bardzo długo.


Problem jest, bo mała zmiana w sofcie może spowodować, że program zacznie się sypać zwłaszcza, jak jeszcze gdzie masz podobne "blokowanie" programu.
Jakiej prędkości komunikacji po RS485 używasz? Jak długie są ramki? Jak często w ciągu sekundy przychodzą dane po RS485?

------------------------ [ Dodano po: 9 minutach ]

Na start masz kawałek kodu

W "timKey1" masz czas przez jaki był trzymany przycisk, w "tk1" jak długo aktualnie naciśnięty. Wszystko co kombinujesz w pętli głównej możesz zrobić w przerwaniu. Bardzo dużo programów można napisać tak, ze pętla główna to

i często są one prostsze niż dziesiątki "if" w pętli głównej.

Używam prędkości 9600


Wysyłam 4 znaki np. "TP01"


Dane przychodzą w momencie przyciśnięcia każdego przycisku w domu. Około kilkanaście razy w ciągu doby. Dodatkowo raz na minute dane z czujników temperatury, wilgotności. Ew, sterownika z podajnika pieca CO. Reasumując bardzo rzadko.


A nie można zrobić obsługi tych przycisków w jakimś osobnym pliku ? Oczywiście dużo lepiej było by na przerwaniach tylko pytanie czy dam rade.

Nie chce wrzucać programu do sterownika którego wcześniej nie sprawdze w garażu układzie testowym bo nic w domu nie będzie działać

Dzięki za pomoc testuje dalej

Transmisja 4 znaków przy 9600 8N1 trwa ok 4ms. Blokujesz program na 200ms. Ile znaków może przepaść zakładając, ze masz fifo na dwa bajty? Mnie wychodzi jakieś 189 znaków.
Masz bufor na odebrane dane z UART? Jak duży?
Możesz wyliczyć prawdopodobieństwo, będzie małe ale będzie. Błąd praktycznie nie do znalezienia, zwłaszcza przez początkującego tym, bardziej, ze zakładam iż takich "kwiatków" jest w programie więcej.


Można ale na początek nie polecam bo pojawią się problemy z zakresem widoczności zmiennych.


Używałeś przerwań w Bascom?

Tam mam bufor 20 znaków (ustawione tylko żeby było, działa więc nie kombinowałem)
Teraz chce bardziej profesjonalnie podejść do tematu.


Tak, ale tylko w momencie naciskania przycisku. Niestety blokuje.



Tak używałem ale wewnętrznych w formie timera. Do zliczania sekund np. przy otwieraniu/zamykaniu rolet.

Czyli 10 razy za mały.


Można by zwiększyć bufor zakładając najgorszy przypadek ale w ten sposób to RAm może zabraknąć zwłaszcza w AVR.
Profesjonalne podejście to przerzucenie max zadań na sprzęt (np do WS2812 SPi lub UART a nie "machanie pinem"), max wykorzystanie DMA (jeśli jest) przerwań. Wykorzystanie RTOS ale to raczej nie na AVR, mają mało RAM, timerów, dlatego do RTOS używa się watchdoga co rodzi ograniczenia.


Dlatego pisałem, ze prawdopodobieństwo małe, jednocześnie gdy paczka zostanie stracona to błąd jest bardzo ciężki do znalezienia

Pętla główna powinna wykonywać się najszybciej jak to możliwe i jak przeważnie z czasami rzędu ms czy ostatecznie nawet dziesiątek ms można się przeważnie zgodzić tak setki ms to już gruba przesada i przeważnie rodzi różne problemy.


Więc dasz radę. Ustaw timer na 1ms i już możesz zacząć pisać soft.
Przydałby się debuger sprzętowy, Bascom czegoś takiego nie ma więc dla Ciebie to nowość. W AVR zdecydowanie najlepiej działa JTAG więc polecam iść w tym kierunku.

Można, ale nie znaczy to, że to dobry kierunek i absolutnie nie polecam takiego stylu pisania. Skoro pętla główna jest pusta to po co przerwania? Przenieśmy wszystko do pętli głównej dajmy delay'a symulującego podział timera i praktycznie na to samo wyjdzie
Zasada jest prosta - przerwania mają się wykonywać jak najkrócej! Nie można tam na pałę umieszczać wszystkiego co się da. W moich programach czasem w przebraniu jest tylko jedna niezbędna linia żonglująca jednym bajtem żeby było jeszcze szybciej i to często wystarcza w wielu sytuacjach.

_________________
http://www.sylwekkuna.com

Mamy tu konkretny przypadek, co za różnica czy przerwanie wykonuje się 5 czy 25us co 1ms? W pierwszym przypadku, wychodzi mi obciążenie CPU przez przerwanie na poziomie 0,05%, w drugim 0,25%. Odczuwalna różnica?
25us przy taktowaniu 16MHz to naprawdę bardzo rozbudowana procedura przerwań, natomiast takich poniżej 5 jest raczej mało.

Pchanie tego co można robić na przerwaniu to jest dopiero błąd. Później wychodzą programy jak autora, które działają bo działają, jak pojawią się problemy ciężko będzie je znaleźć i im zaradzić. Ewentualna rozbudowa programu może powodować, że wszystko się wali. Spowoduje to, ze dodanie prostej funkcjonalności spowoduje gruntowną przebudowę programu. Pytanie po co skoro można to zrobić lepiej?
Jak już ktoś ma ochotę pchać co się da do pętli głównej to niech użyje RTOS ale AVR się do tego nie bardzo nadaje.

Znam wiele komputerów/systemów od 8, przez 16 do 32 bit. Obsługa klawiatury (repeat i takie tam), łącznie z jej buforem jest realizowana na przerwaniach. Czy to nie daje do myślenia? Microsoft może się mylić ale pozostali producenci także?
Wszyscy się mylą obsługując klawiaturę na przerwaniach?

Kurcze... właśnie w tym momencie wszystkie moje programy przestały płynnie obsługiwać, a niektóre całkowicie ignorują przyciski. Nie wiedziały, że trzeba ich w przerwaniach badać, a wszystkie są w pętli głównej... Co robić!

_________________
http://www.sylwekkuna.com

A w moich, mimo, że bez przerwy wysyłam dane po SPI z prędkością 10Mb/s program w czasie rzeczywistym (max 1ms) reaguje na zdarzenia czy to z klawiatury, czy UART, I2C i co tylko zapragnę.

Można się męczyć i napisać obsługę klawiatury w pętli głównej opierając się o maszynę stanów i flagi timera. Co jednak zrobić, gdy mam czasochłonne obliczenia zmiennoprzecinkowe trwające np 20ms? Jak program ma zareagować na zdarzenie w ciągu max 1ms?

Można pisać soft do migania diodą i 200ms w lewo czy prawo nie gra roli, można też pisać soft, gdzie reakcja musi być w max 1us. W takim przypadku fuszerki i półśrodków nie ma a jak raz się napisze dobra funkcję to się jej używa w wielu projektach . Jedna robota a mniej problemów w przyszłości. Raz sobie zrobiłem obsługę LCD i WS2812 przez DMA i teraz nie mam problemu z tym, ze dane do LCD lecą 30ms, do WS2812 20ms. Z punktu widzenia softu są to us.
Tak samo obsługa klawiatury, zrobiłem raz a dobrze. Likwidacja drżenia styków, pomiar czasu, dwuklik itp. Z punktu widzenia programu użytkownika dostaje w zmiennej gotowe dane. Obciążenie CPU przez przerwania to jakieś promile. Bardzo często czas obiegu pętli głównej to setki ns. Owszem, to ARM ale gdy pomnożyć czasy przez 50 czy 100 uzyskamy realne czasy dla AVR.

------------------------ [ Dodano po: 4 minutach ]

Co do sarkazmu, to już wiele razy się z tym spotkałem, że "cudowny" program zawieszałem w kilka minut albo doprowadzałem do nieprawidłowej pracy jak nie włączanie agregatu lodówki mimo iż temperatura jest za wysoka. Wieszanie się funkcji I2C, na AVRmega i STM32F1xx. Najwdzięczniejsze do pokazania autorowi programu, który uważa się za najlepszego, są magistrale I2C i 1-Wire a na Arduino to już norma, że się wyłożą.
Jak to nie skutkuje, to ESD, wahania napięcia zasilania i delikwent wychodzi ze spuszczona głową, bo właśnie dostał zimny prysznic i już wie, że jego "cudowny" soft i urządzenia nadaje się do sprzedaży tylko przez chińczyka gdzie realnie nie ma jak złożyć reklamacji nie mówiąc od odzyskaniu kasy za kupione badziewie.

Panie kolego - podejścia są różne a nawet bardzo różne i nie ma że wszyscy robią obsługę przycisków na przerwaniach a 1% nie ....

Rozwiązań jest tyle ilu programistów - to jest PODSTAWA i proszę nie oceniać innych że coś źle robią tylko dlatego, że kolega patrzy przez z kolei czubek własnego nosa.

Krótko mówiąc osoby, u których program główny wygląda tak:



to nie dziwota - że wszystko tną na przerwaniach i chociażby nie wiem co to tego typu podejście na prockach bez priorytetów przerwań szczególnie, a procki AVR do takich nie należą, zawsze też się ZARŻNĄ na śmierć jak tylko będą np chcieli zrobić większy projekt tylko "na przerwaniach" .... Owszem bywa to dobre podejście jak ktoś się bardzo dobrze orientuje jak przerwania działają, jak robić ew wstawki asemblerowe .. itp .. Jeśli działa - a w wielu przypadkach przecież działa - sam widziałem tak pisane programy ... to jednak np dla mnie jest to masochizm niestety tak troszkę ... ale podkreślam dla rozrastających się projektów ...

Żeby nie być gołosłownym - zrób Pan program który będzie obsługiwał np FAT32 plus stos TCP z odwtarzaniem np plików dźwiękowych - TYLKO na przerwaniach ... to taki mały czelendż

A co do obsługi I2C - co za problem ? Toż normalnie robi się obsługę podobnie jak UART ... czyli buforowanie a sama główna obsługa przesyłu/odbioru na przerwaniach i działa ślicznie !

Z 1wire na 8-bitowcach zwykle trzeba się więcej pogimnastykować ale tu też można podejść na kilka różnych sposobów i na pewno nie TYLKO na przerwaniach ...

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Do tego jest RTOS. Czytanie FAT32 w programie głównym. Jak sie uprzec można zrobić to na przerwaniach ale popularne biblioteki nie są do tego przygotowane, w praktyce trzeba cała przepisać więc nie warto.
TCP na przerwaniach nie problem.


Zwieram drutem SCL do masy i 90% programów wykłada się. Podobnie w innych sytuacjach awaryjnych.
Jak się buduje jakiś tam zegarek, to nie problem ale jak program ma działać pewnie to funkcje wykrywające błędy, reagujące na nie zajmują czasem więcej kodu niż funkcje samej obsługi I2C.
Jest różnica, zabawka a urządzenie przemysłowe, które w przypadku problemów musi próbować ponawiać transmisję, obudzić do życia slave, który zablokował I2C wystawiając na SDA 0, zgłaszać błędy a nie wisieć do czasu aż użytkownik naciśnie reset a czasem uratyje tylko przez wyłączenie zasilania, bo reset nic nie daje, slave cały czas blokuje magistralę.


Jeśli blokowanie przerwań na 64us jest dopuszczalne to ok, a jeśli nie? Przy prędkości 921600bd w 64us może przyjść 6 znaków a nie jest to największa prędkość z jaka pracuję. Dla mnie 20MHz SPI w trybie slave (znak co 400ns) nie jest niczym nadzwyczajnym. Mimo, że wtedy odbiór odbywa się z użyciem DMA nie mogę sobie pozwolić na zawieszanie przerwań na więcej niż 1us, bo CS kończy cykl pracy DMA a master nie będzie czekał wieki. Nie mam wyjścia, albo rzeźba na przerwaniach ale po co się męczyć jak jeszcze Dallas, wydał AN z opisem jak to zrobić na UART? Używając UART, 1-Wire może działać na przerwaniach prawie nie obciążając CPU.

Wszystko zależy co się robi, miganie diodą, zegarek czy coś poważnego ale mając sprawdzone funkcje z poważnych projektów używam ich nawet w zabawkach. Bywa, że po RTOS sięgam do prostych projektów bo ułatwia prace. Fakt, trzeba się najpierw namęczyć i go poznać, ale bez pracy nie ma kołaczy.
Człowiek się namęczył i zbudował piłę spalinową aby się później nie męczyć. Mógłby się nie męczyć i dalej używać siekiery.
Samochód, samolot, kalkulator, to wszystko powstało dla wygody czasem z lenistwa, czasem dla zysku albo sławy.

Tak w przypadku 8-bitowców - RTOS to po prostu MEGA BZDURA - po prostu chore - no aż takiej odpowiedzi to się nie spodziewałem .... kompletny bezsens


Czyżby kolega znowu oceniał wszystkich przez czubek własnego nosa ? .... toż to kolejna bzdura , i to są aż DWA powody tego rodzaju BZDURY !

1. Totalnie bezsensowne założenie testu jednostkowego "zwieram drutem SCL do masy" .... Zdecydowana większość prostych układów embeded opierających swoją pracę na I2C nie ma racji bytu bez działania I2C a więc - czego ma dowieść tak bzdurny test ? zwarcie do masy ? Nie działa I2C to zwykle i tak działanie całego układu bierze w łeb - więc wszystko jedno

2. Co za Qurdę problem dorobić sobie obsługę I2C na przerwaniach z obsługą błędów - najprostszą obsługą błędów i jeśli system embeded przewiduje interfejs UI to wyświetlić taką informację

3. co za problem nawet w poolingu zrobić tak prostą obsługę błędów ?

To że większość programów w andruino czyli gotowców się wyłoży - to nie jest powód żeby mówić, że obsługa I2C to tylko w przerwaniach bo to niestety też bzdura.


haaalooo ... stooop - kolega niech się obudzi ! stooop mówimy o 8-bitowcach prostych bez DMA a nie zaraz o nie wiadomo czym - nie przesadzaj

Bo nawet na ARM można to dużo prościej zrobić


I bardzo dobrze - kto komu zabroni - ale jak mi powiesz że sięgasz po RTOS na zwykłych 8-bitowcach to ja powiem jak polityk że mijasz się z prawdą ....

więc zejdź na ziemie i nie porównuj tego czym ty akurat się bawisz na 32-bitowym STM do tego co możliwe jest do zrobienia na prostym ATmega8 - tylko proszę - nie wyjedź za chwilę z argumentem że STM jest tańszy bo ... no bo już szkoda będzie dalej nawet gadać

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Wiec podsumowując jak mam to zrobić? Sam już niewiem jaką iść drogą. Układy programowanie w bascom działają bez najmniejszych problemów ponad 2 lata. Chciałbym aby było dobrze zrobione ale przerost formy nad treścią mija się z celem.

Przede wszystkim jakie szacujesz max opóźnienia w pętli głównej od innych modułów programowych? Od tego zależy jaki sobie algorytm obrać. Jeśli opóźnienia będą na poziomie kilku/kilkunastu ms (przy przyciskach 20-30ms kompletnie nie ma znaczenia) to można spokojnie w głównej pętli robić, jeśli będzie to kilkadziesiąt ms to coś na wzór tego co pokazał @Semi z licznikiem w przerwaniach. Sposobów jest co najmniej kilka.

_________________
http://www.sylwekkuna.com

Przy zwarciu I2C program ma sygnalizować błąd, gdy zwarcie zniknie program ma podjąć pracę. Podobnie jak układ peryferyjny komunikujący sie po I2C zresetuje się. Niestety, bardzo, bardzo wiele programów zawiesza się w takich sytuacjach.


Jest to jakiś problem, bo programy często takiej obsługi nie mają.


Jak się raz na sekundę wysyła jeden bajt do PCF8574 to przerwania raczej nie są potrzebne, choć to trwa aż 180us, z mojego punktu widzenia program niepotrzebnie jest na ten czas zablokowany. Przerwania zajęły by CPU w sumie na max 40us (cztery przerwania po 10us) w przypadku AVR 16MHz. Czy 180us to długo? Pod koniec wypowiedzi napiszę, ze niedopuszczalnie długo i dlaczego.
Gdy po I2C podłączony jest LCD 128x64, bez użycia przerwań pętla główna jest zablokowana na ok 23ms (1024bajty przy 400kHz). Dla mnie to już wieczność.


Pisałem już o tym ale na mega1284 może miec sens o ile przełączanie tasków zrealizuje timer a nie watchdog.


Proste AVR Xmega mają DMA!


Bo tak jest a z faktami się nie dyskutuje.


Dlaczego 23ms czy nawet 180us dla mnie to wieczność?
Projekt, który kończę, miał być RTOS ale RAM zaczęło brakować więc rozwiązanie klasyczne. DMA (przerwania nie dadzą rady) odbiera dane po SPI max 9MHz. Owych danych (dla LCD) może być ponad 16kB ale może być tylko komenda 4 bajty.Zmiana strobu CS na L powoduje rozpoczęcie transmisji, równocześnie wystawiam BUSY. Koniec transmisji to zmiana CS na H, co wywołuje przerwanie. W przerwaniu ustawiam flagę i gdy program główny ma ją ustawianą dekoduje dane, które otrzymał po SPI (w praktyce zaczyna to już robić gdy CS zmieni się na L). Po zdekodowaniu dezaktywuję BUSY, master może wysłać kolejne dane. Pętla główna wykonuje się w max 1,3us. W najgorszym przypadku po 1,3us program główny zauważy koniec transmisji, zdekoduje (w praktyce dokończy dekodowanie) danych i zdezaktywuje BUSY. Co by było gdyby pętla główna wykonywała się 30ms? Master mógłby wysyłać dane co 30ms a nie co kilka us czyli jakieś 10000 razy wolniej!. Nawet owe 180us spowodowałoby, że dane odbierane mogą być 60 razy wolniej.


Nie chodzi mi o to, że na AVR nie da się tego zadania w ogóle zrealizować, bo się nie da ale gdyby odbierać dane z prędkością np 250kHz i 1kB to problem opóźnienia BUSY będzie ten sam gdy zablokuje się pętlę główną na długo.

W większości moich projektów pela główna musi wykonywać się bardzo szybko. Czy pisałem na AVR czy teraz na ARM, rzadko pętla główna wykonywała się dłużej niż kilkadziesiąt ms. Przeważnie są to pojedyncze ms. Zawsze rezerwuję jeden timer do pomiaru czas wykonania pętli głównej. Mierze czas typowy i maksymalny. Dzięki temu wiem czego mogę się spodziewać w programie, jakich maksymalnych opóźnień. Wiem czy jakąś funkcjonalność mogę realizować przez pooling czy muszę użyć przerwań.
ARM jest szybki, ale gdy podejdzie się do programowania jak autorzy bibliotek Arduino, to zysk czasowy będzie żaden. Aby ARM działał szybko, nie można go blokować przez delay czy czekać na zdarzenie w pętli. Trzeba użyć przerwań albo maszyny stanu oraz na max wykorzystywać sprzęt. Ta uwaga dotyczy także AVR ale ze względu na brak DMA nie zawsze. Przykładowo wysyłanie danych po SPi z f=8MHz na przerwaniach nie ma sensu. Sytuację komplikuje też mała wielkość RAM, ale jaki problem używać mega1284 z 16kB RAM?


Nawet chyba w DIY umieszczę projekt, który zrealizowałem. Zastanawiam się jednak nad tym, czy dekodowania danych nie zrealizować w przerwaniu o niskim priorytecie. Zyskałbym nawet 1,3us.
Mam jeszcze inny podobny projekt. Tam procesor jest usypiany nawet na 1ms i taki jest typowy czas wykonywania pętli głównej ale nie ma linii BUSY bo dane są dekodowane w przerwaniach. Jest to możliwe z dwóch powodów, max prędkość jest mniejsza a dekodowanie danych zdecydowanie łatwiejsze przez co zajmuje mniej czasu.

W DIY umieściłem dokumentację akceleratora dla WS2812 post222192.html#p222192. Jak skończę prace nad aktualnym projektem (akcelerator dla kolorowych wyświetlaczy graficznych ) też umieszczę.

------------------------ [ Dodano po: 17 minutach ]


Działają czy po prostu błędów nie zauważyłeś?


Najlepiej nie szacować ale zmierzyć. Do tego najlepiej użyć timera. Dla wygody można ustawić podzielnik tak, aby był taktowany 1MHz. Wynik pomiaru będzie w us. Gdy 65ms to za mało (jak timer 16-bit) albo timer jest 8-bit i wtedy max to 255us, to trzeba skorzystać z przerwania od przepełnienia.
Można też np w pętli głównej zmieniać stan portu a oscyloskopem mierzyć czas, tyle, że zależnie od oscyloskopu, pomiar max czasu obiegu pętli może być trudny, w przypadku timera wystarczy jeden if

Czas średni i minimalny też można zmierzyć ale najistotniejszy jest czas maksymalny.

------------------------ [ Dodano po: 43 minutach ]


Robiłeś testy "zmęczeniowe" na najgorszy przypadek? Nie znając konstrukcji Twojego sprzętu, budowy programu zrobiłbym na początek test awarii przycisku i wymusił, np generatorem, pojawianie się kilku impulsów na sekundę. Jak zachowa się program?

Takim testem wyłożyłem program, który miał mierzyć czas impulsów na wejściu (tryb przechwytywania timera). Autor w programie nie dał timeout i podanie kilkuset kHz na wejście spowodowało, że program zawiesił się, dokładniej, prawie cały czas przebywał w przerwaniu. Przy okazji wyszło, że nie było obsługi watchdoga. Program trafił do poprawki ale już więcej go nie widziałem a programu bez poprawki nie kupię bo po co mi taki? Działa tylko gdy wszystko jest dobrze, jakakolwiek nietypowa sytuacja i program wisi.
Jak urządzenie ma zewnętrzne moduły np I2C, to obowiązkowo testy odłączenia i podłączenia takiego modułu w czasie działania softu i sprawdzenie reakcji. Dodatkowo zwarcie magistrali łączącej moduły na wszelkie sposoby (linie transmisyjne pomiędzy sobą, do masy, jeśli jest Vcc do i do Vcc, przerwanie linni od strony nadajnika, odbiornika). Program powinien sygnalizować błędy gdy problem zniknie zacząć działać dalej.
Test gdy ramki przychodzące mają przekłamania. Jak Twój program się wtedy zachowuje?

------------------------ [ Dodano po: 49 minutach ]

Pisałeś, że urządzenie wysyła informacje kilka razy na dzień. Jak przestanie to sygnalizujesz to? Czy program nie powinien realizować echa lub ping aby stwierdzić czy slave żyje czy coś jest nie tak?
To nagminny problem w termometrach bezprzewodowych, wysyłają ramkę co minutę, bateria padła (dlaczego w ramce nie ma info o słabej baterii) i baza pokazuje temperaturę z przed kilku dni. Taki termometr nadaje się tylko do kosza, może pokazywać temperaturę z przed kilku dni ale z dodatkową informacją, że brak komunikacji najlepiej jak długo.

To może inaczej. Jestem hobbystą zajmującym się elektroniką. Błędy są na pewno w programach które napisałem, lecz ja patrze na działanie układów. Zawsze coś da się zrobić lepiej. I dlatego chce przejść z bascoma na C gdyż uważam że będzie lepiej. Dodatkowo tez się czegoś nowego nauczę.

Napisałem że działa mi to już ponad 2 lata bo tak jest. Przy użytkowaniu sprzętu wszystko działa tak jak sobie to wymyśliłem.

Nie chcę robić mega zaawansowanego komputera do sterowania przekaźnikiem, załączającym światło w kuchni.

Tak czy inaczej przetestuje metodę z przerwaniem. (jak to ogarnę)

Korzystając z przerwań pamiętaj o atrybucie volatile. Brak tego atrybutu to najczęstsze problemy początkujących.

Nie napisałeś zbyt wiele o swojej konstrukcji więc ciężko coś konkretnego doradzić.