Użytkownik T.M.F. napisał:
> Skad masz makra sei() i cli()? To twoja wlasna definicja czy z
> biblioteki avr-glibc - pliku interrupts.h?
> Zakladam, ze twoja wlasna, stad problemy. Oryginalna prawidlowa
> definicja wyglada tak:
> #define sei() __asm__ __volatile__ ("sei" ::)

Niestety oryginalne z interrupt.h i są one tam zdefiniowane dokładnie
tak jak Kolega napisał.

> Zwroc uwage na slowo volatile. Swoja droga przeczytaj jak volatile
> dziala to rozwiaze sie wiele twoich dziwnych klopotow.

W dużym uproszczeniu ogranicza kompilatorowi możliwości optymalizacji. W
stosunku do zmiennej wymusza bezwarunkowe każdorazowe czytanie aktualnej
wartości zmiennej z pamięci przed wykonaniem jakichkolwiek operacji na
zmiennej. Czyli kompilatorowi nie wolno dla uproszczenia/przyśpieszenia
kodu banglać przez cała procedurę na wartości skopiowanej do rejestrów.
Inaczej mówiąc zmienna ma być tak traktowana jakby jej zawartość mogła
się w każdej chwili zmienić (np. przez inny wątek programu). W
kontekście powyższego (chyba, że jest jednak inna definicja volatile)
nadal nie mogę zrozumieć z jakiej paki rozkaz sei() umieszczony na końcu
funkcji znalazł się nagle na jej początku.


Pozdrawiam
Grzegorz

do góry

Użytkownik Zbych napisał:
> Powinieneś użyć jej wszędzie tam gdzie do tej pory miałeś
>
> cli();
> [...]
> sei();

No to teraz już wiem :-) Dzięki za cenną wskazówkę.

Pozdrawiam
Grzegorz

do góry

On Sat, 13 Jun 2009 12:31:18 +0200, Grzegorz Kurczyk wrote:
>> Zwroc uwage na slowo volatile. Swoja droga przeczytaj jak volatile
>> dziala to rozwiaze sie wiele twoich dziwnych klopotow.
>
>W dużym uproszczeniu ogranicza kompilatorowi możliwości optymalizacji. W
>stosunku do zmiennej wymusza bezwarunkowe każdorazowe czytanie aktualnej
>wartości zmiennej z pamięci przed wykonaniem jakichkolwiek operacji na
>zmiennej. Czyli kompilatorowi nie wolno dla uproszczenia/przyśpieszenia
>kodu banglać przez cała procedurę na wartości skopiowanej do rejestrów.
>Inaczej mówiąc zmienna ma być tak traktowana jakby jej zawartość mogła
>się w każdej chwili zmienić (np. przez inny wątek programu). W
>kontekście powyższego (chyba, że jest jednak inna definicja volatile)
>nadal nie mogę zrozumieć z jakiej paki rozkaz sei() umieszczony na końcu
>funkcji znalazł się nagle na jej początku.

Nie - to rozkaz = ze srodka funkcji znalazl sie na jej koncu :-)

J.

do góry

Użytkownik J.F. napisał:
>
> Nie - to rozkaz = ze srodka funkcji znalazl sie na jej koncu :-)
>

No fakt :-) Można to też w taki sposób zinterpretować :-)
Co oczywiście nie rozwiązuje kwestii "z jakiej paki".

Pozdrawiam
Grzegorz

do góry

On Sat, 13 Jun 2009 13:01:50 +0200, Grzegorz Kurczyk wrote:
>Użytkownik J.F. napisał:
>> Nie - to rozkaz = ze srodka funkcji znalazl sie na jej koncu :-)
>>
>No fakt :-) Można to też w taki sposób zinterpretować :-)
>Co oczywiście nie rozwiązuje kwestii "z jakiej paki".

Jest potrzebny na koncu [do zwrocenia wartosci], to przerzucaja na
koniec .. po co ma wczesniej rejestry zajmowac ?


J.

do góry

Użytkownik J.F. napisał:
> Jest potrzebny na koncu [do zwrocenia wartosci], to przerzucaja na
> koniec .. po co ma wczesniej rejestry zajmowac ?

To dlaczego w przytoczonej funkcji SetEncoder też tak nie zrobił ? Tam
wszystko jest w takiej kolejności jak w źródłówce - sei jest na końcu,
choć z "matematycznego" punktu widzenia sei nie ma wpływu na wartość
obliczeń i może se być wrzuconym gdziekolwiek ;-)

Ufff... kończmy tę dyskusję, bo się mały flejmik robi :-)
Kolega Zbych podał konkretne i skuteczne rozwiązanie problemu, choć
nadal nie mogę zrozumieć czemu akurat tak się dzieje ? Cóż trzeba
przyjąć to na "wiarę", że tak ma być i koniec ;-)

Jeszcze raz dziękuję Kolegom za udział w dyskusji.
Pozdrawiam
Grzegorz

do góry

Użytkownik T.M.F. napisał:
> Co
> wiecej gdybys dalej cops robil z ta zmienna w swojej procedurze to
> kompilator jej pewnie ponownie by nie ladowal, czyli mialbys kolejne
> dziwne bledy.

Błędów by nie było pod warunkiem, że sei wylądowałoby na końcu tam gdzie
je napisałem. W sekcji między cli, a sei program staje się jednowątkowy
i nie ma powodu dla którego wartość tej zmiennej mogłby ulec zmianie,
ale fakt... Samo volatile też nie załatwiłoby sprawy. Musi być połaczone
z sekcją cli/sei.

> Ale to ciagle twoja wina i nie ma co zwalac na gcc.

Ale ja nigdzie nie twierdzę, że to nie moja wina :-) Pewnie, że moja.
Wystarczyło dopisać volatile lub zastosować sekcję ATOMIC_BLOCK i jest
ok. Poprostu kiedyś tam zasugerowałem się tym, że przecież volatile
stosuje się po to aby wymusić każdorazowe czytanie zmiennej z pamięci, a
moim celem było uniemożliwienie aby cokolwiek innego zmieniło wartość
tej zmiennej na czas wykonywania wnętrza funkcji. A zmienna w tej
funkcji czytana jest w sumie tylko raz. Takie małe odwrócenie problemu
:-) I co gorsza/lepsza w starszych wersjach WinAVR kompilowało się to
"po ludzku", co uśpiło moją czujność ;-)

Jeszcze raz dziękuję Kolegom za cenne wskazówki.

Pozdrawiam
Grzegorz

do góry

On Sat, 13 Jun 2009 13:37:15 +0200, Grzegorz Kurczyk wrote:
>Użytkownik J.F. napisał:
>> Jest potrzebny na koncu [do zwrocenia wartosci], to przerzucaja na
>> koniec .. po co ma wczesniej rejestry zajmowac ?
>
>To dlaczego w przytoczonej funkcji SetEncoder też tak nie zrobił ?

No bo tam nie bylo takiej potrzeby :-)

Jak sam zreszta zauwazyles - dodanie volatile zaowocowalo dluzszym
kodem. No to slusznie bez volatile zoptymalizowal do krotszego :-)

Inna sprawa ze ta kompilacja dziwna jakas i wcale niepotrzebnie
dluzsza.

>Ufff... kończmy tę dyskusję, bo się mały flejmik robi :-)
>Kolega Zbych podał konkretne i skuteczne rozwiązanie problemu, choć
>nadal nie mogę zrozumieć czemu akurat tak się dzieje ? Cóż trzeba
>przyjąć to na "wiarę", że tak ma być i koniec ;-)

No coz - moral z tego taki ze czasem warto w kod wynikowy zajrzec.
Czlowiek sie czegos moze dowiedziec.

Inna sprawa ze w tym miejscu to volatile powinienes z przyzwyczajenia
pisac :-)

J.

do góry

W dniu 13.06.2009 02:43, Grzegorz Kurczyk pisze:
> A teraz coś czego już zupełnie nie rozumiem:
>
> int *pEncoderValue; // celowo bez volatile
>
> int GetEncoder(void) {
> cli();
> int e = *pEncoderValue;
> sei();
> return e;
> }
>
> void SetEncoderValue(int Value) {
> cli();
> *pEncoderValue = Value;
> sei();
> }
>
> kompiluje się na:
>

Skad masz makra sei() i cli()? To twoja wlasna definicja czy z
biblioteki avr-glibc - pliku interrupts.h?
Zakladam, ze twoja wlasna, stad problemy. Oryginalna prawidlowa
definicja wyglada tak:
#define sei() __asm__ __volatile__ ("sei" ::)

Zwroc uwage na slowo volatile. Swoja droga przeczytaj jak volatile
dziala to rozwiaze sie wiele twoich dziwnych klopotow.


--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.

do góry

>> (właśnie aby tego uniknąć blokowałem
>> przerwania). Idąc tym tropem kompilator mógłby "dojść do wniosku", że
>> sekwencję:
>> sbi(PORTB, 1);
>> sbi(PORTB, 2);
>> sbi(PORTB, 3);
>> można zamienić na:
>> sbi(PORTB, 3);
>> sbi(PORTB, 2);
>> sbi(PORTB, 1);
>
> Tak to nie, bo to jednak i operacja specjalna i taka "wyjsciowa",
> ale juz kolejnosc odczytow z portow moglby przestawic.

Zadna to operacja specjalna, po prostu PORTB zdefiniowany jest jako
volatile, co implikuje, ze kompilator nie robi dziwnych przetasowan, bo
wie, ze mu nie wolno.

--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.

do góry