ATNEL tech-forum

Re: Problem ze stabilnością timera programowego.

2016-11-07T22:13:07+01:00

Barti9 napisał(a):

Proszę oto kod:

Polecam ci zacząć od Bluebooka bo coś czuję (choć może nie mam racji, to mnie popraw), że książki nie masz - a kody próbujesz pisać na zasadzie sklejania czegoś tam na "chybił trafił" i bez niestety zrozumienia co i jak działa ... Widać to po podstawowych błędach jakie popełniasz. Żeby nie być gołosłownym proszę przykład:

[syntax=c]volatile uint16_t Timer1=0;[/syntax]

kolejny, może nie jakiś tam zaraz wielki błąd

[syntax=c]OCR1A |=2000-1;[/syntax]

ale pokazuje to jak na dłoni, że coś skądś przepisujesz a nie czytałeś jak "to" działa.

No a twoje tajemnicze przyśpieszanie albo późnienie to rzecz naturalna w tak napisanym kodzie - tzn sklejonym z jakichś strzępków innych kodów na zasadzie - że hmmm chyba powinno działać ....

przyczyny twoich problemów leżą zarówno tu:

[syntax=c]TCCR1B|=(1< OCR1A |=2000-1;[/syntax]

a w związku z tym szczególnie tu:

[syntax=c]if(!Timer1)
{
Timer1 = 1000;
......[/syntax]

Nie wspomnę już o tym, że występuje paskudny brak komentarzy

Statystyki: Napisane przez mirekk36 — 7 lis 2016, o 22:13

Re: Problem ze stabilnością timera programowego.

2016-11-07T21:48:26+01:00

Niewiele widac?

Statystyki: Napisane przez micky — 7 lis 2016, o 21:48

Re: Problem ze stabilnością timera programowego.

2016-11-07T21:35:09+01:00

Proszę oto kod:

Code:

#include 
#include 
#include "HD44780/HD44780.h"


volatile uint16_t Timer1=0;

ISR(TIMER1_COMPA_vect) //1000hz
{
   uint16_t x;
   x = Timer1;
   if(x)
      Timer1 = --x;
}

int main(void)
{
   LCD_Initalize();

   TCCR1B|=(1<   TCCR1B|=(1<   OCR1A |=2000-1;
   TIMSK |= (1<
   sei();
   
   uint8_t h = 0;
   uint8_t min = 0;
   uint8_t sec = 0;

   for(;;)
   {
      if(!Timer1)
      {
         Timer1 = 1000;
         LCD_GoTo(0,1);
         if (h<10) LCD_WriteText("0");
         LCD_Int(h);
         LCD_WriteData(':');
         if (min<10) LCD_WriteText("0");
         LCD_Int(min);
         LCD_WriteData(':');
         if (sec<10) LCD_WriteText("0");
         LCD_Int(sec);
         
         sec++;
         
         if(sec >= 60)
         {
            sec = 0;
            min++;
         }
         
         if(min >= 60)
         {
            min = 0;
            h++;
         }
      }
   }
}

Statystyki: Napisane przez Barti9 — 7 lis 2016, o 21:35

Re: Problem ze stabilnością timera programowego.

2016-11-07T20:06:07+01:00

Proponowałbym, żeby autor tematu przedstawił całość kodu, jeśli to nie tajemnica. Podejrzewam, że wtedy coś się uda doradzić.

Statystyki: Napisane przez andrews — 7 lis 2016, o 20:06

Re: Problem ze stabilnością timera programowego.

2016-11-07T18:35:20+01:00

Daro69 napisał(a):

No nie do końca tak jest...

A no rzeczywiście . Przepraszam za błędną diagnozę. Sam w swoich kodach piszę to poprawnie, a tu źle doradzam . Dziękuję za sprostowanie.

Statystyki: Napisane przez wojtekr51 — 7 lis 2016, o 18:35

Re: Problem ze stabilnością timera programowego.

2016-11-07T17:38:54+01:00

wojtekr51 napisał(a):

Według mnie masz źle zainicjalizowany rejestr OCR1A. Powinno być:
Składnia: [ Pobierz ] [ Ukryj ]
język c
OCR1A = 2000;

No nie do końca tak jest, bo OCR1A jest porównywane z licznikiem liczącym od 0.
dlatego do 1999 ma 2000 pozycji.

Statystyki: Napisane przez Daro69 — 7 lis 2016, o 17:38

Re: Problem ze stabilnością timera programowego.

2016-11-07T17:27:57+01:00

Według mnie masz źle zainicjalizowany rejestr OCR1A. Powinno być:
[syntax=c]OCR1A = 2000;[/syntax]
Ale to by nie wyjaśniało aż tak dużej odchyłki odmierzanego czasu. Na 20 min jak piszesz, ten błąd wniósł by mniej więcej tyle:
20 x 60 x 1000 = 1200000 - tyle razy wykonywane jest przerwanie w czasie 20 min
1200000 x (0.001 / 2000) = 0.6 - tyle sekund mniej więcej jest przyspieszenia z tego powodu.

Statystyki: Napisane przez wojtekr51 — 7 lis 2016, o 17:27

Re: Problem ze stabilnością timera programowego.

2016-11-07T17:25:51+01:00

Barti9 napisał(a):

No dobrze, ja rozumiem że tego typu stoper może się późnic i to bardzo ale dlaczego w moim przypadku przyspieszał, jeżeli stoper w pętli głównej zwieksza swoją wartość tylko gdy flaga Timer1 jest równa 0. Dodam jeszcze że na początku przez kilka sekund pracy, stoper działał prawidłowo a potem nagle przyspieszał.

No no i oczywiście pytanie dla jasnowidza na koniec ....

Statystyki: Napisane przez mirekk36 — 7 lis 2016, o 17:25

Re: Problem ze stabilnością timera programowego.

2016-11-07T17:05:21+01:00

Statystyki: Napisane przez Barti9 — 7 lis 2016, o 17:05

Re: Problem ze stabilnością timera programowego.

2016-11-07T16:33:32+01:00

APAP75 napisał(a):

Jako zegar jest ..... i tu, przychylając się do Twojej prośby, nie użyję tego słowa.
Innymi słowy - zegar programuje się używając innych narzędzi.

No i AMEN o to chodzi ... i teraz zgadzamy się w 100% .... jako zegar/stoper jest .....

Mam nadzieję, że dzięki obszernym wyjaśnieniom kolegi squeez oraz tej całej dyskusji - wiele osób które tu zawitają - lepiej zrozumieją istotę timerów programowych

Statystyki: Napisane przez mirekk36 — 7 lis 2016, o 16:33

Re: Problem ze stabilnością timera programowego.

2016-11-07T15:36:18+01:00

OK. Jest dobre a nawet bardzo dobre do pewnych (określonych) zastosowań.
Jako zegar jest ..... i tu, przychylając się do Twojej prośby, nie użyję tego słowa.
Innymi słowy - zegar programuje się używając innych narzędzi.

Nie chciałem nikogo urazić - jeśli tak to przepraszam.
Ty też mnie nie uraziłeś - za dużo Twoich postów już czytałem
Purystą językowym także nie jestem.

A koledze squeez dziękuję za obszerne wyjaśnienia. Okazało się, że opisujemy ścieżki idąc pod zupełnie inna góry
Dzięki niemu jestem na 100% obrotach i to bez kawy.

Statystyki: Napisane przez APAP75 — 7 lis 2016, o 15:36

Re: Problem ze stabilnością timera programowego.

2016-11-07T15:06:42+01:00

APAP75 napisał(a):

Chyba, że znów błądzę, to proszę o kolejne wskazówki.

Nie no teraz zrozumiałeś .... i oczywiście racją jest to co napisałeś

APAP75 napisał(a):

Do głowy mi nie przyszło, że ktoś może na TAKIM timerze programowym zrobić zegar....

No ale z kolei to zdanie

APAP75 napisał(a):

Wam chodzi o coś w rodzaju przerzutnika moinostabilnego - wyzwalamy timer w programie (Timer1=100), a on się zeruje w przerwaniach. Wówczas faktycznie jego dokładność jest do bani.

znowu świadczyć może, że nadal nie rozumiesz albo no - wybacz głupotki opowiadasz - jeśli chodzi o to stwierdzenie na końcu o bani. Nie chciałbym już odpowiadać tobie w takim samym tonie bo pewnie uznałbyś to zaraz za jakiś przytyk czy nieuprzejmość ....

Więc proszę tylko uprzejmie nie pisz takich bzdur, że mechanizm ten jest do "bani" ..... bo nadal to może tylko świadczyć, że nie rozumiesz tego mechanizmu ok - na prawdę proszę

Statystyki: Napisane przez mirekk36 — 7 lis 2016, o 15:06

Re: Problem ze stabilnością timera programowego.

2016-11-07T13:33:02+01:00

HE he he - teraz rozumiem - że mówiliśmy o dwóch różnych rzeczach.

Wam chodzi o coś w rodzaju przerzutnika moinostabilnego - wyzwalamy timer w programie (Timer1=100), a on się zeruje w przerwaniach. Wówczas faktycznie jego dokładność jest do bani.
Do głowy mi nie przyszło, że ktoś może na TAKIM timerze programowym zrobić zegar....

mirekk36 napisał(a):

i co ? teraz ? .... rozumiesz dlaczego Timer1 może nagle MIEĆ rozbieżność z założonym czasem ? A pomimo to nadal taka konstrukcja jest pożądana i używana w milionach przypadków, projektów i rozwiązań

Rozumiem, rozumiem - mały delay wystarczył. A zastosowanie - do nieblokującego odmierzenia pewnego odcinka czasu, coś jak minutnik do jajek. I jak minutnik do jajek może być wykorzystywany w programie.

Ja cały czas myślałem o czymś co chodzi "w tle" - takie "cykadło". Używałem takiego czegoś kilka razy - i także nazywałem to sobie zegarem programowym....

Chyba, że znów błądzę, to proszę o kolejne wskazówki.

Statystyki: Napisane przez APAP75 — 7 lis 2016, o 13:33

Re: Problem ze stabilnością timera programowego.

2016-11-07T13:07:16+01:00

APAP75 napisał(a):

Hmm. Nie wiem jak to napisać, bo większości Was jeśli chodzi o programowanie do pięt nie dorastam, ale:

Tu wcale nie o to chodzi .... za to szkoda, że nie czytasz dokładnie tego co piszę i zamiast zapytać się o coś czego nie rozumiesz to piszesz (wybacz - ale robisz to już po raz drugi więc muszę to powiedzieć) więc piszesz BZDURY.

APAP75 napisał(a):

Skoro timer programowy (postaram się nie używać słowa licznik) jest napędzany w przetrwaniu to nie powinniśmy go modyfikować gdzieś w programie.

To po raz kolejny pokazuje, że W OGÓLE nie rozumiesz istoty działania i korzystania z timera programowego, a szkoda że zamiast próbować się dowiedzieć - bo przyniosłoby to tobie mnóstwo korzyści gdybyś zaskoczył o co chodzi w tym mechanizmie - to wolisz wypisywać swoje kosmiczne teorie i przekręcać to co staram się żmudnie tłumaczyć i w książce i w poradnikach i na forum .... Oczywiście, ja sobie zdaję sprawę, że pomimo tego wciąż ktoś nie może zrozumieć - i nie obwiniam nigdy kogoś za to że nie rozumie - winy mogę szukać u siebie, że nie potrafię dotrzeć .... no ale nie zgodzę się na to, żebyś opowiadał bzdury o tym mechanizmie i kręcił w głowach innym początkującym ok? stąd moje WYJAŚNIENIA.

APAP75 napisał(a):

To tak jakbyśmy używali timera sprzętowego i przy pewnym warunku modyfikowali TCNT (jego licznik).

No więc to BZDURA NAD BZDURAMI, ponieważ - timer programowy jest napędzany licznikiem który modyfikowany jest w przerwaniu ! .... zrozum to. Natomiast gdy ta modyfikacja się zakończy i ma on wartość = ZERO to już przestaje być modyfikowany w przerwaniu. Działa jak FLAGA na którą może zareagować pętla główna, i wtedy mamy pełne prawo modyfikować - hmmm w zasadzie to nie modyfikować tylko ponownie inicjalizować licznik. Oczywiście kwestia czy stosujemy w tym momencie ATOMIC BLOCK czy ręczne wyłączenie przerwań na chwilę to już całkiem inna rzecz i nie zawsze jest to nawet potrzebne ... choć dla porządku tak można uznać że to warto robić ... niech będzie, ale to NADAL NIE MA WPŁYWU na jakąś twoją WYIMAGINOWANĄ dokładność timera programowego - która wg ciebie ma być rzekomo taka sama jak realizacja procesów w oparciu o przerwania .... timera sprzętowego

dlatego spójrz na prosty przykład - który może w końcu spowoduje, że przynajmniej zastanowisz się i pochylisz nad tym co to jest timer programowy

[syntax=c]while(1)
{
if( !Timer1 )
{
PORTD ^= (1< Timer1 = 100;
}
// ***************************
_delay_ms(20); // symulacja procesu zajmującego czas pętli na 20 ms
// ***************************
}[/syntax]

i co ? teraz ? .... rozumiesz dlaczego Timer1 może nagle MIEĆ rozbieżność z założonym czasem ? A pomimo to nadal taka konstrukcja jest pożądana i używana w milionach przypadków, projektów i rozwiązań

Statystyki: Napisane przez mirekk36 — 7 lis 2016, o 13:07

Re: Problem ze stabilnością timera programowego.

2016-11-07T12:21:14+01:00

mirekk36 napisał(a):

A kto tu mówi o liczniku programowym ? ... normalnie co odpowiedź w tym wątku to kompletne niezrozumienie ... masz w tytule "timer programowy" to jedno

Przepraszam - przejęzyczenie. Licznik, timer - zasada działania taka sama - to i to liczy. Wybaczcie, nie jestem purystą. Bardziej jestem w drugiej skrajności. Choć w programowaniu nie jest to pożądana cecha

squeez napisał(a):

Więc może zademonstruję prosty przykład który bardziej przemówi:

Taki prosty kod:

[syntax=c]#include
#include

volatile uint8_t Timer1;

int main(void)
{
DDRD = (1<
TCCR2 = (1< TIMSK |= (1<
sei();
while(1)
{
if( !Timer1 )
{
PORTD ^= (1< Timer1 = 100;
}
}
return 0;
}

ISR(TIMER2_COMP_vect)
{
uint8_t n;

n = Timer1;
if(n) Timer1 = --n;
}
}[/syntax]

Hmm. Nie wiem jak to napisać, bo większości Was jeśli chodzi o programowanie do pięt nie dorastam, ale:
Skoro timer programowy (postaram się nie używać słowa licznik) jest napędzany w przetrwaniu to nie powinniśmy go modyfikować gdzieś w programie. Powinien być modyfikowany tylko w przerwaniu. To tak jakbyśmy używali timera sprzętowego i przy pewnym warunku modyfikowali TCNT (jego licznik). W ten sposób sami strzelamy sobie w stopę. Można spróbować to jakoś "załatać" i całe ciało warunku "if" włożyć w ATOMIC BLOCK, ale nadal to może w przyszłości generować nam problemy. Bo co się stanie, jeśli rozbudujemy nasz program i wartość timera programowego zdąży zmienić się dwa razy zanim sprawdzimy warunek "if" np. przejdzie przez zero.
squeez - Twoje przemyślenia są jak najbardziej poprawne, ale dla mnie jest to nadal kwesta dobrze napisanego programu.
Jest taki scalak: DS1904-F5. Jest to RTC, który tylko liczy - nie pokazuje dni tygodnia, daty itp itd. Gdyby z założenia wszystkie timery programowe były obarczone błędem, ten układ nie miałby prawa istnieć.
Z innej beczki - są projekty zegarów na atmega8 wykorzystujących licznik asynchroniczny i kwarc zegarkowy. Tutaj także sami zliczamy impulsy (timer programowy), a ich dokładność jest taka, jak dokładność zastosowanego kwarcu. Możemy zastosować też inny kwarc i puścić licznik "normalnie" tylko, że wówczas bardziej karkołomne będzie dla nas odmierzenie dokładnie 1 sekundy.

Jak rozumiem timer programowy - dla mnie jest to liczba (komórka pamięci), której wartość zmieniana jest w ściśle określonych odstępach czasu. My możemy podglądnąć jej wartość, ALE TYLKO w określonym miejscu programu (chodzi mi tu o to, że nie wyzwoli przerwania w momencie osiągnięcia przez tą liczbę określonej wartości). Dlatego też, aby jego wskazanie było poprawne modyfikowany może być tylko tam, skąd jest napędzany - w przerwaniu - nigdy w kodzie programu.
Gdy odczytujesz czas na zegarze i stwierdzisz, że minęła pełna np. minuta nie łapiesz wahadła i nie ustawiasz go w np. lewym skaranym położeniu - cyka sobie jak cykało - ty tylko obserwujesz. Bo potem można się zdziwić i np. rewolucja październikowa wybucha w listopadzie

Statystyki: Napisane przez APAP75 — 7 lis 2016, o 12:21

Re: Problem ze stabilnością timera programowego.

2016-11-07T10:18:43+01:00

squeez ---> PIĘKNE podsumowanie tematu !

Statystyki: Napisane przez mirekk36 — 7 lis 2016, o 10:18

Re: Problem ze stabilnością timera programowego.

2016-11-07T08:59:43+01:00

APAP75 napisał(a):

Co to właściwie jest licznik programowy?

A kto tu mówi o liczniku programowym ? ... normalnie co odpowiedź w tym wątku to kompletne niezrozumienie ... masz w tytule "timer programowy" to jedno

APAP75 napisał(a):

Jeżeli jednak robimy to w określonych, stałych odstępach czasu - np. w funkcji obsługi przerwania timera, to dokładność takiego "timera programowego" jest dokładnie taka sama jak dokładność timera sprzętowego, który go wyzwala.

Tu albo nadal nie rozumie kolega co to timer programowy albo kompletnie nie wie w czym rzecz ....

Timer programowy jest wprawdzie napędzany w przerwaniu - ALE ... ale jego realizacja - czyli wywoływane zdarzenia są odpalane w pętli głównej a w niej mogą być umieszczane różne inne funkcje mniej lub bardziej blokujące co ZDECYDOWANIE może wpłynąć na czas albo precyzyjniej mówiąc na rozbieżności czasowe wykonywania się takich procesów i jest to z założenia działania timera programowego NORMALNE zjawisko ...

NIE MA WIĘC mowy - że DOKŁADNOŚĆ timera programowego będzie taka sama jak sprzętowego .... no chyba, że ktoś właśnie mocno nie rozumie co to jest timer sprzętowy - to ok - wtedy można mówić takie dziwne rzeczy .... albo nazywać timer programowy jakimś tam licznikiem ...

Zwracam na to uwagę z uporem maniaka - a jeśli ktoś nie rozumie nadal co to "timer programowy" no to proszę dopytać, napisać czego się nie rozumie - itp ... chętnie podpowiem i odpowiem na każde pytanie.

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

APAP75 napisał(a):

Barti9 - wrzuć cały kod,

I to jest PODSTAWA - zamiast beletrystycznych opisów i domysłów czy mikrokontroler jest wadliwy ?

Statystyki: Napisane przez mirekk36 — 7 lis 2016, o 08:59

Re: Problem ze stabilnością timera programowego.

2016-11-07T08:48:17+01:00

Niby rozumiem, ale pojąć nie mogę.

mczarny napisał(a):

odpowiedź jest jedna: TAK może się późnić, śpieszyć albo raz późnić raz śpieszyć i to o DUŻO WIĘKSZE wartości niż tu podajesz .... i dodam pewnie dla ciebie zagadkowo. TO JEST PRAWIDŁOWE jeśli chodzi o timer programowy ! ... Ba! ... powiem więcej - jak na timer programowy ta niedokładność o której piszesz to i tak jakiś rekord świata DOKŁADNOŚCI dla timera programowego

Co to właściwie jest licznik programowy? Rozumiem, że jest to jakaś liczba, którą zwiększamy/zmniejszamy co jakiś określony czas.
Jeśli tak jest, to gdy zmieniamy jej wartość na delay'ach, powyższe zdanie ma sens.
Jeżeli jednak robimy to w określonych, stałych odstępach czasu - np. w funkcji obsługi przerwania timera, to dokładność takiego "timera programowego" jest dokładnie taka sama jak dokładność timera sprzętowego, który go wyzwala. Wszelkiego rodzaju odstępstwa wynikają tylko z niezrozumienia noty aplikacyjnej lub złego kodu.

WSZYSTKIE moje błędy zawsze sprowadzały się do powyższego (Panowie - kiedyś wymieniłem ATmega128, a okazało się, że błąd był w źle ustawionych fusebitach - i co... mam teraz dwie ATmegi128 )

Barti9 - wrzuć cały kod, to być może ktoś go wgra na procka i przetestuje (lub jakiś megamózg z forum po jednym rzucie oka napisze - TU JEST ŹLE). A błędy czasem wkradają się w najmniej spodziewanym miejscu. Sam jestem trochę zaintrygowany Twoim postem i ciekawi mnie rozwiązanie Twojego problemu.

Statystyki: Napisane przez APAP75 — 7 lis 2016, o 08:48

Re: Problem ze stabilnością timera programowego.

2016-11-07T06:47:33+01:00

(tak dla wyjaśnienia bo widzę, że powtarzasz ten sam błąd - to dekrementacja a nie deklementacja ok?)

Barti9 napisał(a):

Obsługę przerwania napisałem świadomie bez przypisywania nowo stworzonej zmiennej wartości zmiennej Timer1 a później jej deklementacji jak to jest napisane w książce ponieważ instynktownie stwierdziłem że jest to zbędne wydłużanie ilości instrukcji, lecz po głębszym zastanowieniu możliwe że jest to powodem zakłóceń.

Zaczynasz się uczyć programowania, ok ... więc tym bardziej nie polegaj na "instynkcie" bo on cię zwodzi na mega manowce - zamiast instynktu włącz dociekliwość a jak czegoś nie wiesz to dopytaj ... bo sam sobie kładziesz kłody pod nogi. Bo ani nie jest to ŻADNYM powodem wyimaginowanych przez ciebie zakłóceń, ani nie jest to żadne wydłużanie ilości instrukcji a wręcz przeciwnie - ZNACZNE przyśpieszenie działania tego fragmentu kodu - który jest napisany tak jak w książce a nie tak jak w twoim wypadku co może mieć szczególnie znaczenie jeśli chodzi o napędzanie timerów programowych...

Barti9 napisał(a):

Przerwanie jest wywoływane z częstotliwością 64 khz. Pomimo wyższej częstotliwości niz wywolywanie się przerwania timera 16 bit(1 khz), dokładność na oko jest idealna. W obsłudze przerwań jest kod odpowiedzialny za podział częstotliwości przez 64000 czego rezultatem jest deklementacja zmiennej Timer1 co sekundę.

Po tym co piszesz widać też, że na razie przynajmniej nie masz zielonego pojęcia o asemblrze ... skoro odpalasz przerwanie z częstotliwością 64 kHz (a nie wiem nawet co w nim wyprawiasz) ...

i do tego piszesz już KOSMICZNE wizje typu:

Barti9 napisał(a):

, być może powodem są zewnętrze zakłócenia lub wadliwy mikrokontroler? Co o tym sadzicie?

Postaraj się zapamiętać na całe swoje programistyczne życie, że im częściej będziesz wymyślał aż TAK mocno kosmiczne historie - tym gorzej będzie ci się uczyć a na pewno proces uczenia wydłuży ci się gigantycznie .... Tyle mogę napisać o tym co sądzę na taki pomysł ...

Jeśli chcesz odpalać przerwanie z częstotliwością 64 kHz to się grubo zastanów i zajrzyj do pliku *.lss po kompilacji, żeby zobaczyć ile w tym przerwaniu masz instrukcji asemblerowych. Pewnie cię to zaskoczy ile ich tam wlazło - nawet jeśli w C napisałeś np tylko jedną albo dwie linijki kodu..... Pewnie nie słyszałeś o tzw PROLOGU i EPILOGU kodu asemblerowego w ramach każdej funkcji, a zajmują one również nie tylko pamięć Flash ale i CZAS .... rozumiesz? CZAS wykonywania się. Weź sobie byle dokumentację w której zawsze masz podane ilości taktów przypadające na każdą komendę asm, zlicz sobie wtedy czas realizacji procedury obsługi przerwania i wtedy może dopiero to coś ci powie ... i zrozumiesz dlaczego trzeba uważać z częstotliwością przerwań w stosunku do ilości kodu która jest w nich realizowana ...

wtedy też zobaczysz i zrozumiesz że pisanie o wadliwym mikrokontrolerze w tym aspekcie to jakaś kosmiczna teoria ....

Przy okazji obejrzyj że sobie ten poradnik o przerwaniach:
https://www.youtube.com/watch?v=J82_Zop9cjE

(jest on może troszkę z przymrużeniem oka ale pokazuje to co może się dziać gdy ktoś nie zdaje sobie sprawy z tego jak działają przerwania i może ci się to mocno przydać)

Statystyki: Napisane przez mirekk36 — 7 lis 2016, o 06:47

Re: Problem ze stabilnością timera programowego.

2016-11-07T01:32:40+01:00

Witam, dziękuję za wszelkie odpowiedzi. Ogólnie program jest do celów eksperymentalnych. Obsługę przerwania napisałem świadomie bez przypisywania nowo stworzonej zmiennej wartości zmiennej Timer1 a później jej deklementacji jak to jest napisane w książce ponieważ instynktownie stwierdziłem że jest to zbędne wydłużanie ilości instrukcji, lecz po głębszym zastanowieniu możliwe że jest to powodem zakłóceń.
Idąc dalej uruchomilem drugi timer o rozdzielczości 8 bit, wartość ocr jest równa 249 a preskaler jest ustawiony na 1. Przerwanie jest wywoływane z częstotliwością 64 khz. Pomimo wyższej częstotliwości niz wywolywanie się przerwania timera 16 bit(1 khz), dokładność na oko jest idealna. W obsłudze przerwań jest kod odpowiedzialny za podział częstotliwości przez 64000 czego rezultatem jest deklementacja zmiennej Timer1 co sekundę.
W pętli głównej programu jest tylko i wyłącznie funkcja warunkowa sprawdzająca czy wartość Timer1 jest równa zero, więc timer programowy powinien działać bez zarzutu, o ile można to tak nazwać bo jedynie ma za zadanie dzielić częstotliwość taktowania.
Sprawa wydaje się dziwna, być może powodem są zewnętrze zakłócenia lub wadliwy mikrokontroler? Co o tym sadzicie?

Pozdrawiam Bartek

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

Witam, dziękuję za wszelkie odpowiedzi. Ogólnie program jest do celów eksperymentalnych. Obsługę przerwania napisałem świadomie bez przypisywania nowo stworzonej zmiennej wartości zmiennej Timer1 a później jej deklementacji jak to jest napisane w książce ponieważ instynktownie stwierdziłem że jest to zbędne wydłużanie ilości instrukcji, lecz po głębszym zastanowieniu możliwe że jest to powodem zakłóceń.
Idąc dalej uruchomilem drugi timer o rozdzielczości 8 bit, wartość ocr jest równa 249 a preskaler jest ustawiony na 1. Przerwanie jest wywoływane z częstotliwością 64 khz. Pomimo wyższej częstotliwości niz wywolywanie się przerwania timera 16 bit(1 khz), dokładność na oko jest idealna. W obsłudze przerwań jest kod odpowiedzialny za podział częstotliwości przez 64000 czego rezultatem jest deklementacja zmiennej Timer1 co sekundę.
W pętli głównej programu jest tylko i wyłącznie funkcja warunkowa sprawdzająca czy wartość Timer1 jest równa zero, więc timer programowy powinien działać bez zarzutu, o ile można to tak nazwać bo jedynie ma za zadanie dzielić częstotliwość taktowania.
Sprawa wydaje się dziwna, być może powodem są zewnętrze zakłócenia lub wadliwy mikrokontroler? Co o tym sadzicie?

Pozdrawiam Bartek

Statystyki: Napisane przez Barti9 — 7 lis 2016, o 01:32

Re: Problem ze stabilnością timera programowego.

2016-11-06T21:01:12+01:00

Nie chodzi o to że coś jest źle - tylko od dłuższego czasu wszyscy zastanawiają się jakby i szukają przyczyny tak dużych rozbieżności w timerze programowym PODKREŚLAM, programowym - np w dokładności kwarcu - to jest wg mnie irracjonalne - więc ok wyjaśnię po raz kolejny

timer programowy - to taki "twór" który z założenia może działać BARDZO NIEDOKŁADNIE ... czyli korzystamy z niego w tych sytuacjach gdy nie ma znaczenia czy jakiś proces, którym zawiaduje timer programowy wykona się np co sekundę czy może co sekundę 250 ms albo co np sekundę i 500 ms (czyli aż 50% dłużej)

TO JEST ISTOTA RZECZY i proszę tego nie mylić z działaniem timera sprzętowego - który akurat IDEALNIE, podkreślam IDEALNIE nadaje się na realizację stopera i nawet nie ma co wtedy rozważać czy w międzyczasie wykonują się inne przerwania ....

BRAK ZROZUMIENIA tego co wyżej napisałem - NIGDY nie pozwoli początkującym zrozumieć co oznacza potoczne pojęcie "WYKONYWANIA SIĘ KILKU RZECZY NARAZ W TYM SAMYM CZASIE"

--------------------------------------------------------------------

realizacja stopera w oparciu nawet o "kulawy" kwarc 16 MHz ze słabą nawet wartością ppm ale przy wykorzystaniu timera sprzętowego da w 100% zadowalające rezultaty ... I nie trzeba żadnych specjalizowanych układów czasowych. No chyba, że ktoś chce zrobić jakiś mega dokładny stoper liczący z dokładnością co do femtosekund ... ale już po pierwszym poście widać, że chodzi o jakiś najzwyklejszy stoperek że tak powiem.

a więc podchodząc do realizacji niektórych założeń projektowych warto po prostu uczyć się dobierać narzędzia...

Jeśli chcemy żeby np jakiś proces wykonywał się MNIEJ-WIĘCEJ co sekundę, hmmm co 5 sekund i nie robi nam różnicy że czasem będą odchyłki nawet o 20% , 30 % albo i 50% .... a takich zadań w projektach mamy na kopy - to IDEALNIE wpasowują się tu timery programowe. Przy założeniu takich procentowych błędów - dokładność kwarca ma się jak pięść do oka ...

i to proszę zrozumieć.

Statystyki: Napisane przez mirekk36 — 6 lis 2016, o 21:01

Re: Problem ze stabilnością timera programowego.

2016-11-06T17:39:41+01:00

Bo kompilatory języków wysokiego poziomu muszą rozłożyć to na części pierwsze które trochę trwają czyli np inkrementacja może trwać koło 4-5 takty, przypisanie zmiennej wartości innej zmiennej z 8 taktów a if(a+b>c) z 10 takty. Ify mogą nawet 20 taktów zjeść. W Assemblerze masz pełną kontrolę nad czasem wykonania programu, więc napisz w assemblerze program albo wstaw wstawkę assemblerową.

Statystyki: Napisane przez Situs — 6 lis 2016, o 17:39

Re: Problem ze stabilnością timera programowego.

2016-11-06T16:59:23+01:00

squeez napisał(a):

Więc jeśli chcesz używać czegoś takiego do odmierzania czasu to trzeba brać to pod uwagę.

ale chyba kolega nie zauważył, że tu chodzi o timer programowy a nie sprzętowy ....

więc po raz kolejny przypomnę - to nie ma nic wspólnego z dokładnością kwarca

Statystyki: Napisane przez mirekk36 — 6 lis 2016, o 16:59

Re: Problem ze stabilnością timera programowego.

2016-11-06T14:51:50+01:00

Barti9 napisał(a):

if(Timer1)
Timer1--;

Pomijam już fakt - że robisz sam sobie KUKU - bo nie tak jak w Bluebooku .... ale mi rym wyszedł i nawet nie będę już tego komentował ...

no to stwierdzenie z tytułu wątku oraz to:

Barti9 napisał(a):

Po 20 minutach pracy, stoper uruchomiony na timerze 16 bit śpieszy się o około 40 sekund.

Jeśli jest realizowane na timerze programowym - no to już jest to MEGA KOMPLETNY NONSESN .... po prostu masakra niezrozumienia - pomimo to, że nie dość, że w książce JAK BYK i NA TACY (już nie mogę tego inaczej określić, sorki) - podaję o co chodzi z timerami programowymi ....

ok może nie masz Bluebooka - to co z tego - jeśli kod zaczerpnąłeś gdzieś z poradników wideo to oznacza, że też musiałeś w ogóle nie słuchać tego co mówię w poradnikach .... a jeśli zaczerpnąłeś gdzieś z forum to znaczy że kompletnie bez zrozumienia ....

-----------------------------------------

odpowiedź jest jedna: TAK może się późnić, śpieszyć albo raz późnić raz śpieszyć i to o DUŻO WIĘKSZE wartości niż tu podajesz .... i dodam pewnie dla ciebie zagadkowo. TO JEST PRAWIDŁOWE jeśli chodzi o timer programowy ! ... Ba! ... powiem więcej - jak na timer programowy ta niedokładność o której piszesz to i tak jakiś rekord świata DOKŁADNOŚCI dla timera programowego

może któryś kolega tobie wyjaśni dla czego - bo sorki ale ja - jak pisałem za dużo opisywałem to w książce i omawiałem w poradnikach wideo i nie mam już siły .... a i na forum mnóstwo razy o tym mówiłem - nawet o tym błędzie w kodzie który pokazałem na początku

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

mczarny napisał(a):

Po pierwsze czy jesteś pewien, że kwarc generuje dokładnie 16MHz

To nie ma NIC WSPÓLNEGO - nawet gdyby ktoś miał atomowy wzorzec czasu to i tak timer programowy będzie miał takie rozrzuty i to jest (co ciekawe - przypominam) N O R M A L N E

Statystyki: Napisane przez mirekk36 — 6 lis 2016, o 14:51

Re: Problem ze stabilnością timera programowego.

2016-11-06T11:31:28+01:00

cześć

myślę, że niestety ale nie uzyskasz zakładanej dokładności w ten sposób.
Po pierwsze czy jesteś pewien, że kwarc generuje dokładnie 16MHz - prawdopodobnie nie
możesz oczywiście wpisywać do rejestru porównania wartości większe lub mniejsze od wyliczonych 2000 tylko, że to i tak na dłuższą metę nie zda egzaminu.
Ja bym poszedł w stronę zewnętrznego układu RTC gdzie stabilność generowanych przebiegów jest dużo większa.
Układ pracujący jako stoper więc zakładam, że potrzebujesz nie tylko sekundy ale dziesiąte i setne a tu to już wchodzą zależności czasowe poszczególnych instrukcji wykonywanych przez procesor

pozdrawiam

Statystyki: Napisane przez mczarny — 6 lis 2016, o 11:31