>>>> 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.
>>>
>>>
>>> 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ę.
>>
>>
>> Przeciez korzystajac z JTAG na ATMedze128 moze zrobic to samo...
>
>
> Za to kocham JTAG.

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

do góry

W dniu 14.10.2009 09:51, John Smith pisze:
>>>>> 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.
>>>>
>>>>
>>>> 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ę.
>>>
>>>
>>> Przeciez korzystajac z JTAG na ATMedze128 moze zrobic to samo...
>>
>>
>> Za to kocham JTAG.
>
> To czemu tego autor wątku nie zrobi, a Wy nie doradzacie od początku?
> Już byłoby po problemie.

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.

do góry

> 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.

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.

do góry

Użytkownik "T.M.F." <t...@n...mp.pl> napisał w wiadomości
news:hb46v6$5vf$2@atlantis.news.neostrada.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.
>
> 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.

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?

do góry

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

> czy też razem z maksymalną liczbą zmiennych lokalnych i stosem.

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

do góry

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

> Jak zrobić żeby stałe te były pobierane z pamięci programu we Flashu?

AFAIR było wałkowane kiedyś już na grupie. Przeszukaj archiwum.

--
DJ

PS. przy odpisywaniu na priv usun antyspamowy wpis z adresu

do góry

> 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

http://www.nongnu.org/avr-libc/user-manual/pgmspace.
html

Michał

do góry

Użytkownik "Michał Lankosz" <m...@t...pl> napisał w wiadomości
news:hb4bmb$t3a$1@srv.cyf-kr.edu.pl...
>> 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
>
> http://www.nongnu.org/avr-libc/user-manual/pgmspace.
html
>
> Michał
>

Dzięki za linka. Prawdopodobnie to rozwiąże ten problem. Szkoda tylko że
trzeba odwoływać się do różnych chytrych sztuczek żeby uzyskać, tak wydaje
się, podstawowe i częste pożądane działania.
Czasem odnoszę wrażenie, że jednak czasem komputer nie jest dla człowieka, a
raczej człowiek dla komputera.
Ostatnio mam do czynienia z procesorem DSP i środowiskiem do jego
programowanie, gdzie nie jest przewidziany binarny sposób zapisu liczby.
Jedynie dec lub hex. Prawdziwy horror, kiedy wciąż trzeba manipulować na
pojedynczych bitach zmiennych czy rejestrów.
A za to jest bardzo fajna właściwość, bo można zadeklarować zmienne pełniące
rolę dwustanowych flag jako "bool". Podejrzewam, że nie zajmują wtedy całego
bajtu. Jeśli tak , to przydało by się coś takiego w programowaniu ATmegi.
Kupę RAM-u zajmują flagi. Duże marnotrawstwo. Bawienie się w maski, to znów
przystosowywanie się do kaprysów komputera.

do góry

On 2009-10-14 13:59:08 +0200, "Darkac" <d...@w...pl> said:

> za to jest bardzo fajna właściwość, bo można zadeklarować zmienne
> pełniące rolę dwustanowych flag jako "bool". Podejrzewam, że nie
> zajmują wtedy całego bajtu. Jeśli tak , to przydało by się coś takiego
> w programowaniu ATmegi. Kupę RAM-u zajmują flagi. Duże marnotrawstwo.

Oj, kłania się C...
http://en.wikipedia.org/wiki/Bit_field

--
DJ

PS. przy odpisywaniu na priv usun antyspamowy wpis z adresu

do góry

Użytkownik "DJ" <j...@p...onet.pl> napisał w wiadomości
news:hb4f5g$v2f$1@news.dialog.net.pl...
> On 2009-10-14 13:59:08 +0200, "Darkac" <d...@w...pl> said:
>
>> za to jest bardzo fajna właściwość, bo można zadeklarować zmienne
>> pełniące rolę dwustanowych flag jako "bool". Podejrzewam, że nie zajmują
>> wtedy całego bajtu. Jeśli tak , to przydało by się coś takiego w
>> programowaniu ATmegi. Kupę RAM-u zajmują flagi. Duże marnotrawstwo.
>
> Oj, kłania się C...
> http://en.wikipedia.org/wiki/Bit_field
>
> --
> DJ

Ale to przecież nic innego jak zabawa w maski. Stosowanie chytrych sztuczek
i obiegnięć do osiągnięcia, wydawałoby się, prostego celu. Kompilator robi
miliony różnych automatycznych operacji, mógłby robić również i to. Wszystko
powinno być podporządkowane wygodzie człowieka. Po co zaśmiecać głowę i
treść programu operacjami które może zrobić maszyna.
Szybkość, łatwość i wygoda, to powinny być priorytety w pracy programisty.

do góry