AVR-GCC - deklaracja zmiennych pod wskazanym adresem

... Jeżeli tego potrzebujesz do obsługi jakiegoś urządzenia (memory mapped io) to można to zrobić z użycien standardowego C: volatile char* tabl = (volatile char*)0x2000; i dalej normalnie używasz tabl jako zwykłej tablicy C.

Jeżeli chcesz wykorzystać zewnętrzną pamięć RAM to jest to opisane w avr-libc FAQ.

Jezeli robisz bootloader to zainteresuj się atrybutem o nazwie section. Chodzi o __attribute__ (( attribute-list ))

A jeżeli masz tylko taki i kaprys, żeby mieszać kompilatorowi w pamięci

Pozdrawiam,

U¿ytkownik "Artur Lipowski" snipped-for-privacy@pro.onet.pl> napisa³ w wiadomo¶ci news:bvd3j5$r9d$ snipped-for-privacy@news.onet.pl...

No jasne! ¯e te¿ na to nie wpad³em! :-) Tyle, ¿e kompilator nie bêdzie zna³ rozmiaru tablicy, ale to ju¿ pójdzie programowo.

Ale i tak jestem niepocieszony brakiem dyrektywy "_at" :-(, do której siê ju¿ przywi±za³em.

Z tego opisu wynika, ¿e powinienem skorzystaæ z mechanizmów dynamicznego przydzia³u pamiêci, ale w tym przypadku raczej nie ma takiej potrzeby.

Nie robiê bootloadera, ale ethernetowy dekoder MP3. Obecnie do testów u¿ywam ATmega162. W jego zewnêtrznej przestrzeni adresowej jest umieszczona 8-kilowa SRAM (tam bêdzie FIFO), ale oprócz niej s± jeszcze obszary do komunikacji z modu³em Ethernetowym i 8-bitowy równoleg³y port dekodera MP3. Wszystko tak przemiksowane w adresach, ¿e g³owa boli (s± nawet obszary zachodz±ce na siebie, gdzie mam konflikty). Dosta³em to jako gotowy uk³ad bez oprogramowania zrobiony w oparciu o '51, która okaza³a siê za wolna, wiêc tymczasowo zast±pi³em j± meg± 162, ¿eby zrobiæ próby na tym co mam. Pó¼niej przeprojektujê to cudo na megê128.

I masz racjê, to jest chyba tylko kaprys, bo by³oby "fajniej", ale sposób podany przez Ciebie wy¿ej chyba bêdzie OK.

Wielkie dziêki!!! QmX.

QmX wrote: ...

Z tego "znania" rozmiaru tablicy i tak raczej niewielki pożytek (niestety). Oczywiście zdajesz sobie sprawę, że nikt nie każe Ci używać całej dodatkowej pamięci jako tablicy znakowej. Ta sama metoda może (powinna) być użyta do przechowywania tam innych typów, a w tym struktur, które są nieocenione przy dostępie do pamięci urządzeń (MMIO).

...

Proszę bardzo.

Pozdrawiam,

W artykule <bvcv45$t4e$ snipped-for-privacy@korweta.task.gda.pl> autorem którego mieni się QmX, napisano:

Pierwsza możliwość (doc/gnu/gcc/Variable-Attributes.html#Variable%20Attributes):

struct duart a __attribute__ ((section ("DUART_A"))) = { 0 };

W skrypcie linkera trzeba zdefiniować sekcję j.w. pod właściwym adresem.

Druga możliwość - w kodzie zadeklarować zmienną, np.

extern char lcd[1024];

i nie podawać definicji. W skrypcie linkera umieścić przypisanie

lcd = 0x4000;

Uwaga - trzeba zadbać, by linker miał informację o tym, że zajmujemy kawałek pamięci (parametery sekcji), bo inaczej może tam coś ulokować.

Jest jeszcze prostsza metoda:

char *lcd = (char*) 0x4000;

lcd[7] = 0x77; /* Dostęp */

Uwaga jak wyżej.

Pozdrawiam Jarosław Szynal

On Behalf Of JS

Niby w BASCOM nie ma takich problemów, ale... jak się dzieli long przez word to wynik wychodzi long. Niby logiczne, tylko czemu wynik zapisany w word daje bzdurne liczby? Pierwsza, druga i prostsza metoda : zapisywać wynik w long. Nie pisałem o tej przypadłośći autorowi, ale tak ku przestrodze, żeby inni nie marnowali dwóch dni. Przy okazji - nie mam czasu na sprawdanie dlaczego wychodzi bzdura jeśli 125000 dzielę przez 1000. Musi jaki robal tam siedzi.

pzdr Artur PS W sumie w każdym programie należy się _zastanowić_jak_zmniejszyć wielkość zmiennych. Zawsze to kawałek RAM zostaje, a i kod jest mniejszy.

No w³a¶nie i tu jest przewaga C nad Bascomem.

W C takie sytuacje nie wyst±pi± je¿eli programista ma trochê oleju w g³owie. Natomiast w Bascomie? nie wiem.

Mister

Rowniez zalecam zapoznanie sie z dokumentacja skryptow linkera, przy odrobinie wprawy mozna w ten sposob zrobic z ukladem pamieci bajeczne rzeczy. Tylko w takich przypadkach zamiast extern lepiej uzyc extern "C" albo __attribute__((__alias__)), bo kompilator moze robic nieprzyjemne z punktu widzenia czlowieka rzeczy podczas "manglowania" nazw.

Pozdrawiam Piotr Wyderski

"Mister" <wojpie@wywal_to.poczta.onet.pl> napisal(a):

He he he nie bylbym taki pewien, rzutowanie typów niezle miesza w wynikach w C. Pozdr Janusz

Je¿eli wiesz co robisz to w czym problem ? Co siê mo¿e namieszaæ?

Mister

On Behalf Of Mister

A co, jeśli się wie, a i tak można namieszać? Jak właśnie zauważyłem niejawne konwersje dotarły do bascom'a. A namieszać się może bardzo dużo, w zależności od kompilatora. Np. w bascom. Użycie zmiennej single do wykresów bruździ. Użycie tej samej wartości po przypisaniu jej do zmiennej word powoduje, że wykres jet prawidłowy. Ale word= single (123) * word (2) daje bzdurę. Musi być singel= single*single i w następnym wierszu word = single. W C jest podobnie, niby konwersje typów są prawidłowe, ale czasami, zdarzają się sytuacje wyjątkowe. Przypuszczam, że to jest świadome działanie autora, który musiał wybrać pomiędzy uniwersalnością, a długością kodu. W sumie - zawsze wszystko trzeba sprawdzać trzy razy ;-)

pzdr Artur