Witam

Dzisiaj przeczytałem w "Podstawach programowania" o timerach programowych.

Autor pisze że takie przerwanie musi wykonywać się jak najszybciej

Kod z książki:



Czy ten kod nie mógłby wyglądać tak:





Czy to nadal będzie poprawnie działać ?

Mi wydaje się że tak i przy okazji deko szybciej.

Proszę o potwierdzenie / wyprowadzenie mnie z błędu

_________________
sig on ;)

Odpowiedź na twoje wątpliwości jest pod koniec tego artykułu:
http://mirekk36.blogspot.com/2012/10/obsuga-klawiszy-zwoka-czasowa-cd3.html

Zachęcam jednak do przeczytania od początku

Pozdrawiam
PP

_________________
Pozdrawiam
PP

Bardzo dobra podpowiedź ze strony kolegi Piotrek_P

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

Dziękuję za odpowiedź, jutro poczytam

_________________
sig on ;)

Przeczytałem

Dziwne to dla mnie, ale na razie nie będę wnikał w asemblera by to zrozumieć.

Natomiast mam pytanie odnośnie kodu tam przedstawionego.
Analizuję go powoli i jednego słowa nie znam (wydaje mi się że w książce się z nim nie spotkałem)

chodzi o linijkę na ostatnim zrzucie oznaczoną jako A
a dokładnie o słowo register

Co ono oznacza ?


Ps. Całe to wyjaśnienie pojawiło się dla mnie jak to ze strony 118, nagle i w odpowiednim momencie
Chwała Autorowi

_________________
sig on ;)

Mam również problem z tymi timerami. Z większego programu wyodrębniłem samą część z timerami i działanie tego przykładu wygląda tak:

W przerwaniu co ~1ms dekrementowane są dwa timery, timer1ms_1 oraz timer1ms_2. Obie te zmiennie to 16 bitowe integery bez znaku.



W mainie natomiast timer1ms_2 ustawiany na 32767, więc w troszkę ponad pół minuty zmienna ta osiąga 0. Pętla główna wykonuje się, dopóki timer ten jest różny od zera. W pętli tej sprawdzany jest warunek, czy timer1ms_1 jest równy 0. Jeżeli tak, do zmiennej tej wpisywana jest wartość 256 i po uarcie idzie informacja o różnicy wartości timera drugiego z chwilą poprzednią.

Sprowadza się do tego, że sprawdzamy czy warunek ten faktycznie wykonuje się co te ~256ms. W terminalu powinno nam się pokazać:

itd.
Jednak u mnie to ma postać np.:

Ktoś kradnie mi 255 milisekund! Naprawdę nie mam pojęcia co jest tego przyczyną. W zależności od kodu, te zubożone cykle pojawiają się w sposób okresowy, czyli przebieg pokazany powyżej powtarzany jest w tej samej sekwencji. Gdyby trochę kod zmienić, błędy te pojawiają się w innej kolejności, jednak potem znów dochodzi do cyklicznego ich występowania. Wniosek mój z tego taki, że nie jest to wina zakłóceń, ponieważ brak tu elementu losowego.
Jak wypełnimy timer pierwszy np. 1000 (aby warunek wykonywał się co sekundę), to błędny, szybszy cykl wykona się po 745ms - znowu różnica 255. Coś jakby było nie tak z arytmetyką 16bitową w przerwaniach... Coś złego jakby z pierwszym bajtem się dzieje.. Próbowałem już wyłączać przerwania przy wpisywaniu do zmiennej timera i załączać zaraz potem, nic to nie pomogło niestety.
Tu cały projekt z Eclipse Juno:
http://dl.getdropbox.com/u/19477765/test_timer.zip

Kiedyś coś takiego popełniłem.
http://sp9rqa.net/Elektronika/Timery_programowe.html

Może się komuś przyda. Mam nadzieję, że nie ma błędów.

Przede wszystkim to BARDZO WYRAŹNIE pisałem o rozdzielczości hmmm ziarnistości czasowej - jej dobraniu ....

A ty sobie z marszu dajesz rozdzielczość czasową na poziomie 1ms ..... Gdybyś programował w asemblerze to jeszcze mógłbyś sobie na to pozwolić - ale tu już może być ciężko

zaczynaj bezpiecznie od 10ms .... Timery programowe nie są do odliczania aż tak szczegółowych zadań a już tym bardziej do super precyzyjnego odmierzania czasu.

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

Fakt, docelowo zastanowie się nad innym rozwiązaniem. Jednak próbowałem już zmniejszać rozdzielczość timerów.

Po zmienieniu wartośći OCR2 (używam timer2) z wartości 8 na 78 (co daje tyknięcia co około 10ms) dzieje się to samo:

Tak wygląda jeden cykl "przebiegu" który można obserwować na terminalu. W tym wypadku widać, że różnice pomiędzy kolejnymi wykonaniami kodu w warunku wykonują się co 256 kroków (*10ms=~2,5s), natomiast co 11 wejście w ten warunek dzieje się za szybko. Dodatkowo, na tyle na ile sprawdziłem, błędy te nie pojawiają się przy pracy na zmiennych dających się zapisać na 8 bitach.
Dziękuję za odpowiedź i mam nadzieję, że dojdziemy gdzie tu błąd leży.. Po prostu nie mogę dojść już co mi umyka

ellox --> na drugi raz tak krótkie kody prezentuj tu na forum a nie w ZIP'ie bo wcześniej nawet nie zajrzałem ...

a teraz widzę że masz tam babol na babolu i tak patrząc na to to twój program działa zupełnie poprawnie ... zgodnie z babolami

po pierwsze co robi to słówko extern ???? może warto doczytać co to jest extern i do czego ? - w KSIĄŻCE na 100% jest

po drugie - panie kochany bój się ZEUSA gdzie u ciebie jest pętla główna ??? ja wszystko rozumiem, że to tylko test - ale próba zrozumienia co ty chciałeś tu poczynić doprowadza do poważnego zapętlenia moich resztek wątłej kory mózgowej

Proszę cię - popraw to - ja na razie totalnie nie mogę zajarzyć co ty chciałeś zrobić w tym przykładzie

aha i jeszcze jedno - po co zmienna static w main() ??? zrób ją albo lokalną albo globalną - tutaj dawanie statica - mija się z celem totalnie

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

Za statica w mainie przepraszam, usunąłem zaraz po wrzuceniu na forum - były to resztki moich prób łapania się za próby nawet bezsensowne.

Druga sprawa. Skoro słówko "extern" jest tam niepoprawne? To w takim razie jak należy się odnosić do zmiennych zadeklarowanych w innym pliku źródłowym? Jak na mój poziom wiedzy, do tego właśnie to słówko służy... Sprawdziłem to co wrzuciłem na dropa - no przeca tam są dwa foldery w których znajdują się pliki źródłowe prócz samego main.c. Nie wrzucałem całego kodu, ponieważ mimo że przykład prosty, to chciałem pozostawić strukturę podfolderów w projekcie - tak samo poukładane mam to w programie, w którym ten błąd mój wykryłem. No nic, kody zamieszczam poniżej, po dodaniu komentarzy aby wszystko było już jasne. Zaczynam od części sprzętowej:

folder: USART
usart.c:

usart.h:


folder: system_timer
system_timer.c:

system_timer.h:


No i main.c w ścieżce głównej:


Owszem, w moim programie pętla główna nie wykonuje się nieskończenie, jednak jest to efekt zamierzony. Mimo skończonej postaci tej pętli, chyba nadal można ją nazywać mianem "pętli głównej"?

Mógłbym prosić o wskazanie tych wszystkich baboli i niejasności? Bo szczerze, za bardzo nie wiem co poprawiać w na tyle prostym przykładzie...

ed: Przeniosłem deklarację zmiennej do pliku nagłówkowego (bo zapewne o to Panu chodziło). Jednak to, czy deklaracja znajduje się przed funkcją main w formie dosłownej, czy też zawarta jest w pliku nagłówkowym nie ma w tym wypadku żadnej różnicy w działaniu programu - zmienna ta używana jest tylko w mainie.

z tym extern - to ja albo nie zauważyłem albo tam nie było innych plików ...

Naturalnie masz rację że jeśli ta zmienna jest w innym pliku to dajemy extern ... tylko że nie w pliku *.c a w pliku *.h

------------------------ [ Dodano po: 1 minucie ]

jednym słowem mówiąc to:

extern volatile uint16_t timer10ms_1, timer10ms_2;

powinieneś dać w timer.h

a że nie ma tak jak powinno być to czytanie tego projektu jest tak ciężkie - rozumiesz ?

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

Jak dla mnie, to obie metody są poprawne. Zależy, jaki chcemy uzyskać zasięg tych zmiennych.. Zamiast kilkukrotnie w innych plikach wypisywać osobno "extern zmienna1, zmienna2" po kilka razy, faktycznie lepiej jest to zawrzeć w pliku nagłówkowym, zaliczyłbym to w tym momencie do tej dobrej praktyki programistycznej. Jednak jeżeli zmienne te są używane tylko w jednym z tych plików, lepszym rozwiązaniem może być użycie tego w ten mój sposób (rozwiązanie na podobę jak ze stosowaniem zmiennych z "const" - stosowane wtedy, kiedy innego użytkownika lub sami na przykład chcemy się ustrzec przed błędem i próbami zmiany jakiejś zmiennej, bo używamy jej jako stałej).

No ale cały czas mijamy się z tematem, wyżej cały kod wisi, z tym że extern jest użyte jak jest, a na dropie jest aktualna wersja (z deklaracją zmiennej w pliku nagłówkowym) z całym projektem pod adresem: http://dl.getdropbox.com/u/19477765/test_timer.zip

Opisywałem co ten program robi. W skrócie: wedle timera programowego 1, co 256 tyknięć co 10ms, czyli co ~2,5s wykonywany jest kod, który wypisuje w terminalu, ile minęło od jego ostatniego wywołania - do mierzenia tego służy timer programowy 2, który na początku życia programu jest wypełniony 32767 i potem dekrementowany tak samo jak timer 1.

No i to właśnie nie działa poprawnie - w większości kod wykonywany jest co te 256 tyknięć, czasami jednak coś się dzieje niedobrego i wywołany jest po 1 tyknięciu. Gdzieś gubi się 255 tyknięć. Gdyby timer 1 wypełniać liczba 1000, to te błędne wywołanie (szybsze) nastąpi po 745 tyknięciach, sprawdzałem to.

Ja ci zwracam uwagę jak powinno być a to że wg ciebie jest ok to już inna kwestia ... nie chcesz nie stosuj się do zasad, ale później będziesz sam szukał błędów .... nic nie uzasadnia w takim przypadku stosowania deklaracji zmiennej w pliku *.c


Przy tak zakręconym kodzie .... ja i tak nadal go nie rozumiem a tym bardziej co nie działa .... ale to nieważne

Zwróć uwagę jeszcze na użycie sekcji krytycznych ATOMICBLOCK podczas przeładowywania wartości tych 16-bitowych timerów programowy czyli:



poza tym to:



nie jest żadna pętla główna programu i znowu albo robisz jakieś swoje uproszczenie myślowe jak z tym extern albo nie wiesz o co chodzi z tą pętlą główną

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

Mógłbym prosić o jakieś źródła w których jest więcej napisane właśnie na temat używania extern? Chciałbym wiedzieć, dlaczego właśnie ten sposób jest poprawny. Jakieś uargumentowanie? Bo to że coś powinno być tak, a nie inaczej bo ktoś tak uważa do niczego nie prowadzi (bo chyba oboje w tym momencie używamy takiej postawy). Jeśli robię to źle, to proszę powiedzieć dlaczego. Ja błędów szukać nie będę - wiem dlaczego tego używam w ten sposób, a nie inny. Chciałbym po prostu zobaczyć źródło tych zasad, dlaczego tak nie wolno i utwierdzić się że jest to rozwiązanie błędne. Będzie to również wskazówka dla innych żeby nie powielali tego błędu - jeżeli jest to faktycznie błąd.

To jak wg Pana powinna pętla główna wyglądać?

??
Czy chodzi o Panu o pętlę nieskończoną? Można zamienić to na while(1) i wewnątrz tej pętli dodać mój warunek, ale to jest już sztuka dla sztuki.. My tu się w jakąś ciuciubabkę bawimy lub inną zgaduj zgadule, ja chętnie poprawię to co poprawić trzeba, ale to wystarczy powiedzieć co i dla czego, a przy takich odpowiedziach nie można dojść co jest nie tak. Mogę zgadywać, że chodzi Panu o to:


Prosiłbym o konstruktywną krytykę, zamiast ogólnego narzekania, że to zakręcone, to nie tak. Tak to się nikt niczego nie nauczy, a pół strony zajmie dyskusja na nie wiadomo jaki temat (a takierzeczy to raczej na elektrodzie ). Ja rozumiem że dla mnie pewne oczywiste rzeczy nie są oczywiste dla innych, tylko proszę powiedzieć co dokładnie jest niejasne? Już dwa razy tłumaczyłem co ten przykład robi, dodałem odpowiednie komentarze. Mam wrażenie, jakby ten kod przeglądał Pan na szybcika bez jego analizy, vide - pierwszy post z extern.

ed:
Poczytam o użyciu sekcji krytycznych ATOMICBLOCK, bo nic nie wiem o tym na chwilę obecną. Dziękuję za wskazówkę.

------------------------ [ Dodano po: 27 minutach ]

No dobra, to może inaczej. Skoro ja nie umiem napisać poprawnie kodu tego prostego przykładu, to mam takie zadanie do rozwiązania:
1. Ustalamy rozdzielczość tykania dwóch timerów programowych, jak tak Pan Mirek polecił, nie za szybko, niech będzie te 10ms.
2. Jeden timer służy do wykonania, co 256 tyknięć, kodu: wysłania na terminal pewnej informacji.
3. Drugi timer służy do obliczania czasu pomiędzy kolejnymi wysłanymi informacjami na terminal - i to jest właśnie to co chcemy przekazywać po UARCIe. Sprawdzamy, czy faktycznie ten kod wykonywany jest co taki okres czasu, jaki powinien.

Ktoś pomyśli - no ale po co takie coś sprawdzać, przecież to proste?? No właśnie - takie proste, że u mnie czasami gubi się te 255 tyknięć i informacja ta przekazana jest już po 1 tyknięciu. Tym samym, w terminalu wypisuje mi "1" zamiast "256".
Howgh.

To jest tak jak niedawno na elektrodzie ktoś się ze mną kłócił - że #define F_CPU też czasem można robić w kodzie bo to jest OK .... i może być nawet pożądane w prostych projektach.

Więc zarówno zasada związana z tym że #define F_CPU nie robi się w kodzie programu jest taka sama jak z tymi deklaracjami zmiennych extern....

W ogóle - ale to w ogóle dla mnie żadnym wyjaśnieniem ani uzasadnieniem nie jest fakt - że jak mam np mały projekt, mało plików to można sobie dawać #define F_CPU albo extern dla zmiennych w plikach *.c

dlaczego ???? to baaardzo proste

otóż można się babrać i pisać projekt jedno- czy dwu- plikowy i wmawiać sobie, że to nic nie szkodzi że w pliku *.c dałem sobie extern

kłopoty zaczynają się później. Czasem projekt się rozszerza - idąc tą drogą dajesz w kolejnych plikach projektu *.c te deklaracje extern ..... a czasem projekt się rozrasta jeszcze bardziej i gdzieś po drodze zmieniasz nazwę zmiennej (a przy okazji masz ich kilkadziesiąt a nie jedną) ..... i co ??? robi się MEGA KASZANA - i zaczynasz szukać po plikach co gdzie jest nie tak i tracić czas ...

a wystarczy trzymać się PROSTEJ jak DRUT ZASADY o której piszę - czyli deklaracje zmiennych extern dawać w powiązanych plikach *.h i NIE WAŻNE czy mały projekt czy duży projekt ZAWSZE BĘDZIE DOBRZE

więc masz tu ŹRÓDŁO - tu ci napisałem .... o co chodzi.





Kolega chyba sobie raczy żartować teraz - albo robić sobie ze mnie żarty.



Oj tak widzę że bawimy się chyba i mnie to przestaje odpowiadać ... więc pewnie kolega będzie musiał poczekać aż ktoś inny pomoże. Tyle że dla mnie to kolega bawi się w ciuciubabkę - bo albo zadajemy pytania poprawnie, albo piszemy kod zgodnie ze sztuką zadając pytania - a jak się czegoś nie wie to dopytujemy się - a nie jak kolega - odpowiada mi - że nie mam racji - bo wg kolegi jest inaczej - to po jaką choinkę w ogóle kolega pyta ?

Jak widzę kod z babolami to staram się naprowadzić na nie po kolei i wykorzenić od początku do końca ....




Ja nie narzekam - po prostu nie rozumiem kodu - tzn teraz po dodatkowych komentarzach coś mi świta co masz na myśli .... ale nie jest moim celem ośmieszanie czy ironizowanie. Za to sam wprowadzasz nerwową atmosferę - bo popełniasz błędy - ja ci zwracam uwagę a ty piszesz że wg ciebie tak może być i też bez wyjaśnienia - a ode mnie wtedy go oczekujesz ? ...




Niestety tak jest - że na szybcika - bo ja nie mam za dużo czasu a staram się go dzielić na mnóstwo zadań w tym na pomoc na forum , maile itp ... więc już chociażby dlatego napisałem że jak dla mnie kod i pomysł jest zakręcony - co NIE OZNACZA że głupi! tylko że ja nie mogę go na szybko dobrze przeanalizować - a ty proszę dalej się czepiasz z tym że nie zauważyłem z tym extern na początku.


..... zaraz napiszę dalej - bo strasznie długi post napisałeś

------------------------ [ Dodano po: 38 minutach ]

o to ci chodziło ?





dodałem jeszcze widok tego głównego licznika który się zmniejsza od 32767

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

Okey, już wiem gdzie występował błąd, a i gdzie ja nie mogłem znaleźć. Zapomniałem o objęciu w ATOMIC_BLOCK również i sprawdzenia warunku, czy timer jest równy zero. Wykorzystam to w ten sposób w programie, że za pomocą tej funkcji przypiszę wartość timera do zmiennej pomocniczej i na niej będę operować, a nie na zmiennej timera. Mimo, że opatrzona "volatile", jest przecież 16 bitowa - 8 bitowy procesor nie może w takim razem dokonać operacji na takiej zmiennej "za jednym razem".
Dobrze kombinuje z tą zmienną pomocniczą? Nie musiałbym wtedy dawać dużego kodu w blok ATOMIC.

Co do extern i przykładu z nazwami zmiennych. Do zmiany nazwy użyłbym funkcji Refactor->Rename w Eclipse. No i kwestia powtarzania tej samej deklaracji w mnożących się plikach - już parę postów wyżej zgodziłem się z Panem, że użyłbym wtedy tej deklaracji w nagłówku, no sam to wyżej napisałem. Gdybym jednak używał tego tylko w jednym pliku i nie chciałbym, aby zmienne te były dostępne w caaałym projekcie, a właśnie tylko w pliku gdzie zostały zdefiniowane oraz w pliku gdzie zostały zdeklarowane (a plik nagłówkowy zawarty jest właśnie w całym projekcie). W tym momencie jest to w sposób świadomy ograniczenie widoczności zmiennych do wybranych plików. Jeżeli jest to sposób zły, to jak zrobić to inaczej? W każdym razie, jak faktycznie nie będę potrzebować takiego podejścia, to będę to deklarować w nagłówku - oszczędzi to problemów. No i w zasadzie po to ten plik jest, do deklaracji... czy to funkcji, czy zmiennych, tam ich miejsce!

No i co do programu teraz. W tej chwili są pod rząd dwie nieskończone pętle while(1). Komunikat końcowy w ogóle nie pojawi się na terminalu. Jak się domyślam mojego błędu, to chodziło o to, że zostawiłem mikrokontroler w stanie niewiadomym - ani żadnej nieskończonej pętli, ani żadnego return 0. Zrozumiałem jednak o co chodzi z wykonywaniem kodu "atomowo".

No i właśnie - gdybym na początku przeczytał, że miejsce deklaracji zmiennej jest w pliku nagłówkowym (no bo to przecież deklaracja! - zapamiętam), albo że brakuje pętli głównej programu, czyli takiego zastosowania pętli lub instrukcji return, aby nie zostawiać mikrokontrolera stanie nieustalonym, co może powodować nieprzewidziane wyniki... Sam bym się wtedy nie denerwował i niepotrzebnych postów nie produkował.. Próbując się domyślić co jest źle, skoro działa?