Bardzo często pisząc programy posługujemy się zmiennymi lokalnymi, które teoretycznie zwalniają pamięć jeśli nie są używane... ale dlaczego przestawiając podział pamięci na zewn. SRAM (kostka 62256), zmienne te jakby się nie inicjowały i program się wywala?
Przykład:
dodałem do makefile
LDFLAGS += -Wl,--section-start,.data=0x801100,--defsym=__heap_end=0x8090ff
a tu program:
Reasumując: mam program, w którym jest masa modułów, masa zmiennych lokalnych i wnosząc takie dodatki jak zewnętrzny SRAM (jeśli chodzi o sprzęt) i dodatki programowe w samym makefile nie pomagają
czy chcąc używać SRAMU muszę teraz wszystkie zmienne lokalne przerabiać na wskaźniki i posługiwać się malloc() itp? To by było bez sensu, musi być jakieś rozsądne rozwiązanie tego problemu, aby nie ingerować w kod za zbytnio.
Problem zrodził się w rozbudowanym programie, w którym na dodatek chciałem użyć bardzo dużych tablic. Nie chcę używać pamięci flash i eepromów, nie potrzebuję nieulotności danych itp. chodzi mi konkretnie o pamięć sram. Może któryś z kolegów już coś takiego przerabiał?
Aaa, przez nie działanie programu chciałem tutaj powiedzieć, że przez USARTa ciągu znaków "START" nie doczekamy się - wykonanie programu tutaj jakby nie dociera.
Pozdrawiam.
Przykład:
dodałem do makefile
LDFLAGS += -Wl,--section-start,.data=0x801100,--defsym=__heap_end=0x8090ff
a tu program:
#include (...) // tutaj początek programu
/*
// tak dziala -- tablice jako zmienne globalne ładnie lądują
// w sramie i rozmiar .bss zwiększa się, tak jakby procek już rezerwował
// obszar SRAMu
uint16_t wartosc_reg[5376];
uint8_t wartosc_reg_hi[501];
uint8_t wartosc_reg_lo[501];
*/
void init_extemem(void) __attribute__((naked,section(".init3"))) ;
void init_extemem(void)
{
MCUCR |= (1<<SRE) | (1<<SRW10);
XMCRA = (1<<SRL2) | (0<<SRL1) | (0<<SRL0) | (1<<SRW01) | (1<<SRW00) | (1<<SRW11);
XMCRB = (1<<XMBK);
}
int main(void)
{
/*
// tak nie dziala - zmienne lokalne - dlaczego :( ???????????
uint16_t wartosc_reg[5376];
uint8_t wartosc_reg_hi[501];
uint8_t wartosc_reg_lo[501];
*/
/*
// tak się da poprawnie wykonać program - zmienne ponizej dzialaja
// sekcja .bss nie jest zapchana dużymi tablicami
uint16_t *wartosc_reg;
uint8_t *wartosc_reg_hi;
uint8_t *wartosc_reg_lo;
unsigned char* data_pointer = (unsigned char*)0x6ff0;
*/
// dopiero teraz moge zapisywac i odczytywac tablice
// ale rozmiar .bss nie rosnie, dlaczego?!
uint16_t *wartosc_reg;
wartosc_reg = (int *)malloc(5376*sizeof(uint16_t));
uint8_t *wartosc_reg_hi;
wartosc_reg_hi = (int *)malloc(501*sizeof(uint8_t));
uint8_t *wartosc_reg_lo;
wartosc_reg_lo = (int *)malloc(501*sizeof(uint8_t));
unsigned char* data_pointer = (unsigned char*)0x6ff0;
sei();
usart_init(9600);
usart_write("START\n");
wartosc_reg_lo[500]=0x2d;
// troche zabawy, wartosci o 1 mniejsze od adresu komórek zapisuja sie
// do tablicy, a po przekroczeniu adresu komórki 5000 wyświetlam
// sobie adres i wartość tablicy po USART-cie i wszystko jest ok w przypadku
// gdy nie używam zew. sramu (ale wtedy max. długość tablicy znacznie
// mniejsza) lub tak jak wyżej ze sram-em działa, ale jeśli tablica jest
// jako zmienna globalna lub poprzez wskaźniki i malloc()
// jak to zrobić aby zmienne lokalne - duże tablice nie wywalały programu
// i wszystko działało jak przed dodaniem kostki 62256 i dodaniu wpisu do makefile-a?
for (uint16_t i=0; i<5375; i++)
{
wartosc_reg[i]=i-1;
if (i>=5000) usart_write("%i %i\r\n",i,wartosc_reg[i]);
}
while (1)
{
if (odebrano_znak==1)
{
*data_pointer=(unsigned char)receive_char;
usart_write_char(*data_pointer);
usart_write_char(wartosc_reg_lo[500]);
odebrano_znak=0;
}
}
return 0;
}
Reasumując: mam program, w którym jest masa modułów, masa zmiennych lokalnych i wnosząc takie dodatki jak zewnętrzny SRAM (jeśli chodzi o sprzęt) i dodatki programowe w samym makefile nie pomagają
Problem zrodził się w rozbudowanym programie, w którym na dodatek chciałem użyć bardzo dużych tablic. Nie chcę używać pamięci flash i eepromów, nie potrzebuję nieulotności danych itp. chodzi mi konkretnie o pamięć sram. Może któryś z kolegów już coś takiego przerabiał?
Aaa, przez nie działanie programu chciałem tutaj powiedzieć, że przez USARTa ciągu znaków "START" nie doczekamy się - wykonanie programu tutaj jakby nie dociera.
Pozdrawiam.