AVRSTUDIO

W dniu 2011-07-14 07:25, Lelek@ pisze:

Sama struktura w ogólności nie gwarantuje ciągłości (człowiek nawet nie poczuje jak mu się zrymuje), bo dochodzi jeszcze coś takiego jak wyrównanie adresów (padding po polsku) dla zmiennych wielobajtowych (np. int). Na avr nie powinieneś mieć z tym problemu jeśli do opcji kompilacji jest dodawane -fpack-struct, albo użyjesz atrybutu packed przy strukturze.

A nie można zmusić tych tablic jakimś atrybutem żeby jedna za drugą sie ustawiły w ramie? mam już napisany program i teraz przyszła mi ochota na chwilowy bufor 1kB ale nie mam tego 1kilo, a tablice są niepotrzebne w chwili używania tego obszaru jako bufor. W asm to nie ma kłopotu. .org i jazada.

W dniu 2011-07-14 08:22, Lelek@ pisze:

A w gcc to byś musiał dodać osobne sekcje w RAMie do skryptu linkera a potem atrybutem section wstawić daną tablicę do odpowiedniej sekcji (niektóre kompilatory używają @ do określania adresów zmiennych, ale gcc do nich nie należy). Mniej pracy będzie kosztowało wsadzenie tych tablic do struktury.

W C od tego masz unie. W gcc powinno zadziałać coś takiego: union { unsigned char bigtable[1000]; struct { unsigned char A[100]; unsigned char B[200]; unsigned char C[700]; } __attribute__ ((packed)) smalltables; } data;

Do przestrzeni liniowej odwołujesz się przez data.bigtable[], a do małych tablic przez data.smalltables.A[] itd. Deklaracja powinna też zadziałać bez atrybutu packed, ale dla świętego spokoju lepiej go zostaw.

pzdr. j.

In the darkest hour on Thu, 14 Jul 2011 08:07:16 +0200, Zbych snipped-for-privacy@onet.pl screamed:

Ewentualnie jedna wielka tablica i wskaźniki do indeksów.

W dniu 14.07.2011 08:22, Lelek@ pisze:

unsigned char Bufor[1024];

//unsigned char A[128]; unsigned char *A = &Bufor[0]

//unsigned int B[32]; unsigned int *B = (unsigned int *) &Bufor[128];

//unsigned int char C[16]; unsigned char *C = &Bufor[192];

i dalej możesz spokojnie używać zapisów: A[3] = 5; for (i=0;i<32;i++) B[i] = 0; if(C[4] >= 10) ...

ALE!! Uwaga!! Zapisy typu sizeof(A) na pewno Ci nie zwrócą wielkości tablicy A, bo kompilator nawet nie wie, ile ona zajmuje!! Pomijając fakt, że zmiana rozmiaru pierwszej tablicy pociąga za sobą konieczność korekty pozostałych, choć to możesz ominąć odpowiednimi dyrektywami #define... Ale z tym powalcz już sam ;)... Tak czy siak - ja bym tak napisał program tylko, jeśli chciałbym komuś uprzykrzyć życie... w przeciwnym wypadku stosowałbym struktury!! Co do tego, czy są ciągłe - w 8-bitowcu właściwie na pewno, poza tym, jeśli nie są, to miejsce pomiędzy nimi jest "puste", więc nic nie stoi na przeszkodzie, aby je wykorzystać. Np. struct { unsigned char A[130]; unsigned int B[32]; unsigned char C[16]; } _s;

i możesz spokojnie odwoływać się do: _s[140] bez obawy, że wyjedziesz poza obszar struktury _s.

no dzięki Panowie :-) Wzdrgam się przed przerabianiem tego :-) Ale muszę do tego przysiąść :-) Mam na razie "zmarnowane" 844B, bo nie zamierzałęm wcześniej robić takiego bufora do chwilowego uzycia. Chyba następnym razem bedę grupował tablice na potrzebne i czasem zbędne i od razu w strukturę.

Szkoda, że nie można po prostu ustawić ich kolejno i __attribute__ costam :-)

In the darkest hour on Fri, 15 Jul 2011 04:42:15 +0200, Lelek@ snipped-for-privacy@iw.iw screamed:

Z wszystkich propozycji wybrałbym jednak tę opartą o unię.

W dniu 15.07.2011 04:42, Lelek@ pisze:

Możesz ustawić je oddzielnie i dać "extern". A potem ułożyć je w pliku asm tak jak chcesz.

Możesz też użyć np takiego stm32, gdzie w cenie ~atmegi8 będziesz miał