Różnice w zachowaniu zmiennych globalnych w AVR-GCC: extern vs static w przerwaniach

Fri Jul 01, 2005 7:36 pm   

Witam!

Okazało się ze to nie był problem z wywoływaniem funckji z przerwań. To
chyba co innego. Z nieznanych mi przyczyn jest istotna róznica jeśli:

a) Mam program w modułach
b) definiuje zmienną globalną w jednym z modułów w postaci:

extern long zmienna (to w pliku .h)
long zmienna (to w jednym z plików .c)

c) modyfikuje ją w przerwaniu

To w takiej konfiguracji zmiana "zmiennej" powoduje wesołe zawieszenie
się reszty programu/błedne działanie.

jednak wystarczy zdeklarować:

static long zminna

A program się stabilizuje i działa poprawnie.

W kodzie wygląda to tak, że bez static allokowane jest to w innym
obszarze niż ze static. Konkretnie static allokuje wyższe komórki (rzędu
0xd0) a ze static okolice 0x60.

Wygląda mi to dość dziwnie, tak jak gdyby nie dało się deklarować
widocznych pomiedzy modułami zmiennych. Nie potrafie wyłapać dokladnych
warunków, kiedy to zachodzi, ponieważ w róznych kombinacjach wielkości
programu raz działa a raz nie działa (bez static). Ze static działa
zawsze poprawnie.

Ktoś ma jakiś pomysł co robie źle ?

--
Sebastian Bialy - heby@poczta.onet.pl

Sat Jul 02, 2005 10:34 am   

Dnia Fri, 01 Jul 2005 22:36:29 +0200, Sebastian Bialy
<heby@poczta.onet.pl> napisał:



tak to nazwac. Przeciez kompilator powinien ja zrobic dopiero w miejscu
wlaczenia do pliku .c


moze definicje w .h warunkowa i ustawiaj odpowiedni warunek.


--
Jaroslaw "Jaros" Berezowski

Sat Jul 02, 2005 12:15 pm   

On Fri, 01 Jul 2005 22:36:29 +0200, Sebastian Bialy wrote:

Ciagle nie widzie volatile :-)


Dziwne rzeczy piszesz. Jesli zmienna jest zadeklarowana poza funkcja,
to "static" znaczy de facto "nie publiczna".
Jako taka nie moze byc dostepna z innych modulow !

Kompilatora raczej nie podejrzewam .. albo uzywasz dwoch zmiennych w
roznych modulach, albo masz konflikt nazw z biblioteka ..


POdeslij caly program.

J.

Sat Jul 02, 2005 1:51 pm   

J.F. wrote:

Fakt, zapomniałem dopisać, ale jest oczywiście.


W moim przypadku nie sięgam do niej z innych modułów (chwilowo) żeby
wykluczyc jakies problemy między-modułowe. Jest deklarowana jako static
i extern i korzysta z niej jeden i tem sam moduł. W jednym wypadku jest
dobrze, w drugim dzieją się cuda.


Eeee Nie da rady, ale postaram się ten problem wywołać dla
rzeczywistego kodu. na razie jedyny objaw to inna lokalizacja zmienne jw
pamięci dla extern i static, natomiast w bardzo mayłym programie który
korzysta z tego mechanizmu jest ok.

Będe dalej waczył.

--
Sebastian Bialy - heby@poczta.onet.pl

Sat Jul 02, 2005 11:34 pm   

On Sat, 02 Jul 2005 16:51:30 +0200, Sebastian Bialy wrote:

Maly test - skasuj static, ale zmien jej nazwe ..


Skasuj niepotrzebne czesci programu, ale zostaw zmienne - moze to
pomoze odtworzyc blad.

J.

Sun Jul 03, 2005 6:48 am   

Sebastian Bialy wrote:

Już wiem, aczkolwiek jestem bardzo zdziwiony ...

Oczywiscie jestem temu winien. Mój program składa się z 5 modułów.
Przypadkowo (zapewne efekt pisania nocami) w jednym z plików .c
zapomniałem doinkludować charakterystyczme pliki do AVR. Ponieważ nie
było w nim żadnych zaleznych sprzetowo elementów poza SIGNAL i
matematyce na zmiennych to nie wrzeszczał o ich brak (swoją drogą bradzo
dziwne, czyżby SIGNAL był wbudowany w avr-gcc ?).

Efekt: W tym jednym mudule zmienna lądowała w innym obszarze pamięci. Po
dodaniu #include zmienna poleciała tam gdzie wszystkie.

Oczywiście wie ponosze ja, za nieuwagę, ale bardzo dzinym dla mnie
zjawiskiem jaest fakt, że w ogóle kod się skompilował bez błędów.

Pisze to ku przestrodze, gdyby komus robily się również takie numery z
lokalizacją zmiennych ...

--
Sebastian Bialy - heby@poczta.onet.pl

Sun Jul 03, 2005 9:36 am   

Sebastian Bialy napisał(a):

to wygląda tak, jakbyś sobie tą zmienną zadeklarował mimo wszystko w tym
pliku. gdybyś nie miał wcześniej żadnej deklaracji, kompilator powinien
się wywalić.

swoją drogą, dodajesz -Wall do flag kompilatora? dzięki dużej ilości
ostrzeżeń łatwo wykryć potencjalne błędy.

w.

Sun Jul 03, 2005 9:42 am   

On Sun, 03 Jul 2005 09:48:58 +0200, Sebastian Bialy wrote:

Dziwne to co piszesz.
Jesli zapomiales inlude ze zmienna, to powinno wywalic wielki blad
ze zmienna niezdefiniowana. No chyba ze byla zdefiniowana w dwoch
miejscach.

Natomiast SIGNAL .. bez include to jest po prostu zwykla funkcja
o takiej nazwie, ktora kompiluje sie swietnie, ale wywolywana
nigdy nie jest. Na assemblerze powinno cie zaciekawic:
-czemu nie konczy sie reti,
-czemu nie przechowuje uzywaneych rejestrow,
-czemu wektorek na nia nie wskazuje.

J.

Sun Jul 03, 2005 12:46 pm   

Sebastian Bialy wrote:


Podziękuj Kernighanowi i Ritchiemu. :-)

Jeszcze lepszą zabawę będziesz miał, gdy uda Ci się wywołać
konflikt nazwy Twojej funkcji z jedną z funkcji bibliotecznych
-- linker bez ostrzeżeia wybierze Twoją wersję, mimo, że inne
fragmenty biblioteki moga chcieć się odwoływać do prawidłowej
wersji. No cóż, jaki jest C każdy widzi...

Pozdrawiam
Piotr Wyderski

Sun Jul 03, 2005 3:37 pm   

Wojtek Kaniewski wrote:

nie chodzi o mój plik .h tylko w ogóle o zestaw plików .h:

avr/interrupt.h
avr.signal.h
arv/io.h
....


Dodaje ale wtedy, kiedy kod kompiluje mi się bez błędów, a w trakcie
pisania programu na wczesnym etapie jest cała masa błędów typu "nieużyte
i" albo "nigdy tego nie wywołasz" i tym podobnym. Więc wyłączyłem Ale
masz rację, Wall mogło podpowiedziec co jest nie tak.

--
Sebastian Bialy - heby@poczta.onet.pl

Sun Jul 03, 2005 3:41 pm   

J.F. wrote:

Wyjasniłem jakie pliki h mi brakowało w sąsiednim poście.


Alez kończy, wcześniej tez kończyło się.


No własnie przechowywało wszystkie.

Moje zdumienie miało związek z faktem magicznego przenoszenia się
zmiennej z 0x6x do 0xdx w zalezności od uzycia "static". Widocznie z
jakiś powodów nie dołaczenie własciwych plików .h (moja wina) powoduje,
że linker/kompilator allokuje zmienną w innym obszarze.

Teraz wszystko jest ok, i nie ma żadnych problemów.

--
Sebastian Bialy - heby@poczta.onet.pl

Sun Jul 03, 2005 3:47 pm   

Piotr Wyderski wrote:

No niestety, tego typu "czeskie błędy" cały czas są moją zmorą. Ale C
znam od 10 lat i na razie mimo jego upierdliwości nie zamienie go na nic
innego, jeśli mam grzebac blisko sprzetu (a jak daleko, to C++).


A to akurat jest bardzo ok i w zasadzie zgodne ze zdrowym rozsądkiem jak
dla mnie. Moim zdaniem pisanie programów w C jest swego rodzaju
pozytywnym wyzwaniem szczególnie w czasach Delphi/VB i wszelkiej maści
..NET ów, gdzie myślenie i znajomośc bebechów jest wysoce niewskazane.

--
Sebastian Bialy - heby@poczta.onet.pl

Sun Jul 03, 2005 4:55 pm   

Sebastian Bialy wrote:


A to mnie zaciekawiło: dlaczego C++ stosujesz pisząc bardziej
wysokopoziomowo, a C na niższym poziomie? Przecież wszystko,
co można zrealizować w C przenosi się do C++ praktycznie bez
modyfikacji, a w C++ dostajesz kilka bardzo silnych mechanizmów,
m.in. szablony. Pokazałem Ci kilka dni temu w jaki sposób Twój
nierozwiązywalny problem w C rozwiązać w kilku linijkach w C++,
i to bez generowania jakiegokolwiek kodu i zajmowania pamięci.


Nie jest bardzo OK, bo może stać się przyczyną powstania bardzo
trudnych do wykrycia błędów. W C++ można się przed tym zabezpieczyć
za pomocą przestrzeni nazw


Pisanie programów w czymkolwiek nie jest żadnym wyzwaniem,
to rzemiosło. Wyzwaniem jest zaprojektowanie programu, ale
to się robi w oderwaniu od języka programowania.


To jakieś zabobony... Języki trzymające się daleko od poziomu
maszyny są równie potrzebne, jak te, które ujawniają niskopoziomową
strukturę sprzętu -- każdy z nich ma swój obszar stosowalności.

Pozdrawiam
Piotr Wyderski

Sun Jul 03, 2005 5:33 pm   

Piotr Wyderski wrote:

Nie zrozum mnie źle, ale pisanie w kompilatorze C++ nie używając klas
dalej uważam za pisanie w C. To że dostaje do rąk pare fajnych narzedzi
(szablony na ten przykład jak sam wspomniałeś) jeszcze nie czyni ze mnie
programisty C++ w tym przypadku. W zasadzie dla mnie pisanie w C++ to
używanie klas/szblonów/STL. To się średnio nadaje do mikrokontrolerów
8-bitowych na razie. Tak więc po prostu inaczej definiuje "pisanie w C++"


Owszem, ale kiedyś pisałem bardzo dużo w assemblerze i swoboda grzebania
po RAM była dla mnie bardzo ważną cechą. Kiedy przesiadłem się na C
jęczałem na widok "niepotrzebnych" konwersji zmiennych, etc. Teraz kiedy
przyszło mi nabazgrac plikację w Javie szlag mnie trafia na brak
destrukorów, które są dla mnie ważne w C++. Każdy nastepny język
ogranicza troche swobode (i dobrze, ogranicza to też błędy związane z
prostymi pomyłkami) i coraz bardziej wymusza stosowanie
czasochłonnych/pamięciochłonnych/zasobożernych rozwiązań, zamiast
prostej podmiany funkcji bibliotecznej w C. Akurat tego nie stosuje
powszechnie (2 razy w życiu acz zakładam, że są sytuację, kiedy się
przydaje. Co nie znaczy że jestem przeciwnikiem języków myślących za
programistów, ale po prostu jestem "wychowany" na asm Z80/6502/680x0/x86
i mam jakieś zboczenie w tym kierunku.

Cenie sobie C własnie dlatego że MOGĘ to zrobic. A to że czasami jest to
źródłem błędu - no cóż, przy okazji jego rozwiązania uczę się. Inna
sprawa, że przeciętny biznesmen powiedziałby, że trace czas na pierdoły.
Więc zalezy to od punktu widzenia.


Hmmm, mam inne zdanie, a wyprowadzam je z mojej obserwacji wielu osób
piszących programy. Przeciętny programista BASCOMa nie musi wiedziec nic
na temat komunikacji układu X z Y - i to jest rzemiosło. Programista C w
tej samej sytuacji zazwyczaj musi dośc dokładnie poznać dokuentację
obydwu - i to jest wyzwanie. Pisanie w C/ASM w przypadku
mikrokontrolerów to jedna większe wyzwanie niż w BASCOMie/etc.

Może BASCOM to zły przykład, ale w ogólnym przypadku pisanie w C wymaga
od programisty znacznie więcej niż znajomosci paru funkcji wbudowanych w
język. Z resztą nie trzeba daleko szukac, bo w wielu firmach pracują
"programisci" pisząc przez pare lat programy skłądające się z kawałków
truwialnego kodu w delphi przelatanych SQLem (w dodatku takich samych).
To jest dopiero nuda i rzemiosło.

--
Sebastian Bialy - heby@poczta.onet.pl

Sun Jul 03, 2005 5:49 pm   

Piotr Wyderski napisał(a):

szkoda, że tak późno zauważyłem tamten wątek, to bym napisał, że można
po prostu zrobić tak:

unsigned long x;

if (sizeof(x) == sizeof(unsigned long)) {
// foo
}

if (sizeof(x) == sizeof(unsigned short)) {
// bar
}

gcc nawet bez -O już w trakcie kompilacji rozwinie sizeof() i usunie
martwy kod warunkowy. fakt, to nie jest dokładne sprawdzanie typu (nie
odróżni char[2] i short od unsigned short), ale w większości przypadków
wystarczy.

w.