Chciałbym wykorzystać TIMER do debouncingu i spowolnienia odświeżania wyświetlacza, żeby nie stosować tak lubianych przez początkujących programistów _delay'ów
Wyklepałem coś takiego (bez ściągania od nikogo jedynie sugerując się opisami jak to należy zrobić)
Czy takie podejście jest poprawne i czy można coś jeszcze bardziej usprawnić

_________________
Czekamy na RedBook'a!

Wszystko byłoby dobrze gdyby nie to że zrobiłeś kilka poważnych hmm wręcz karygodnych błędów które w efekcie dyskfalisikują ten pomysł w całości

Po prosu używasz wewnątrz procedury obsługi przerwania - wyświetlania na LCD, ale także odczytu i zapisu RTC chociaż to już mniejszy nieco problem


Tak się NIGDY nie robi, żadnych długotrwałych operacji w przerwaniach, to jeszcze gorsze od używania _delay'ów o których wspominasz. Jak sobie z tym poradzić ?

Droga już niedaleka - teraz zastosuj flagi i te operacje krytyczne o których mówię wyżej przenieś z przerwania do pętli głównej programu..... Tak to się robi...

Tak tylko zasugeruję delikatnie, że bardzo przydałaby ci się ta pierwsza książka - LINK Już nie tylko ze względu na te filmy n/t eclipse itp ... ale tam właśnie są podstawy i po kolei tłumaczone systemów czasu rzeczywistego - tyle że w taki przystępny sposób i jak działać w oparciu o timery programowe.

------------------------ [ Dodano po: kilkunastu sekundach ]

sprintf() to też długaśne operacje jak na przerwania do timerów

_________________
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 ]

O widzisz... wpadłem na flagi (bo w innym przerwaniu ustalam co się ma wyświetlić, ale samego wyświetlania nie robiłem w przerwaniu).
Za to tutaj na szybkiego, żeby zapytać o sposób wykorzystania timera do odświeżania bezmyślnie wkleiłem kod z pętli głównej
Czyli idea jest dobra, wykonanie do poprawki...

_________________
Czekamy na RedBook'a!

Tak jak najbardziej - sama idea jest ok - czyli wykorzystujemy timer sprzętowy do odmierzania odcinków czasu, które nas interesują, a to co z tym robimy w pętli głównej to właśnie namiastki timerów programowych

_________________
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 ]

No dobrze... a bardzo trudne będzie zrobienie aby tutaj wyrzucić stąd ten bezsensowny _delay ?

_________________
Czekamy na RedBook'a!

O jej! aż 100ms w przerwaniu ? to baaaardzo niedobrze - delikatnie mówiąc.

Jak zastąpić ? ... żeby na to odpowiedzieć to trzeba by znać jakąś całą konecpcję jaką przyjąłeś

ale przede wszystkim tutaj czy przypadkiem nie kłania się (tak dopytam tylko) niezrozumienie do końca debouncingu. Pytam, bo jak widzę, że ktoś w programie dla obsługi drgań styków stosuje tak kosmicznie długie czasy i nie ważne czy w przerwaniu czy w pętli głównej - to często tak na prawdę potrzebne one są takiej osobie nie do eliminacji drgań styków tylko do hmmm opóźnień pomiędzy klikaniem klawisza ....

Ja tutaj podpowiedziałbym ci dokładnie to samo .... bierzesz w rękę FLAGĘ a w pętli głównej czy dowolnym zdarzeniu EVENT, wykorzystując najzwyklejszy i mało precyzyjny timer programowy - robisz z tym co ci się żywnie spodoba. Czyli w tej pętli głównej możesz uznać, że jeśli status wciśnięcia klawisza wystąpił np dwa razy w ciągu 20ms (drgania są i tak setki razy krótsze jeśli w ogóle są) .... to przekazujesz info dalej do pętli głównej albo kod wciśniętego klawisza do kolejki itp itd.... Ale jeśli w ciągu 20ms nie wzrośnie licznik do 2, to status klawisza zostanie wyzerowany ... i tak w kółko - no ale te operacje - w ogóle nie zasługujące na obecność w procedurach obsługi przerwań - mogą się byczyć w pętli głównej albo zdarzeniach EVENT, które z kolei mogą być powoływane do życia w DOWOLNEJ części programu

a nawiasem mówiąc - jeśli nie trzeba to nie stosuj wywoływania innych funkcji z wewnątrz przerwania, obsluga_klawiatury(klucz);

nie dość że zwiększasz niepotrzebnie stos to jeszcze dokładasz sobie narzut czasowy na skok i return. Więc jeśli tylko można to UNIKAJ tego.

_________________
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 ]

Oto koncepcja:
Trzy przyciski na 2 liniach I/O ponieważ 2^2 = 4 możliwości czyli:
1 1 - nic nie wciśnięte,
1 0 - wciśnięty jeden,
0 1 - wciśnięty drugi,
0 0 - wciśnięte oba (tzn. wciśnięty trzeci podłączony do obu wejść I/O przez diody shottky)
W ten sposób oszczędzony jeden pin potrzebny do czegoś innego... i mamy 3 przyciskową klawiaturę na której już można zrobić całkiem sensowne menu .

Teraz wciśnięcie któregokolwiek klawisza wywołuje przerwanie od portu - Pin Change Interrupt.
Ponieważ przerwanie typu PCI jest jedno dla grupy pinów (całego jednego portu) trzeba sprawdzić skąd przerwanie wyszło - w tym celu liczony jest klucz czyli złożenie dwóch najmniej znaczących bitów portu PB (przyciski są podłączone PB0 i PB1). Na podstawie wyniku z klucza osobna procedura ustala co program ma robić... Ponieważ to przyciski - potrzebny jest jakiś debouncing. Na nieszczęście w przerwaniu.

Już wiem, że procedurę trzeba wywołać nie z przerwania a z programu głównego i tylko flagę sprawdzać... ale co zrobić z tym debouncingiem? Może zrezygnować z przerwania od przycisków i tylko sprawdzać co jakiś czas tak jak napisałem na początku tego tematu... tzn. też nie do końca bo w przerwaniu tylko ustawić flagę, a sprawdzanie stanu już w pętli głównej Tylko zastanawiam się co będzie jak procesor będzie zajęty czymś dłużej np. zapisem na MMC a ja zechcę w tym samym czasie zmienić jakieś ustawienie (co będzie wymagało wciśnięcie całej sekwencji klawiszy)?

_________________
Czekamy na RedBook'a!

No widzisz - u mnie w 99% aplikacji do obsługi klawiszy wykorzystywane jest tylko skanowanie w pętlach programu bez udziału przerwań. I to co piszesz można z powodzeniem tak samo zrobić. Przecież co to oznacza że procesor będzie zajęty czymś dłużej np zapisem do MMC. A niech sobie zapisuje i odczytuje ile chce - musi to przecież robić tą operację w jakiejś pętli ... co za problem dodać do nie zdarzenie: EVENT_KBD() ???

ale w 1% aplikacji czasem to dodanie skanowania może przeszkadzać dlatego wtedy - skanowanie przenoszę do timera sprzętowego, który i tak pełni rolę podstawy czasu dla wszystkich timerów programowych w całej aplikacji. A skanowanie to ładnie już informuje inne zdarzenie EVENT które mogę spokojnie wstawić do pętli obsługującej zapis/odczyt do/z SD/MMC

_________________
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 ]

Co robię nie tak?

_FLAGA jest volatile uint_8t
Pętla główna wygląda tak:


Nie mogę wypatrzyć błędu...

_________________
Czekamy na RedBook'a!

A gdzie masz kasowanie tych swoich flag ? w pętli głównej ?

_________________
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 ]

_________________
Czekamy na RedBook'a!

No coraz ciekawiej i krócej piszesz - teraz to już mistrzostwo czyli nic poza kodem. Teraz jest zerowanie flag. Ale jaki problem ??? to już tylko ty raczysz wiedzieć ja nie mam zielonego pojęcia

_________________
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 ]

Heh... no tak ekhm... nic na wyświetlaczu nie mam, jak po za warunkami dam lcd_hex(_FLAGA) to cały czas mam 0...

Edit:
Powodem była źle postawiona klamerka na końcu pętli głównej - było tak:

_________________
Czekamy na RedBook'a!