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 !!!!!!
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
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
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
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:
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 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
no i może zanim coś powiem to rzućcie okiem na widok z analizatora:
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
język c
Musisz się zalogować, aby zobaczyć kod źródłowy. Tylko zalogowani użytkownicy mogą widzieć kod.
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
Kanał - ATNEL tech-forum
Zaloguj
Zarejestruj
Informacje o cookies
FAQ
Szukaj
