AVR: Umiejscowienie stałych i optymalizacja pamięci w GCC

Question

Witam wszystkich! Mam kilka pytań do szanownych kolegów: a) Gdzie w pamięci lądują stałe podane w kodzie programu w ten sposób: (mam na myśli 50,100,-100,0) b) Czy jeśli wysyłam wielokrotnie w różnych miejscach programu komendę czyszczenia LCD (czy inną) to czy kompilator tworzy jakąś stałą i ta...

Konto nie istnieje · Answer

a) te stałe są 'danymi natychmiastowymi' i lądują w pamięci programu (flash);

b) write_command(0x40) - to nie jest funkcja GCC, jest to jakaś funkcja, którą stworzył autor tego programu, który cytujesz; w pamięci jest ona zapisana tylko raz, takimi kolejnymi komendami powodujesz tylko skok do tej funkcji, więc zbyt dużo miejsca nie tracisz;

c) tak - podczas deklaracji takich zmiennych kompilator rezerwuje sobie miejsce w pamięci tylko i wyłącznie dla tych zmiennych

d) oj, tego nie wiem, podczas kompilacji podawana jest zajętość flashu i eepromu, ale co się dzieje z RAMem to nie wiem

BoskiDialer · Answer

d) To, ile jest zużytej pamięci RAM w sprzyjających warunkach można policzyć. Ogólnie pamięć wewnętrzna jest rozlokowana jakoś tak:
data - bss - wolne - stos
teoretycznie można pobrać adres pierwszej wolnej komórki, wierzchołek stosu i można policzyć ile pamięci jest wolne - aczkolwiek 'wolne' to pojęcie względne - wywołanie funkcji, przerwań etc będzie tą pamięć uszczuplać. Inaczej wygląda sprawa, kiedy ma się do mikrokontrolera podłączoną zewnętrzną pamięć i do tego menager pamięci.

aster11 · Answer

ad c) Wartości inicjalizacyjne zmiennych są oczywiście, jak to powiedziano, przechowywane w pamięci stałej (np. flash). Można tu jeszcze zwrócić uwagę na następujące szczegóły: 1. Trudno dać głowę, że liczba bajtów zajętych przez wartości inicjalizacyjne będzie proporcjonalna do liczby inicjalizowanych zmiennych. Np. gdy kolejne wartości inicjalizujące są identyczne (jak w przykładzie), kompilator może zastosować pewne optymalizacje. 2. Pamięciowy koszt inicjalizacji to nie tylko same wartości inicjalizujące, zajmujące pamięć, ale także (a może bardziej) same instrukcje inicjalizacji, które oczywiście także zajmują pamięć programu. 3. Inicjalizacja wartościami zerowymi (jak w przykładzie) ma charakter szczególny. W przypadku zmiennych globalnych i statycznych zmiennych lokalnych jest to początkowa wartość domyślna, gwarantowana przez standard języka C (technicznie realizacja tego polega na umieszczeniu takich zmiennych w początkowo wyczyszczonym obszarze). W przypadku takich zmiennych ich jawna inicjalizacja (wartościami zerowymi) ma charakter nadmiarowy i rzeczywiście zajmuje niepotrzebnie miejsce w pamięci programu - chyba, że odpowiednia zdolność optymalizacji kompilatora potrafi to wykryć i wyeliminować.

tmgofer · Answer

Nie no, to oczywista sprawa sam ją pisałem. Chodziło raczej o 0x40 Dokładnie to jest sedno całej sprawy. Czyli jednak kompilator może wykazać się taką spostrzegawczością i zapamiętać wartość w jakiejś jednej komórce pamięci... Nie wie ktoś przypadkiem, czy któraś z optymalizacji (1,2,3,s) gwarantuje takie postępowanie kompilatora? Warto wiedzieć...

marek_Łódź · Answer

Możesz sobie zdezasemblować kod i obejrzeć reprezentację. W przypadku write...(0x40) stworzenie wspólnej czterdziestki dla wszystkich wywołań jest mało opłacalne bo prosciej jest pobrać tę wartość bezpośrednio w obszarze wywołania, jak tworzyć dodatkowe odsyłacze do wspólnej komórki.

szelus · Answer

Może trochę spróbuję podsumować, bo, sądząc z pytań, odpowiedzi kolegow powyżej, aczkolwiek poprawne, moga być na nieco zbyt wysokim poziomie abstrakcji

1. Stałe są umieszczane w pamięci programu, a nie pamięci danych.
2. AVR gcc preferuje umieszczanie stałych wewnątrz kodu rozkazu umieszczającego ją w rejestrze. Krócej się nie da, bo załadowanie danej z pamięci flash (umieszczonej poza rozkazem) do rejestru zajmie więcej kodu.
3. Zmienne globalne (i statyczne) z wartością początkową inna niż 0 są umieszczane w ciągłym obszarze RAM, tak że ich wartości zapisane w ciągłym obszarze pamięci FLASH zostaną przepisane na poczatku programu prostą petlą (rodzaj funkcji) memcpy. Też się tego nie da raczej zrobić efektywnie.
3. Nie wiem, jak dla "dużych" zmiennych automatycznych w rodzaju:


struct abc {
  int a;
  int b;
  int c;
};

int foo(void)
{
    struct abc x = {1,2,3};

}

ale raczej unikam takich konstrukcji dla mikrokontrolerów :wink:

4. W przykładowym makefile-u w WinAVR jest generowanie listingu (.lst).
Wykonując make lst dostajemy taki listing, w którym dokładnie rozpisane jest wykorzystanie pamięci. Ręcznie można to uzyskać wykonując komedę

avr-objdump -h prog.elf

Aby ustalić zajętość RAM należy dodać do siebie rozmiary sekcji .data .bss .noinit i (zakładany) rozmiar stosu.

marek_Łódź · Answer

W przypadku stałych, których rozmiar przekracza możliwości alokowania w pamięci RAM, można wykorzystać mechanizmy umożliwiające ich alokowanie w pamięci kodu np funkcje dostępu do pamięci kodu pgmspace.h

przykład wycięty z jakiegoś programiku:

.....
#include <avr/pgmspace.h>

#define Word uint16_t
#define Byte uint8_t

.....
//Stałe w pamięci kodu

Byte XCode[0x1000] PROGMEM = 
  {0x00, 0x13, 0x02, 0x00, 0x08, 0x00, 0x00, 0x00, 0x16, 0x00, 0x2E };


#define  GetCodeByte(n) pgm_read_byte_near(&XCode[n])
#define  GetCodeWord(n) pgm_read_word_near(&XCode[n])

Tak w prosty sposób możemy zdefiniować np. stałe teksty, sekwencje sterujące wyświetlaczem itp.

_pieczas · Answer

Panowie.
W moim programie dla atmegi32 mam 2 tablice typu uint32_t. Te tablice muszą (?) mieć charakter statyczny i pracują w innej fukcji niż main. Ściśle mówiąc będą wywoływane przez timer. Problem polega na tym, że gdy tylko dostaną przydomek "static" ich objętość rośnie. I tak 2 zmienne uint32 po 256 elementów zapełniają mi pamięć w 104%. Gdy przerzucę je poza obszar funkcji i zadeklaruje jako globalne to historia taka sama. Czy można ominąć ten problem zachowując ich statyczność? Przy każdym wykonaniu funkcji dopisywany jest jeden element przy czym nie mogą zostać zapomniane starsze elementy, a gdy tablica się przepełni wówczas nadpisywana jest od początku (FIFO).

Promuję tematy:
11.08.2016 BMW e90 LCI 2009 - Typ diody LED w przednim kierunkowskazie

zumek · Answer

...całą dostępna w ATMega32 pamięć RAM. Wytłumacz proszę, o co Ci DOKŁADNIE chodzi.

_pieczas · Answer

Kompilacja nie następuje gdyż Data memory usage = 104%Full. Po wykomentowaniu static zajętość pamięci wynosi kilka procent. Chodzi mi o to, że tablice te są konieczne w moim programie. Muszą one być statyczne - nieulotne po wyjściu z funkcji. Jednakże ustawiając je jako statyczne powoduję że zapełniają pamięć. Gdy jednak nie są statyczne wówczas program nie działa poprawnie.

tadzik85 · Answer

Przecież to oczywiste skoro wykorzystujesz więcej RAMu niż posiadasz. Co tym zmiennej nie ma tu znaczenia. lokalna static czy nie gdzieś musi się znajdować.

excray · Answer

Oznacza to że wybrałeś nie właściwy mikroprocesor do swojego projektu. Za mało RAM.

tmgofer · Answer

Ściśle mówiąc to funkcja obsługi przerwania (od przepełnienia/porównania) timera będzie na nich wykonywała jakieś operacje (np. zapisu) Jak umieszczasz je wewnątrz funkcji bez static to mają dokładnie taką samą wielkość, ale lądują na stosie jako zmienne automatyczne. Dlatego kompilator nie wykrywa błędu w czasie kompilacji. Nie jest świadomy, że w tym przypadku stos się przepełni. Tak jak wspomnieli koledzy wcześniej, procek ma za mało pamięci RAM na zadanie, które przed nim postawiłeś.

_pieczas · Answer

Dziękuję za konkretne odpowiedzi. Szczerze powiedziawszy zaniedbałem przemyślenia nad tym, że dwie tablice mogą zapełnić mi całą atmegę.

AVR: Umiejscowienie stałych i optymalizacja pamięci w GCC

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Podsumowanie tematu