Błąd czasowy w pętli z volatile unsigned int Time_out w przerwaniu 25ms

Witam serdecznie.

Mam następujący fragment programu który powtarza sie u mnie w programie dość często:



zmienna Time_out jest typu volatile unsigned int.
Zmienna ta jest inkrementowana w przerwaniu od przepełnienia licznika . Przepełnienie następuje co około 25ms.

Wiem że w tej konstrukcji jest błąd atomowości.
Dlatego pytanie moje brzmi - jaki największy błąd czasowy może mi się pojawić jeśli zastosuje np taki warunek:



powinna ta procedura być wykonywana przez 25sekund, a jaka najgorsza sytuacja może tu wystąpić, ile wtedy będzie wynosił ten czas?

pozdrawiam

O jeden okres zliczania licznika 25ms przy takim właśnie warunku z liczba większą od 255.

A nie o 255 * 25ms?

Jeśli załóżmy zmienna Time_out ma wartość 255 i w tym momencie następuje porównanie dolnego rejestru zmiennej , w miedzy czasie wyskakuje przerwanie i zwieksza sie górny rejestr , to procesor odczyta zamiast prawidłowej wartości 256 wartość dwa razy większą czyli 255+256. A więc maksymalny błąd może być aż 255.

Czy dobrze myśle?

Trzeba sprawdzić w listingu czy kompilator na czas tego porównania nie wyłącza przerwań (a prawie na pewno tego nie robi) to rzeczywiście może dojść do takiej sytuacji.Ewentualnie sam możesz wyłączyć przerwania na ten moment.

excray napisał:

.Ewentualnie sam możesz wyłączyć przerwania na ten moment.

nie może wyłączyć przerwań bo ta funkcja nigdy się wtedy nie zakończy.

Wystarczy nieco zmieinć pętlę i problem z atomowością zniknie, ale to autor zapewne wie. Ale może inaczej ten problem rozwiązać - skoro procesor i tak nic nie robi (chyba, że jeszcze jakieś przerwania wykorzystujesz) to może prościej go usypiać i tak przeskalować timer, żeby generował przerwanie go wybudzające? Skróci to kod i dodatkowo zmniejszy zapotrzebowanie na energię.

A czy może mi Kolega TMF coś podpowiedzieć jak to zrobić?
Wiem że mógłbym w procedurze obsługi przerwania dodać ifa który sprawdzi warunek i ustawi jakąś flagę. Ale to obciąży tą procedurę przerwania , a boję się że jest już i tak zbyt "ciężka".
Jeśli chodzi o usypianie to nie jest to możliwe, bo tą procedurę chciałbym wykorzystać w różnych częściach programu, np w oczekiwaniu na znak z RSa.

I wszystko na ten temat....

Wielkie "pomógł" Panie kolego TMF.

tmf napisał:

Kod: C / C++

Zaloguj się, aby zobaczyć kod

Twoja wersja wyłącza przerwania ale ich już nie włącza po skopiowaniu Time_out do x.
A nie powinno przypadkiem być:

co praktyce jest to to samo co:

excray napisał:

Twoja wersja wyłącza przerwania ale ich już nie włącza po skopiowaniu Time_out do x.

Na jakiej podstawie tak twierdzisz?

Widzę w debuggerze:
ATOMIC_BLOCK(ATOMIC_RESTORESTATE):


ATOMIC_BLOCK(ATOMIC_FORCEON):

Proponuję okulary, lub przypatrzeć się uważniej.
Mała podpowiedź - nie tylko cli i sei zmieniają flagę zezwolenia na przerwanie.

TMF ma rację - w tym listingu masz kopiowany cały rejestr SREG .Na koniec jest ponownie ustawiony na wartość początkową.
Zastanawia mnie coś innego, czemu kompilatory mają problemy z atomowością zerowania zmiennej.
Przecież polecenie x =0 , gdzie x jest zmienną typu INT,aż się prosi aby zawsze zerować od najmłodszej części, jeśli tak by było zawsze to nie byłoby z tym problemu. Czy dobrze myśle?

Też byłby problem, wyobraź sobie, że x zawiera 0xFFFF i chcesz go wyzerować. Zerując od najmłodszego bajtu przejściowo masz 0xFF00, od najstarszego 0x00FF, jeśli w trakcie zapisu jednego bajtu wystąpi przerwanie to tak czy siak x będzie miało nieprawidłową wartość. Co prawda niby inkrementacja w przerwaniu będzie działać poprawnie, wrócisz z przerwania z x równym 0xFF01, czyli po skończonej procedurze będzie 0x0001, ale już np. dekrementacja skończy się z błędnym wynikiem 0x00FE. A ciągle mówimy tylko o trywialnych przykładach, co z bardziej skomplikowanymi?
A kompilatory mają problem (konkretnie kompilator C ma problem) bo ten język nie zna czegoś takiego jak przerwania, czy wielowątkowość. C nie zawiera absolutnie żadnych rozszerzeń w tym kierunku, wszystko co jest jest doraźną próbą załatania tej dziury. Dlatego też np. obsługa przerwań na różnych procesorach, a nawet na tym samym ale dla różnych kompilatorów jest zupełnie inna.