ATNEL tech-forum 2022-05-06T08:57:05+01:00 https://forum.atnel.pl/feed.php?f=4&t=24214&mode 2022-05-06T08:57:05+01:00 2022-05-06T08:57:05+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235477#p235477 <![CDATA[Re: Timery programowe, nierówna praca]]> SylwekK napisał(a):

nie większą niż 1ms - dość często 100us, a bywało, że i 50us

Tak też podejrzewałem, ze w tym wątku piszemy głównie o CZYM INNYM.
Ja o softTimerach w rozumieniu bluebook, a Autor o czym innym :)
Jakiś kod ma u siebie, do wątku wrzuca jakieś tylko swoje zmiany wyrwane z kontekstu, opisuje to kodem przepisanym "żywcem" z książki, a tak na prawdę to działa chaotycznie, nieprecyzyjnie przedstawia problem. To najgorszy ze sposobów szukania pomocy
Jakie to charakterystyczne dla programistów, którzy już mają sporą wiedzę, ale brakuje pokory :)

SylwekK to już w ogóle o czym innym. soft timer 100us - w ogóle bym tego nie nazwał soft timerem jak uczono nas w Bluebooku.

Dziwię się tylko, że jeszcze takie coś "wchodzi" na forum Atnel, kiedy Mirek od chyba już 10 lat mówi jak działać.

To takie ogólne obserwacje i one tyczą się wszelkim gremiów technicznych.
Musiałem to wyrzuć z siebie, bo od połowy wątku już mnie to gryzło :)
Nie miałem na myśli oczywiście nic złego tak pisząc, jedynie komentuję "rzeczywistość"

Jeszcze apropos roboty Andrews, to faktycznie "wyprostował" mnie w tym sensie, że zupełnie pominąłem fakt możliwości "rozdarcia" warunku IF.
Cały czas byłem skupiony na modyfikacji softTimer1 = 1000, która była zabezpieczona poprzez długi okres między przerwaniami.
Natomiast zarzut o patrzeniu z perspektywy C nie był zasadny, bo pierwsze co zrobiłem przy analizie to spojrzenie do asemblera :)

Tyle wyjaśnień.

Statystyki: Napisane przez Zealota — 6 maja 2022, o 08:57

]]> 2022-05-06T08:08:59+01:00 2022-05-06T08:08:59+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235476#p235476 <![CDATA[Re: Timery programowe, nierówna praca]]> SylwekK napisał(a):

bo stosuję zazwyczaj podstawę nie większą niż 1ms

Ja to doskonale wiem, bo kiedyś pisaliśmy nawet o tym na tym forum i wcale nikt nie jest szalony skoro takich technik używa, po to jest procek, żeby go cisnąć na maxa gdy trzeba. Powiem tak mnóstwo ludzi tak korzysta z procka - tylko, że tego już się nie da nazwać typowymi prostymi timerkami programowymi. W takich wypadkach gdy już schodzisz nawet do 100us czy 50us to jest już odmierzanie czasu dla konkretnych i sam przyznasz b.krótkich zdarzeń bo przecież przy 50us nie powiesz, że pakujesz tam jakiś kod który potrzebuje na wykonanie więcej niż 50us - pewnie zajmuje on nawet mniej niż połowę tego czasu. I to jest normalne jak jedzenie bułek z masłem i serem w programowaniu ... tylko właśnie trzeba mieć już na prawdę dobre doświadczenie w pisaniu programów w sposób nieblokujący ... a wiem, że ty masz i to duże bo już Bascoma wyciskałeś na MAXA kiedyś (ja też zresztą zanim przesiadłem się na C). Dlatego też na końcu mówiłem, że każdy ma rację - tylko w nieco innych aspektach i nie dotyczących koniecznie akurat tego konkretnego przypadku u autora tego wątku.

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

Rnext napisał(a):

Przerwanie miałem ustawione co 1ms. Po zmianie na 10ms efekt "cudów" zniknął.
Dziękuję wszystkim za pomoc i przede wszystkim ciekawą dyskusję.


No i bardzo fajnie - cieszę się, że ruszyło - teraz na pewno w przyszłości łatwiej będzie ci korzystać z tych mechanizmów

Statystyki: Napisane przez mirekk36 — 6 maja 2022, o 08:08

]]> 2022-05-06T07:19:36+01:00 2022-05-06T07:19:36+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235475#p235475 <![CDATA[Re: Timery programowe, nierówna praca]]> Teraz to i mnie się rozjaśniło. Wg powyższego moje problemy z nierównym odliczaniem, są tak widoczne, bo stosuję zazwyczaj podstawę nie większą niż 1ms - dość często 100us, a bywało, że i 50us i mniej. Może to dziwić, ale bardzo mi pomaga takie poganianie przerwań. Często umieszczam tam algorytmy, które wymagają szybkiego odświeżania, a o pętlę główną się nie martwię, bo ZAWSZE jest w pełni przelotowa nawet z wyświetlaczem LCD, który jest buforowany i jego obsługa zajmuje jednorazowo kilka/naście us. Może jestem szalony, ale ja na tych prostych timerach zegary dokładnie odliczające czas zawsze robię :)
Jak w takim razie sobie radzę z dłuższym odcinkami? Na dwa sposoby - dokładny i mniej dokładny (teoretycznie, bo w praktyce nie widzę różnicy). Dokładny to użycie dodatkowej zmiennej w przerwaniach jako dzielnik dziełu czemu z pętli głównej wysyłam do timera zmienną jednobajtową, a mniej dokładny - w przerwaniach jest jeden timer sterujący, a w pętli głównej pod tym timerem kolejne timery już z wykorzystaniem dowolnej zmiennej (nawet 32bitowej). Jak wspominałem pętla główna u mnie jest nieblokująca i zabieg ten w moich programach sprawdza się praktycznie zawsze. Polecam :)

Statystyki: Napisane przez SylwekK — 6 maja 2022, o 07:19

]]> 2022-05-06T06:14:30+01:00 2022-05-06T06:14:30+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235474#p235474 <![CDATA[Re: Timery programowe, nierówna praca]]> Dziękuję wszystkim za pomoc i przede wszystkim ciekawą dyskusję.

Statystyki: Napisane przez Rnext — 6 maja 2022, o 06:14

]]> 2022-05-05T22:43:21+01:00 2022-05-05T22:43:21+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235473#p235473 <![CDATA[Re: Timery programowe, nierówna praca]]> mtbchn napisał(a):

A w międzyczasie, może Mirosław zabierze głos i wyjaśni powyższe wątpliwości.

Ja tak obserwuję sobie z doskoku tę dyskusję i po prostu oczom własnym nie wierzę ;) ... bo tu w zasadzie jest spór ideologiczny i na dodatek (ku mojemu zdumieniu) kompletnie oderwany od pytania i problemów autora - co zaciemnia w ogóle obraz i wyłania się tylko jedno:

Stosować Atomowe podejście przy timerach programowych czy nie ?

No i są dwie grupy (o ile tak można powiedzieć) bo jedna grupa to zaledwie pojedynczy użytkownik forum - kolega ZELAOTA a druga grupa to kilku użytkowników, którzy przekonują że nie da się inaczej jak bez ATOMIC BLOCK .... i to pomimo to, że ZELAOTA wyraźnie też po drodze pisał, że jak chodzi o problem autora to nie może mieć żadnego wpływu czy mamy podejście atomowe czy nie.

Oczywiście kolega Andrews jak zawsze (spec w asemblerze) ładnie wyłożył i pokazał przykłady (fajna nazwa) ROZRYWANIA zmiennej 16-bitowej podczas gdy wystąpi przerwanie i w ogóle ciężko z tym dyskutować bo taka jest prawda i nie ma co się z tym nawet sprzeczać, że TEORETYCZNIE - może do tego dojść a wtedy w JEDNYM z najgorszych przypadków (którego prawdopodobieństwo wystąpienia jest chyba porównywalne do wygranej w toto lotka) - czyli gdy softimer = 256 i akurat przy sprawdzaniu if() nastąpi przerwanie i to pomiędzy pobieraniem młodszego i starszego bajtu - no to co tu dużo mówić - to jest OCZYWISTE JAK SŁOŃCE że tak będzie - że ten IF się źle wykona i biedny softTimer1 źle zadziała tym razem ....

Krótko mówiąc nawet nie ma co kruszyć kopii że w większości wypadków gdy szczególnie nam zależy na wyśrubowanych warunkach działania programu i korzystamy ze zmiennych więcej niż 8-bitowe w przerwaniu i w programie głównym - to ATOMIC BLOCK musi nam przyrosnąć do ręki ....

ALE ........ no właśnie jest moim zdaniem jedno małe ALE i nie musicie się z tym zgadzać oczywiście

PO PIERWSZE - proste timerki programowe absolutnie nie służą do super precyzyjnego odmierzania czasu - a jeśli ktoś się z tym spiera to jest w błędzie. Bo nawet przy nie wiem jakich ATOMIC BLOKACH - gdy inna część większego programu zużyje dużo więcej czasu niż czas najszybciej ustawionego timera programowego przy podstawie czasu 10ms czyli przy wartości 1, to na kiszkę zdadzą się wszystkie Atomic Bloki

PO DRUGIE - jest dokładnie tak jak pisze ZELAOTA - że skoro podstawa czasu to 10ms to jest to KOSMICZNY odstęp od przerwania do przerwania więc prawdopodobieństwo tego, że kolejne przerwania timera sprzętowego utrafią akurat w obsłudze tych timerków programowych w IF()'a albo w ładowanie nowej wartości do softTimer - moim zdaniem jest właśnie jak w totolotku albo i jeszcze mniejsze


Zealota napisał(a):

Od momentu uruchomienia globalnego przerwań sei() do pierwszego wejścia w warunek if (softTimer1 == 0) {} przerwanie może zaburzyć ten warunek wpisując "randomowe" wartości do zmiennej, poprzez rozerwanie dwubajtowej wartości softTimer1.

Wcale nie - będzie dużo lepsza sytuacja i nie będzie ŻADNYCH randomowych wartości które mogą zaburzyć przy starcie bo przecież jeśli zmienne globalne softTimers nie są zainicjowane to mają wartość = 0, więc przerwanie przy starcie ich nie będzie ruszać. Przerwanie wystartuje od razu po SEI() i nie zmieni wartości żadnego softTimera i UWAGA! bo tu ZELAOTA ma rację, następne przerwanie odbędzie się aż za 10 ms, zatem rozpocznie się pętla główna która odpali każdy softTimer i ustawi im wartości na nowe, czyli ich zmniejszanie w przerwaniu rozpocznie się za jakiś czas ...

... i OK nie jesteśmy w stanie przewidzieć kiedy nadejdzie to kolejne przerwanie za 10ms to czy akurat nie trafi w któregoś IF()'a albo w któreś napełnianie nową wartością jednego z softTimerów. Ale zakładając - że NAWET TRAFI w któregoś IF()'a to teraz czy akurat trafi nie dość że dokładnie w momencie ładowania dwóch bajtów do porównania ... .i ..... dodatkowo gdy akurat w softTimer jest wartość 256 ????? (oczywiście ja rozumiem Andrews - że to nie chodzi o tylko ten przypadek ale o każdy inny bo można twój przykład w ASM rozpisać sobie dla wartości nie 256 ale np 512 albo i dla byle jakiej np 613 ... i bez ATOMIC BLOCK gdyby te przerwanie trafiało akurat zawsze na IF()'y i rwało nawet te porównania to będą one zakłócone - ale o ile ? wziąwszy pod uwagę podstawę czasu 10ms ? ... o tyle co było utracone w młodszym bajcie - czyli softTimer zadziała załóżmy nieco albo i sporo szybciej niż trzeba - a nie że program się (potocznie mówiąc) WYSYPIE.

Mi nawet przez myśl nie przechodzi żeby się zastanawiać i dbać o to czy przy zastosowaniu prostych timerków programowych brać pod uwagę takie różnice czasu. To jest kompletnie nieistotne

a teraz NAJWAŻNIEJSZE - spróbujcie się Panowie - którzy tak naciskacie na atomowe podejście przy tych timerkach ... więc spróbujcie powiedzieć - przypatrzyć się, przeanalizować kod autora !!!! Pomijam że autor gra w mega kalambury i przez cały wątek ktoś go wciąż prosi żeby udostępnił kolejny puzzel kodu bo nie wiadomo co może mu źle działać ... że jaki TAKT jest zakłócony jeśli chodzi o BUZZER .... więc proszę - powiedzcie mi czy analizowaliście ten kod - zbierając puzzle z kolejnych postów - bo ja w końcu tak - i co ? NADAL nie wiadomo co ile dokładnie czasu on odpala ten buzer żeby słyszeć równy takt. Nie wiemy bowiem o kolejnym puzlu czyli jaką częstotliwością jest taktowany u niego procek i czy aby na pewno w ogóle korzysta z podstawy czasu dla timerów 10Hz ? Ja coś w to bardzo wątpię i już to może być pierwszym krokiem do jego problemów a nie żaden brak atomowiści w tych timerkach bo to wręcz nonses !

Zobaczcie sami że w przykładowych kawałkach kodu które pokazał - przeładowuje timer buzzera wartością 1000 !!!!!!

[syntax=c]if (!timer1) {
BUZZER_TOGGLE;
timer1 = 1000;
}[/syntax]

czyli gdyby była podstawa czasu 10ms to buzzer brzęczałby przez 10s i przez kolejne 10s byłby cicho - CZY DAŁOBY się usłyszeć różnice w takim TAKCIE ???? gdyby zmieniał się powiedzmy nawet o kilkadziesiąt ms ????????????

No dobra - załóżmy że autor ustawił sobie jakąś randomową podstawę czasu albo nawet niech będzie że ustawił podstawę czasu 1ms co wg mnie jest już nonsensem (albo nie będzie nonsensem dla kogoś kto ew już ma większe doświadczenie w pisaniu programów w sposób nieblokujący i w takim wypadku rzeczywiście warto byłoby już sięgać po AtomicBLOCK) ... Więc jeśli ja miałbym pomóc autorowi w rozwiązaniu problemu to najpierw nakierowałbym go na właściwe tory - żeby zaczął od podstaw bo widać, że jeszcze jest mocno początkujący, a szczególnie w porządnym opisie problemu.

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

krótko albo długo mówiąc ALE WYJAŚNIAJĄC dokładnie przyczynę problemów autora - proszę bardzo pierwszy przykład, z porządną podstawą czasu 10ms dla timerów programowych - jak w Bluebooku - a autor zarzekał się, że wszystko zrobił jak z Bluebooka - ileż ja to razy już słyszałem, a wszyscy poszli tropem opowieści autora - wierząc mu że zrobił jak w Bluebooku - no to jeśli słyszy różny TAKT - to nic tylko ATOMIC BLOCK nie dał ;)

A tymczasem to jest dla niego prawidłowy kod i to bez żadnych kocich kalamburów - w którym widać jak na dłoni co i jak jest skonfigurowane
[syntax=c]/* F_CPU = 11,0592 MHz */
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <util/delay.h>
#include <avr/wdt.h>
#include <stdio.h>

#define LED(1<<PC4)
#define BUZ(1<<PC7)

volatile uint16_t timer1, timer2;

int main() {

DDRC |= LED|BUZ;

/* Timer2 – inicjalizacja przerwania co 10ms */
TCCR2 |= (1<<WGM21);// tryb pracy CTC
TCCR2 |= (1<<CS22)|(1<<CS21)|(1<<CS20);// preskaler = 1024
OCR2 = F_CPU/1024/100;// przerwanie porównania co 10ms (100Hz) !!!!!!!! 10 ms !!!!!!!!!!
TIMSK = (1<<OCIE2);// Odblokowanie przerwania CompareMatch

sei();

while (1) {


if( !timer2 ) {
PORTC ^= LED;
timer2 = 300;
}

if( !timer1 ) {
PORTC ^= BUZ;
timer1 = 100; // <---------- tyle że zmieniam stan buzera co ok SEKUNDĘ !!!!!
}
}
}

ISR( TIMER2_COMP_vect ) {

uint16_t x;

x = timer1;
if( x ) timer1 = --x;

x = timer2;
if( x ) timer2 = --x;
}[/syntax]

No i niech mi ktoś powie, że tu coś będzie źle śmigało bez atomowego podejścia - MOWA O TYM PROSTYM KODZIE - a nie o domysłach - co by było gdyby, warto się czasem skupić na problemie autora. Ja wprawdzie gdy widzę że kogoś trzeba ciągnąć za język to się po prostu wyłączam i nic dalej się nie odzywam bo po co - strata czasu. Ale że rozgorzała - fajna dyskusja ;) to w końcu też zabrałem głos - ot mogłem się oderwać na chwilę od kursu ESP :)

ale żeby nie było że sobie gdybam to proszę widok z analizatora:
Obrazek

no i zobaczcie Panowie, którzy twierdzicie że tu bez atomic block się nie obejdzie - jak pomimo wszystko są równe odcinki czasu - ok wprawdzie mało ich widać ;) ale spokojnie poczekajcie co dalej pokażę


więc tu spłodziłem nowy kod - tyle że prawdopodobnie zbliżony jak chodzi o czasówki do tego co stworzył autor i to być może nieświadomie - albo i świadomie ale nie raczył puzla pokazać ;)

TYM RAZEM ----- UWAGA !!!! ------ podstawa czasu = 1ms !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
[syntax=c]/* F_CPU = 11,0592 MHz */
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <util/delay.h>
#include <avr/wdt.h>
#include <stdio.h>

#define LED(1<<PC4)
#define BUZ(1<<PC7)

volatile uint16_t timer1, timer2;

int main() {

DDRC |= LED|BUZ;

/* Timer2 – inicjalizacja przerwania co 10ms */
TCCR2 |= (1<<WGM21);// tryb pracy CTC
TCCR2 |= (1<<CS22)|(1<<CS21)|(1<<CS20);// preskaler = 1024
OCR2 = F_CPU/1024/1000;// przerwanie porównania co 1ms (1000Hz) ****** 1 ms *******
TIMSK = (1<<OCIE2);// Odblokowanie przerwania CompareMatch

sei();

while (1) {


if( !timer2 ) {
PORTC ^= LED;
timer2 = 300;
}

if( !timer1 ) {
PORTC ^= BUZ;
timer1 = 1000; // <---------- 1000 ale też zmieniam stan buzera co ok SEKUNDĘ !!!!!
}
}
}

ISR( TIMER2_COMP_vect ) {

uint16_t x;

x = timer1;
if( x ) timer1 = --x;

x = timer2;
if( x ) timer2 = --x;
}[/syntax]

no i może zanim coś powiem to rzućcie okiem na widok z analizatora:
Obrazek

widzicie różnicę ???? Nagle się okazuje, że bardzo często wskakują krótsze odcinki czasowe niż 1s !!!! te krótsze są krótsze aż o ok 30% !!!!! Jak myślicie z czego to wynika ????? .... No to dodajmy ATOMOWE PODEJŚCIE ;)

Więc ten sam kod co wyżej z podstawą czasu 1 ms !!!!!!!!! ale z ATOMIC BLOCK
[syntax=c]/* F_CPU = 11,0592 MHz */
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <util/delay.h>
#include <avr/wdt.h>
#include <stdio.h>

#define LED(1<<PC4)
#define BUZ(1<<PC7)

volatile uint16_t timer1, timer2;

int main() {

DDRC |= LED|BUZ;

/* Timer2 – inicjalizacja przerwania co 10ms */
TCCR2 |= (1<<WGM21);// tryb pracy CTC
TCCR2 |= (1<<CS22)|(1<<CS21)|(1<<CS20);// preskaler = 1024
OCR2 = F_CPU/1024/1000;// przerwanie porównania co 1ms (1000Hz) ****** 1 ms *******
TIMSK = (1<<OCIE2);// Odblokowanie przerwania CompareMatch

sei();

while (1) {


if( !timer2 ) {
PORTC ^= LED;
timer2 = 300;
}

uint8_t sreg = SREG;
cli(); // ATOMIC BLOCK manualnie ;)
uint16_t t1 = timer1;
SREG=sreg;
if( !t1 ) {
PORTC ^= BUZ;

uint8_t sreg = SREG;
cli(); // ATOMIC BLOCK manualnie ;)
timer1 = 1000;
SREG=sreg;
}
}
}

ISR( TIMER2_COMP_vect ) {

uint16_t x;

x = timer1;
if( x ) timer1 = --x;

x = timer2;
if( x ) timer2 = --x;
}[/syntax]

no i już nie będę wklejał kolejnego obrazka z analizatora - bo wygląda on DOOOOKŁAAADNIE tak samo jak ten pierwszy który pokazałem - czyli czasy są równe i wynoszą 1,009 s !!! czyli znowu dobrze !

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

PODSUMOWUJĄC - rację mają wszyscy i zwolennicy łupania wszędzie ATOMIC BLOCK nawet bez zastanowienia się - no bo to szkody jakiejś nie przyniesie .... przecież ... ale zawsze dodatkowy kod, miejsce we flashu ;) no i zawsze parę taktów ale zegara ubywa hahahahaha ;)

Rację też ma ZELAOTA - ale właśnie w aspekcie tego co mówił - czyli kodu autora że na kodzie z BLUEBOOKA nie może mieć ŻADNYCH niespodzianek, tylko że każdy wierzy że jak autor napisał - że na 100% zrobił jak w książce to to prawda - a po pierwszej pobieżnej analizie jego kodu widać że NIEPRAWDA bo właśnie podstawa czasu wg mnie jest na 100% inna niż ta o której mówię w Bluebooku i NACISKAM wręcz że dla prostych timerków programowych nie schodźcie poniżej 10ms .... Ale co tam pomyślał autor ;) i zrobił po swojemu. Tyle że ciekaw jestem czy ten czas dobrał świadomie czy przypadkowo mu tak wyszło - jeśli się nie obrazi to może odwróci ostatnie puzzle i wypowie się - co i jak ustawiał i jakie ma F_CPU i dlaczego zrobił TAK a nie jak Bluebooku. A na dodatek może sobie skopiować ten pierwszy kod - który pokazałem z timerami z podstawą 10ms (tylko niech przerobi rejestry dla swojego procka bo nie miał m32 tylko jakiś nowszy) i niech sprawdzi sobie jeden, drugi i trzeci kod który pokazałem - to mam nadzieję, że w końcu mu to coś powie.

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

Na ZAKOŃCZENIE moja odpowiedź:

TAK tego typu proste timerki programowe można używać bez ATOMIC BLOCK bo po to one są stworzone i nawet jeśli raz na pierdyliard obiegów pętli głównej dojdzie do super specyficznej sytuacji jaką słusznie opisał i pokazał w ASM kolega Andrews - to proszę pamiętać - timerki programowe mogą mieć spory rozrzut i są używane do rozdzielania czasu dla ZADAŃ - coś na zasadzie RTOS'a ;)

zresztą jak myślicie - dlaczego w RTOS'ach - nawet na bajecznie szybszych procesorach - podstawa czasu to właśnie 10ms a nie żadna 1ms ?

Tak więc Andrews nie myśl, że ja tu chcę z kolei podważać to co mówisz - i widzisz że przyznaję rację nawet w tym, że i w tych timerkach programowych może dojść (choć wg mnie cholernie rzadko - totolotek) do takich sytuacji o których piszesz - tak więc tu chodzi też troszkę o taką hmmm praktykę programowania

ZELAOTA - jeśli miałeś na myśli podstawę czasu 10ms - to praktycznie wszystkie twoje uwagi były słuszne - szczególnie te odnośnie że chodzi o problem autora i że nie może się tu nic złego dziać, i o to, że takie przerwanie praktcznie nie będzie trafiać przy podstawie 10ms ani drastycznie niszczyć czasów pracy timerów - a NAWET jeśli raz na miliard obiegów jakiś TASK (timer programowy wykona szybciej swoje zadanie) to nikt od tego nie zginie - o ile wie co to są timery programowe i jak się z nich korzysta i wie jak pisać programy w sposób nieblokujący.

.... miało być krótko - a wyszło jak to u mnie - poemat - sorki ;)

Statystyki: Napisane przez mirekk36 — 5 maja 2022, o 22:43

]]> 2022-05-05T12:48:39+01:00 2022-05-05T12:48:39+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235472#p235472 <![CDATA[Re: Timery programowe, nierówna praca]]> Zealota nie masz racji.

Patrzysz na program z punktu widzenia języka C, a tu (aby zrozumieć problem) niestety trzeba spojrzeć na asemblera, bo instrukcje języka C nie są wykonywane przez mikrokontroler "atomowo".

Przykładowo instrukcja porównania softTimer1==0 wymaga najpierw załadowania obydwu bajtów zmiennej softTimer1 do rejestrów. Odbywa się to w dwóch taktach mikrokontrolera, między którymi może wystąpić przerwanie, które zmodyfikuje zawartość zmiennej. Spowoduje to, że w rejestrach R25:R24 zmienna zostanie złożona z młodszego bajtu zmiennej softTimer1 w RAM przed modyfikacją i starszego bajtu zmiennej softTimer1 w RAM po modyfikacji (w przerwaniu), czyli wartość zmiennej będzie nieprawidłowa. I to na tyle. Struktura programu w języku C jak i wywłaszczanie nie mają tu nic do rzeczy. istotny jest tylko ten fragment dwóch instrukcji asm, pomiędzy którymi może wystąpić przerwanie (które zmodyfikuje wartość kopiowanej akurat zmiennej).

Właściwie jedynym sensownym rozwiązaniem tego problemu jest wyłączenie przerwań na czas kopiowania z RAM do rejestrów, czyli w asemblerze wyglądałoby to tak:[syntax=asm];
CLI
LDS R24,0x0100 ; Load direct from data space
; tutaj może wystąpić przerwanie
LDS R25,0x0101 ; Load direct from data space
SEI
OR R24,R25 ; Logical OR
BRNE PC-0x05 ; Branch if not equal
;[/syntax]
W C można użyć makra ATOMIC_BLOCK() lub instrukcji cli(); i sei();

Statystyki: Napisane przez andrews — 5 maja 2022, o 12:48

]]> 2022-05-05T11:29:04+01:00 2022-05-05T11:29:04+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235471#p235471 <![CDATA[Re: Timery programowe, nierówna praca]]> Zealota napisał(a):

andrews napisał(a):
Scenariusz może być taki:

Świetnie opisałeś moment "rozrywania" zmiennej, natomiast wg mnie takie coś w tym przykładzie być może nastąpi raz, na początku, po starcie programu.

Od momentu uruchomienia globalnego przerwań sei() do pierwszego wejścia w warunek if (softTimer1 == 0) {} przerwanie może zaburzyć ten warunek wpisując "randomowe" wartości do zmiennej, poprzez rozerwanie dwubajtowej wartości softTimer1.

Natomiast po wyjściu z pierwszego przerwania następne będzie dopiero po milisekundach. Być może pierwszy "tik" będzie dłuższy albo krótszy od zadanego softTimer1, ale następnie dojdzie do zsychronizowania pętli głównej z licznikiem i przerwaniami, a późniejsze sekwencje będą już "po kolei" i zgodnie z założeniami dla TEGO przykładu

Jak pisałem wyżej:
1. Obsługa przerwania bezwzględnie blokuje obsługę kodu pętli while.
2. Pętla while nie "wywłaszcza" przerwania
3. Nie ma nic innego co "wywłaszczy" przerwanie i rozerwie słowo na bajty

Te trzy warunki zapewniają, że po "rozkręceniu" licznika przerwań program będzie pracował poprawnie.
Dodatkowo modyfikacja zmiennej softTimer1 przez pętlę główną, będzie zawsze po kilkunastu mikrosekundach od wyjścia z przerwania i czasu starczy na poprawną obsługę zmiennej softTimer1. Wyjście z przerwania da zawsze stabilną wartość zmiennej softTimer1
Stabilność "danych" w pętli while zapewnia bardzo długi czas pomiędzy przerwaniami.

Może źle to tłumaczę, może mi coś umyka, ale ten przykład musi działać poprawnie.
Dziś jeszcze dokonam prób sprzętowych na większej liczbie zmiennych, może coś się wyjaśni.



Daj znać jak będziesz już po testach. Proponuję pomiar programowych timerów na kilku kanałach analizatora stanów logicznych. Jeśli byś mógł, wrzuć screeny.

A w międzyczasie, może Mirosław zabierze głos i wyjaśni powyższe wątpliwości.

Statystyki: Napisane przez mtbchn — 5 maja 2022, o 11:29

]]> 2022-05-05T10:04:29+01:00 2022-05-05T10:04:29+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235470#p235470 <![CDATA[Re: Timery programowe, nierówna praca]]> andrews napisał(a):

Scenariusz może być taki:

Świetnie opisałeś moment "rozrywania" zmiennej, natomiast wg mnie takie coś w tym przykładzie być może nastąpi raz, na początku, po starcie programu.

Od momentu uruchomienia globalnego przerwań sei() do pierwszego wejścia w warunek if (softTimer1 == 0) {} przerwanie może zaburzyć ten warunek wpisując "randomowe" wartości do zmiennej, poprzez rozerwanie dwubajtowej wartości softTimer1.

Natomiast po wyjściu z pierwszego przerwania następne będzie dopiero po milisekundach. Być może pierwszy "tik" będzie dłuższy albo krótszy od zadanego softTimer1, ale następnie dojdzie do zsychronizowania pętli głównej z licznikiem i przerwaniami, a późniejsze sekwencje będą już "po kolei" i zgodnie z założeniami dla TEGO przykładu

Jak pisałem wyżej:
1. Obsługa przerwania bezwzględnie blokuje obsługę kodu pętli while.
2. Pętla while nie "wywłaszcza" przerwania
3. Nie ma nic innego co "wywłaszczy" przerwanie i rozerwie słowo na bajty

Te trzy warunki zapewniają, że po "rozkręceniu" licznika przerwań program będzie pracował poprawnie.
Dodatkowo modyfikacja zmiennej softTimer1 przez pętlę główną, będzie zawsze po kilkunastu mikrosekundach od wyjścia z przerwania i czasu starczy na poprawną obsługę zmiennej softTimer1. Wyjście z przerwania da zawsze stabilną wartość zmiennej softTimer1
Stabilność "danych" w pętli while zapewnia bardzo długi czas pomiędzy przerwaniami.

Może źle to tłumaczę, może mi coś umyka, ale ten przykład musi działać poprawnie.
Dziś jeszcze dokonam prób sprzętowych na większej liczbie zmiennych, może coś się wyjaśni.

Statystyki: Napisane przez Zealota — 5 maja 2022, o 10:04

]]> 2022-05-04T21:46:12+01:00 2022-05-04T21:46:12+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235469#p235469 <![CDATA[Re: Timery programowe, nierówna praca]]> Statystyki: Napisane przez SylwekK — 4 maja 2022, o 21:46

]]> 2022-05-04T20:41:38+01:00 2022-05-04T20:41:38+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235468#p235468 <![CDATA[Re: Timery programowe, nierówna praca]]> Zealota napisał(a):

Mikrokontroler działa sekwencyjnie. Dopiero zagnieżdżanie przerwań wymusza w odp. momencie atomowość.


W Twoim przykładzie linia 17. (if( softTimer1 == 0 )) wygeneruje mniej więcej taki kod asm:
[syntax=asm];
LDS R24,0x0100;Load direct from data space
; tutaj może wystąpić przerwanie
LDS R25,0x0101;Load direct from data space
OR R24,R25; Logical OR
BRNE PC-0x05;Branch if not equal
;[/syntax]

Jak widać dwubajtowa zmienna softTimer1 jest umieszczona w RAM pod adresami 0x0100 (low) i 0x0101 (high).
Przyjmijmy, że zmienna softTimer1=256, czyli adres 0x0100 = 0x00, a adres 0x0101 = 0x01.


    Scenariusz może być taki:
  • do rejestru R24 zostaje skopiowana wartość niskiego bajtu zmiennej softTimer1, czyli 0x00
  • po tej operacji może nastąpić skok do procedury obsługi przerwania, w której zmienna softTimer1 zostaje zmniejszona o 1, czyli adres 0x0100 zawiera teraz 0xFF, a adres 0x0101 zawiera 0x00,
  • po powrocie z procedury obsługi przerwania do rejestru R25 zostaje załadowana wartość adresu 0x0101, ale teraz już nie 0x01, tylko 0x00
  • obydwa rejestry (R24 i R25) są równe 0x00, w związku z czym operacja testu zmiennej softTimer1==0 da wynik fałszywie pozytywny.

Coś takiego będzie się dziać bez zagnieżdżania, a nawet bez innych przerwań.
Oczywiście nie będzie tak w każdym obiegu timera. Prawdopodobieństwo "trafienia" przerwania w nieodpowiednim momencie może nie jest duże, ale prędzej czy później się przytrafi, w efekcie czego program może działać niestabilnie.

Statystyki: Napisane przez andrews — 4 maja 2022, o 20:41

]]> 2022-05-04T19:00:51+01:00 2022-05-04T19:00:51+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235467#p235467 <![CDATA[Re: Timery programowe, nierówna praca]]> SylwekK napisał(a):

przecięta na pół w losowych momentach...

W przykładzie z jednym przerwaniem i modyfikacją w pętli głównej kiedy ma nastąpić to "przecięcie na pół"?
Modyfikacja zmiennej następuje tylko w przerwaniu oraz w pętli głównej.

Jeśli mikrokontroler wchodzi w obsługę przerwania, to póki nie skończy obsługi - podziała na rejestrach - to nic mu nie przerwie działania na rejestrach.
"Atomowość" przerwania nie jest potrzebna, bo pętla główna nie jest wstanie zaburzyć/przerwać działania żadnego przerwania.
W AVR przerwanie może zostać jedynie "przecięte na pół" przez inne przerwanie, czyż nie?

No to może podczas modyfikacji zmiennej w pętli głównej?
Nie, bo przerwanie wykonuje się co milisekundy, a inkrementacja dwubajtowej w pętli głównej, wraz z sprawdzeniem warunku będzie trwała wielokrotnie dłużej.
Mamy zatem sekwencję:
1. Wejście w przerwanie
2. Obliczenia
3. Wyjście z przerwania

4. Wejście do pętli głównej

5. Co kilkanaście taktów zegara jest sprawdzany warunek - mikrosekundy najwyżej
Gdy tylko przerwanie zmieni wartość licznika na 0 - w tym przerwaniu PĘTLA nie zmieni rejestrów, to DOPIERO po wyjściu z przerwania pętla będzie mogła wpisać nową wartość.
PONIEWAŻ przerwanie nastąpi dopiero za kolejne milisekundy JEST DOŚĆ czasu na modyfikację dwóch jednobajtowych rejestrów.

6. Pętla sprawdza warunek (licznik == 0) wpisuje nową wartość w ciągu maks. kilku mikrosekund
7. Wielokrotnie sprawdzany jest warunek (licznik==0).
Były ms zanim po raz kolejny nastąpiło przerwanie, ale zmienna już została zmodyfikowana do wartości początkowej (licznik = 1000 /ms/ )

8. Wejście w przerwanie - po ms
9. Obliczenia
10. Wyjście z przerwania
itd

Mikrokontroler działa sekwencyjnie. Dopiero zagnieżdżanie przerwań wymusza w odp. momencie atomowość. Bo jedno jak i drugie przerwanie może zostać "przerwane", pokićkać wspólne rejestry.
Nie pojedyncze przerwanie i pętla główna.
No chyba, że coś pominąłem, ale co?
Jaki macie pomysł na wytłumaczenie? Nie zadowala mnie "bo ktoś powiedział', albo że "tak ma być", "atomowość rozwiązała problem" :)

Taki kod działa u mnie bezbłędnie nawet jeśli jest kilka liczników i kilka diod czy inne proste zmiany portów.
Greenbook'owe kody też działają, a mamy tam przecież dość skomplikowane projekty, a softtimery są wykorzystywane.

[syntax=c]#include <avr/io.h>
#include <AVR/interrupt.h>


#define PRESCALLER256
#define TIMER_OCR13

volatile uint16_t softTimer1;
void timer2_init(void);

int main( void ) {
timer2_init();

sei();

while (1) {
if( softTimer1 == 0 ) {
softTimer1 = 500;
PORTD ^= (1<<PD0);
}

}
}
ISR( TIMER2_COMPA_vect ) {
register uint16_t n;
n = softTimer1;
if (n) softTimer1 = --n;
}

void timer2_init(void) {
// Timer na 1ms, w zależności od zegara różne OCR
// Timer2 – konfiguracja silnika timerów programowych
TCCR2A = (1<<WGM21);// tryb pracy CTC dla ATmega8

if ( PRESCALLER == 1024 )
TCCR2B |= (1<<CS22)|(1<<CS21)|(1<<CS20);// preskaler = 1024
else
if ( PRESCALLER == 256 )
TCCR2B |= (1<<CS22)|(1<<CS21);// preskaler = 256
OCR2A = TIMER_OCR;

TIMSK2 |= (1<<OCIE2A);// Odblokowanie przerwania CompareMatch
}[/syntax]

Statystyki: Napisane przez Zealota — 4 maja 2022, o 19:00

]]> 2022-05-04T16:26:29+01:00 2022-05-04T16:26:29+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235466#p235466 <![CDATA[Re: Timery programowe, nierówna praca]]> Statystyki: Napisane przez SylwekK — 4 maja 2022, o 16:26

]]> 2022-05-04T12:08:01+01:00 2022-05-04T12:08:01+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235459#p235459 <![CDATA[Re: Timery programowe, nierówna praca]]> Rnext napisał(a):

Nie no, bez przesady Przecież sam możesz sprawdzić (lub ktokolwiek).

Sprawdziłem, masz rację - zwracam honor.
Na "usprawiedliwienie" :) mam to, że pomyliłem chyba Bluebooka z Greenbookiem.
Różnica polega na tym, że w późniejszych implementacjach Mirek w obsłudze timerów programowych, przy inkrementacji, używa specyfikatora "register", który prawdopodobnie daje odpowiednią ochronę kodu. Takiego rozwiązania użyłem w wielu projektach i nigdy nie było problemu z działaniem w odpowiednim czasie.
Sprawdź proszę, czy ta drobna zmiana spowoduje poprawne działanie.
[syntax=c]ISR(TIMER0_COMPA_vect) {
register uint16_t x; // Tutaj jest istotna zmiana

x = timer1;
if (x) timer1 = --x;

x = timer2;
if (x) timer2 = --x;
}[/syntax]

Statystyki: Napisane przez Zealota — 4 maja 2022, o 12:08

]]> 2022-05-04T11:12:46+01:00 2022-05-04T11:12:46+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235458#p235458 <![CDATA[Re: Timery programowe, nierówna praca]]> mtbchn napisał(a):

Możesz pokazać ciało swojej funkcji: hw_timer0_ctc_enable?


Jasne. Nic szczególnego w niej nie ma a jak pisałem, umieszczenie przełączania w obsłudze przerwania chodzi idealnie.
[syntax=c]typedef enum {
clk0_1, clk0_8, clk0_64, clk0_256, clk0_1024
} TSCALETIM0;[/syntax]

[syntax=c]void hw_timer0_ctc_enable(TSCALETIM0 prescaler, uint8_t cmp) {
TCCR0A |= (1 << WGM01);

switch (prescaler) {
case clk0_1:
TCCR0B |= (1 << CS00);
break;
case clk0_8:
TCCR0B |= (1 << CS01);
break;
case clk0_64:
TCCR0B |= (1 << CS00) | (1 << CS01);
break;
case clk0_256:
TCCR0B |= (1 << CS02);
break;
case clk0_1024:
TCCR0B |= (1 << CS00) | (1 << CS02);
break;
default:
TCCR0B |= (1 << CS00);
break;
}

OCR0A = cmp;
TIMSK0 = (1 << OCIE0A);
}[/syntax]

Statystyki: Napisane przez Rnext — 4 maja 2022, o 11:12

]]> 2022-05-03T17:49:32+01:00 2022-05-03T17:49:32+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235457#p235457 <![CDATA[Re: Timery programowe, nierówna praca]]> Rnext napisał(a):

Zealota napisał(a):
SylwekK napisał(a):
Więcej niż Ci się wydaje.

Nie w tym banalnym przykładzie. {...}
Natomiast na pewno autor źle przepisał kod z bluebooka i od poprawnego powinien był zacząć.


Nie no, bez przesady :) Przecież sam możesz sprawdzić (lub ktokolwiek). Przecież wkleiłem też ten pierwotny, przepisany kod. Tym bardziej że za wiele do przepisywania tu nie ma, zwłaszcza że na pierwszy rzut oka w kod z BB wiadomo o co w nim chodzi.

------------------------ [ Dodano po: 19 minutach ]

ord napisał(a):

Poczytaj sobie o współdzieleniu danych i atomowym dostępie.


Dzięki! Do głowy mi nie przyszło, żeby zerknąć w generowany ASM. Wstępnie zerknąłem w temat dostępu atomowego. Zdaje się tu jest pies pogrzebany.



Możesz pokazać ciało swojej funkcji: hw_timer0_ctc_enable?

Statystyki: Napisane przez mtbchn — 3 maja 2022, o 17:49

]]> 2022-05-03T16:09:22+01:00 2022-05-03T16:09:22+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235456#p235456 <![CDATA[Re: Timery programowe, nierówna praca]]> Zealota napisał(a):

SylwekK napisał(a):
Więcej niż Ci się wydaje.

Nie w tym banalnym przykładzie. {...}
Natomiast na pewno autor źle przepisał kod z bluebooka i od poprawnego powinien był zacząć.


Nie no, bez przesady :) Przecież sam możesz sprawdzić (lub ktokolwiek). Przecież wkleiłem też ten pierwotny, przepisany kod. Tym bardziej że za wiele do przepisywania tu nie ma, zwłaszcza że na pierwszy rzut oka w kod z BB wiadomo o co w nim chodzi.

------------------------ [ Dodano po: 19 minutach ]

ord napisał(a):

Poczytaj sobie o współdzieleniu danych i atomowym dostępie.


Dzięki! Do głowy mi nie przyszło, żeby zerknąć w generowany ASM. Wstępnie zerknąłem w temat dostępu atomowego. Zdaje się tu jest pies pogrzebany.

Statystyki: Napisane przez Rnext — 3 maja 2022, o 16:09

]]> 2022-05-02T17:53:49+01:00 2022-05-02T17:53:49+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235455#p235455 <![CDATA[Re: Timery programowe, nierówna praca]]> Statystyki: Napisane przez SylwekK — 2 maja 2022, o 17:53

]]> 2022-05-02T15:20:57+01:00 2022-05-02T15:20:57+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235454#p235454 <![CDATA[Re: Timery programowe, nierówna praca]]> SylwekK napisał(a):

Więcej niż Ci się wydaje.

Nie w tym banalnym przykładzie. Jest dość czasu na odczyt i zapis i "składanie" rejestrów. Nie ma innych przerwań, nie ma konfliktu dostępu do rejestrów mikrokontrolera
Natomiast na pewno autor źle przepisał kod z bluebooka i od poprawnego powinien był zacząć.

Statystyki: Napisane przez Zealota — 2 maja 2022, o 15:20

]]> 2022-05-02T13:56:13+01:00 2022-05-02T13:56:13+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235453#p235453 <![CDATA[Re: Timery programowe, nierówna praca]]> Quote:

Tylko co to ma do rzeczy w kontekście problemu?

Więcej niż Ci się wydaje. Przy przekazywaniu 16bitowych parametrów do przerwania dzieją się różne rzeczy. Doczytaj jak Cię o to proszą, wiedzą co mówią....

Statystyki: Napisane przez SylwekK — 2 maja 2022, o 13:56

]]> 2022-05-02T13:38:19+01:00 2022-05-02T13:38:19+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235452#p235452 <![CDATA[Re: Timery programowe, nierówna praca]]> ord napisał(a):

Poczytaj sobie o współdzieleniu danych i atomowym dostępie.

Tylko co to ma do rzeczy w kontekście problemu?
Przy miganiu diody czy też buzzera nie ma żadnego znaczenia czy ktoś się pomyli o "kilka taktów zegara"

Timery z bluebooka były wielokrotnie sprawdzane i używane do zadań jak w temacie i stawiam orzechy przeciwko kokosom, że autor coś pokikciał.

Jeśli ktoś się wykłada na timerach programowych to niech jeszcze się nie bierze za "atomowość".

Statystyki: Napisane przez Zealota — 2 maja 2022, o 13:38

]]> 2022-05-02T05:43:32+01:00 2022-05-02T05:43:32+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235448#p235448 <![CDATA[Re: Timery programowe, nierówna praca]]> mirekk36 napisał(a):

Rnext napisał(a):
to "niemal" to u ciebie całkiem inaczej i źle - stąd twoje problemy. Gdybyś jednak spróbował jak w Bluebooku to mógłbyś działać DOKŁADNIE

Sam bardzo chętnie pozbył bym się flag. Pierwotnie zrobiłem DOKŁADNIE jak w BB i też działało nierówno. Stąd kolejne kombinacje w kodzie.

Tak wyglądała przepisana żywcem pętla główna:
[syntax=c]int main() {
LED_DDR |= (1 << LED_PIN);
BUZZER_DDR |= (1 << BUZZER_PIN);
hw_timer0_ctc_enable(clk0_64, 249);
sei();

while (1) {
if (!timer2) {
LED_TOGGLE;
timer2 = 300;
}

if (!timer1) {
BUZZER_TOGGLE;
timer1 = 1000;
}
}
}[/syntax]
A tak przepisałem obsługa przerwania:
[syntax=c]ISR(TIMER0_COMPA_vect) {
uint16_t x;

x = timer1;
if (x)
timer1 = --x;

x = timer2;
if (x)
timer2 = --x;
}[/syntax]

Po samej LED pewnie bym się nie zorientował, bo na oko mrugała jak powinna, ale głośniczek daje możliwość łatwego wyłapania skoków "taktu".

Statystyki: Napisane przez Rnext — 2 maja 2022, o 05:43

]]> 2022-05-01T17:20:51+01:00 2022-05-01T17:20:51+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235446#p235446 <![CDATA[Re: Timery programowe, nierówna praca]]> Rnext napisał(a):

No i super - z flagą pomocniczą wszystko działa perfect. Dzięki!

To jest bardzo zły sposób na realizację timerów programowych

poza tym pisałeś:
Rnext napisał(a):

Adaptacja niemal żywcem z bluebooka.


to "niemal" to u ciebie całkiem inaczej i źle - stąd twoje problemy. Gdybyś jednak spróbował jak w Bluebooku to mógłbyś działać DOKŁADNIE i tak samo wygodnie jak w Bluebooku i to bez żadnych dodatkowych flag - bo te dodatkowe flagi twoje to po prostu będą tylko zawalizdrogą przy bardziej rozbudowanych programach.

Statystyki: Napisane przez mirekk36 — 1 maja 2022, o 17:20

]]> 2022-05-01T08:32:17+01:00 2022-05-01T08:32:17+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235445#p235445 <![CDATA[Re: Timery programowe, nierówna praca]]> JarekB napisał(a):

Czy timer_1000ms i timer_300ms są volatile ?
To po pierwsze

Tak, tak, naturalnie.

JarekB napisał(a):

Po drugie badanie w pętli głównej czy zmienna w przerwaniu osiąga 0 jest ryzykowne.
W czasie wykonania przerwania może się zdarzyć że zero stanie się jedynką i pętla główna nie zdąży zareagować
Gdybyś w przerwaniu postawił jakąś flagę i w pętli głównej ją zerował to wtedy miałbyś pewność że zawsze zdążysz.

Adaptacja niemal żywcem z bluebooka. Ale racja, dodam flagę.

------------------------ [ Dodano po: 7 minutach ]

No i super - z flagą pomocniczą wszystko działa perfect. Dzięki!

Statystyki: Napisane przez Rnext — 1 maja 2022, o 08:32

]]> 2022-05-01T08:25:24+01:00 2022-05-01T08:25:24+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235444#p235444 <![CDATA[Re: Timery programowe, nierówna praca]]> To po pierwsze
Po drugie badanie w pętli głównej czy zmienna w przerwaniu osiąga 0 jest ryzykowne.
W czasie wykonania przerwania może się zdarzyć że zero stanie się jedynką i pętla główna nie zdąży zareagować
Gdybyś w przerwaniu postawił jakąś flagę i w pętli głównej ją zerował to wtedy miałbyś pewność że zawsze zdążysz.

Statystyki: Napisane przez JarekB — 1 maja 2022, o 08:25

]]> 2022-05-01T08:01:23+01:00 2022-05-01T08:01:23+01:00 https://forum.atnel.pl/viewtopic.php?t=24214&p=235443#p235443 <![CDATA[Timery programowe, nierówna praca]]> Zredukowałem do testów kod do chyba najprostszej możliwej formy. Przerwanie CTC ustawione co 1000ms.

[syntax=c]int main() {
LED_DDR |= (1 << LED_PIN);
BUZZER_DDR |= (1 << BUZZER_PIN);
hw_timer0_ctc_enable(clk0_64, 249);
sei();

while (1) {
if (!timer_300ms) {
LED_TOGGLE;
}

if (!timer_1000ms) {
BUZZER_TOGGLE;
}
}
}

//-------------------------------
ISR(TIMER0_COMPA_vect) {
timer_300ms++;
timer_1000ms++;

if (timer_1000ms >= 1000)
timer_1000ms = 0;

if (timer_300ms >= 300)
timer_300ms = 0;

}[/syntax]

...i głośniczek kołacze jak chce, led mruga jak chce ale na pewno nie są to zadane interwały.
Jak umieszczę zmianę stanów w kodzie przerwania to wszystko jest jak najbardziej OK.

Czegoś tu nie widzę?

Statystyki: Napisane przez Rnext — 1 maja 2022, o 08:01

]]>