Znikająca zmienna globalna w programie na ATmega128 przy obsłudze przerwań

Tue Oct 13, 2009 1:37 pm   

Piszę program na ATmega128 za pomocą edytora AVRSide i kompilatora WinAVR.
Program jest juz trochę rozbudowany i zawiły. Jest obsługa przerwań
czasowych co mniej więcej 1ms i używane jest sporo zmiennych globalnych.
Program obrabia równolegle dwa sygnały A i B z przetwornika A/C.
Jeśli sygnał A lub B spełni pewien warunek badany w przerwaniu, w pętli
głównej wchodzi w odpowiadającą swojemu kanałowi jedną z dwóch bliźniaczych
procedur (dość zawiłych).
Jedna ze zmiennych ustawiana jest w menu (wyświetlacz LCD i klawiatura
multipleksowana) i przyjmuje wartości 1 lub 0.

Dziwne zjawisko występuje, kiedy program wejdzie w wykonywanie procedury
tylko dla kanału B. W trakcie jej wykonywania powoduje samoistne wyzerowanie
wspomnianej wcześniej zmiennej. Zmienna ta nie występuje w ogóle w tej
procedurze. W całym programie jej wartość może być zmieniana ręcznie tylko w
pewnym menu które trzeba specjalnie wywołać sekwencją działań.
Podejrzewałem że może jest za mało pamięci RAM (zajętość 83%) i coś zaczyna
głupieć. Testowo wywaliłem pewne tabele zajmujące sporo RAM-u i uzyskałem
52% zajętości. Zjawisko się nie zmieniło. Sprawdziłem użycie tablic i
nigdzie nie jest przekroczony ich rozmiar.

Zmienna nie jest używana w przerwaniach, ale dla próby dałem ją jako
volatile - bez poprawy.
Szukanie dokładnie miejsca w procedurze w którym następuje zmiana wartości
tej zmiennej, to żmudna czasochłonna praca. Procedura jest duża i
pokiełbaszona z wieloma rozgałęzieniami typu case. Przydałaby się jakaś
wskazówka do szukania winnego.

Co może powodować ingerencję w wartość zmiennej przez procedurę, w której ta
zmienna nie występuje?

Tue Oct 13, 2009 2:14 pm   

On 2009-10-13 14:37:54 +0200, "Darkac" <darkac2@wp.pl> said:


stos?

--
DJ

PS. przy odpisywaniu na priv usun antyspamowy wpis z adresu

Tue Oct 13, 2009 2:43 pm   

Użytkownik "DJ" <johnny12-WYTNIJTO-@poczta.onet.pl> napisał w wiadomości
news:hb1uet$fia$7@news.dialog.net.pl...

Tak podejrzewałem, ale redukcja zmiennych z 83% zajętości RAM do 52% nie
zmieniła nic w tym względzie. Ile może zajmować taki stos? ATmega128 ma 4
KB RAM-u. Polowa pamięci na stos ? Trochę nieprawdopodobne.
Kilka wersji programu wcześniej, nie było tego złego zjawiska, a zajętość
RAM-u była ponad 80%. Było sporo drobnych zmian, które nie powinny były
znacząco wpływać na rozmiar stosu. Ale śledzenie tych zmian to też
partaninka.

Tue Oct 13, 2009 4:23 pm   

Użytkownik "Darkac" <darkac2@wp.pl> napisał w wiadomości
news:hb206d$t7q$1@news.lublin.pl...

Stos moze zajmowac dowolnie duzo No nie, sa procki gdzie jest
maly, ale jesli jest rekurencja, zagniezdzone przerwania i inne
niespodzianki, to moze rosnac.
Ale jakby stos zajezdzal zmienna, to zapewne nie ta jedna.

Dodaj pare zmiennych dookola, zobacz czy tylko ta jedna sie
zmienia.
Albo dodaj nowa zmienna, zmien program zeby z niej korzystal, ale
te zostaw i monitoruj.



J.

Tue Oct 13, 2009 4:24 pm   

Użytkownik "Darkac" <darkac2@wp.pl> napisał w wiadomości
news:hb1sbu$qoq$1@news.lublin.pl...



wyjechanie za tablicę / zapis przez źle ustawiony wskaźnik?

e.

Tue Oct 13, 2009 4:30 pm   

Darkac wrote:




zapisujac
Chyba ze masz na mysli iz aby dokonac zmiany tej zmiennej trzeba wykonac
sekwencje polecen, np. jak przy zapisie do pamieci Flash,
ale wtedy nie mam mowy o Ramie


mozesz uzyc 100% RAMu i program bedzie dziala poprawnie - oczywiscie jesli
rozmiar fizyczny pamieci jest identyczny lub wiekszy niz rozmiar pamieci,
ktora dysponuje linker.
Nie mieszaj pojec!!! Zajetosc RAMu mowi tylko ile jeszcze zmiennych czy kodu
mozesz dodac do swojego programu.




myslisz badz przekroczyles rozmiar obiektu na ktory wskazuje wskaznik.
Spojrz na mape linkera - gdzie zostala zaalokowana rzeczona zmienna tj. jaka
zmienna znajduje sie przed nia.
2. Uzyj grep i sprwadz wszystkie wystapienia inkryminowanej zmiennej - moze
jednak jest modyfikowna explicite w kodzie.
3. Czy nie zostal przekroczony rozmiar stosu. Na to ma wplyw glebokosc
zgniezdzenia funkcji, ilosc zmiennych automatycznych trzymanych na stosie
itp. a nie zajetosc RAMu przez program!!!

i najwazniejsze wyslac post na grupe pl.comp.lang.c

Tue Oct 13, 2009 5:48 pm   

Tue, 13 Oct 2009 14:37:54 +0200, na pl.misc.elektronika, Darkac napisał(a):


Popatrz na ewentualne bufory, których użycie odbywa się w runtime bez
możliwości skontrolowania w kodzie : np. bufor do konwersji itoa, bufor
odbiornika znakowej transmisji szeregowej itp.

--
Pozdrowienia
Jurek Szczesiul

Tue Oct 13, 2009 9:59 pm   

Źle sparametryzowana biblioteczna funkcja printf potrafi zużyć
dużo stosu. To taki przykład.



Za to kocham MSP430, w hardware-owym debugerze można ustawić pułapkę
na zapis do obszaru pamięci i już wiadomo w wyniku jakiej instrukcji
nastąpił problem. Sprawę rozwiązuje się w chwilkę.

A błędy na stosie mogą się markować bardzo długo a objawiać
bardzo rzadko, akurat wtedy gdy nie trzeba.
K.

Tue Oct 13, 2009 10:15 pm   

Przeciez korzystajac z JTAG na ATMedze128 moze zrobic to samo...

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

Tue Oct 13, 2009 10:37 pm   

Użytkownik "T.M.F." <tmf@nospam.mp.pl> napisał w wiadomości
news:hb2r8g$g8t$1@nemesis.news.neostrada.pl...

Za to kocham JTAG.

Wed Oct 14, 2009 8:51 am   

To czemu tego autor wątku nie zrobi, a Wy nie doradzacie od początku?
Już byłoby po problemie.
K.

Wed Oct 14, 2009 10:47 am   

W dniu 14.10.2009 09:51, John Smith pisze:

Bo to wcale nie jest takie super narzedzie. Wyobraz sobie, ze zmienna
ktora sledzisz jest modyfikowana w wielu miejscach i ciagle twoj program
jest przerywany, mozna zeswierowac sledzac cos takiego.

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

Wed Oct 14, 2009 10:49 am   

Zajetosc RAM, ktora ci pokazuje kompilator moze sie miec nijak do
rzeczywistego zapotrzebowania na pamiec. Przeciez kompilator nie
pokazuje ci miejsca zajetego przez zmienne alokowane dynamicznie oraz na
stosie.

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

Wed Oct 14, 2009 11:23 am   

Użytkownik "T.M.F." <tmf@nospam.mp.pl> napisał w wiadomości
news:hb46v6$5vf$2@atlantis.news.neostrada.pl...

Dlatego też uważałem że potrzebny jest jakis margines bezpieczeństwa.
Dlatego zrobiłem próbę ze zredukowanym radykalnie zapotrzebowaniem na RAM.
Nie wiem w końcu jaką informację niesie pokazany przez kompilator stopień
użycia RAM. Czy jest tam tylko to, co zajmują zadeklarowane zmienne
globalne, czy też razem z maksymalną liczbą zmiennych lokalnych i stosem. Z
powyższych odpowiedzi nie wynika to jednoznacznie. Może ktoś wypowie się.

A tak przy okazji zajętości RAM-u, nie wiem jak rozwiązać następujący
problem:
W programie jest sporo komunikatów tekstowych zadeklarowanych jako stałe w
tablicach jednowymiarowych. Są one wyświetlane na LCD przez procedurę,
której parametrem jest nazwa tablicy. Mimo że deklaracja tablic zawiera
słowo "const", to stałe te niestety zajmują pamięć RAM. I to tyle bajtów ile
w sumie liczą. Jak zrobić żeby stałe te były pobierane z pamięci programu we
Flashu? Dlaczego powielane są do RAM-u? Czy słowo "const" oprócz
zabezpieczenia przed zmianą nie powinno decydować o lokalizacji tej
informacji?

Wed Oct 14, 2009 11:28 am   

On 2009-10-14 12:23:26 +0200, "Darkac" <darkac2@wp.pl> said:


A skąd kompilator ma wiedzieć ile Twój program w runtime zje stosu.
Może zjeść i całą dostępną przestrzeń adresową, jeśli gdzieś go
wpuścisz w stosowną pętelkę...

--
DJ

PS. przy odpisywaniu na priv usun antyspamowy wpis z adresu