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,

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.

"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

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