AVRGCC - ?



Masz problem? Zapytaj na forum elektroda.pl

Poprzedni Następny
Wiadomość
Spis treści
From: "Andy" <anok_at_nospam_ceti.pl>
Subject: AVRGCC - ?
Date: Mon, 29 Apr 2002 16:14:51 +0200


witam

czy avrgcc ma juz albo bedzie mialo mozliwosc rozrozniania przestrzeni
adresowych ?

jak na razie dane, ktore chce miec tylko w romie (flashu)
i nie chce ich trzymac w ram'ie musze deklarowac jako PROGMEM (co jest OK)

a przy dostepie do nich uzywac __lpm_inline ( i to jest troche uciazliwe)

ewentualnie memcpy_P , ktore kopiuje z rom'u do ram'u
ale to jest czasowo narzutowe

nie da sie zrobic tak aby kompilator wiedzial, ze dana zmienna jest typu
PROGMEM
i przy odwolaniu do niej sam uzywal lpm ?

dzieki
Andrzej



Poprzedni Następny
Wiadomość
Spis treści
From: marekmSPAM_at_nospam_amelek.gda.pl (Marek Michalkiewicz)
Subject: Re: AVRGCC - ?
Date: Mon, 29 Apr 2002 17:10:17 +0000 (UTC)


Andy <anok_at_nospam_ceti.pl> wrote:

czy avrgcc ma juz albo bedzie mialo mozliwosc rozrozniania przestrzeni
adresowych ?

Chyba nieprędko. Było to dyskutowane już dawno, ale wymagałoby dość
poważnych zmian w kodzie GCC, wspólnym dla wielu typów procesorów
(AVR jest tylko jednym z wielu, a większość to "duże" 32/64-bitowe
z jedną przestrzenią adresową gdzie nie ma takich problemów). A jest
to spory kawał kodu...

jak na razie dane, ktore chce miec tylko w romie (flashu)
i nie chce ich trzymac w ram'ie musze deklarowac jako PROGMEM (co jest OK)

a przy dostepie do nich uzywac __lpm_inline ( i to jest troche uciazliwe)

ewentualnie memcpy_P , ktore kopiuje z rom'u do ram'u
ale to jest czasowo narzutowe

Niestety póki co jest to jedyne wyjście. Ale w praktyce nie jest to
bardzo uciążliwe...

Marek


Poprzedni Następny
Wiadomość
Spis treści
From: "Andy" <anok_at_nospam_ceti.pl>
Subject: Re: AVRGCC - ?
Date: Tue, 30 Apr 2002 03:28:23 +0200


"Marek Michalkiewicz" <marekmSPAM_at_nospam_amelek.gda.pl> wrote in message
news:aajupp$6b2$1_at_nospam_alf.amelek.gda.pl...
Andy <anok_at_nospam_ceti.pl> wrote:

czy avrgcc ma juz albo bedzie mialo mozliwosc rozrozniania przestrzeni
adresowych ?

Chyba nieprędko. Było to dyskutowane już dawno, ale wymagałoby dość
poważnych zmian w kodzie GCC, wspólnym dla wielu typów procesorów
(AVR jest tylko jednym z wielu, a większość to "duże" 32/64-bitowe
z jedną przestrzenią adresową gdzie nie ma takich problemów). A jest
to spory kawał kodu...

szkoda przyzwyczailem sie z Keila 51, ze nie musze pamietac z jakiej przestrzeni
pochodza dane w trakcie ich uzywania


a przy dostepie do nich uzywac __lpm_inline ( i to jest troche uciazliwe)
ewentualnie memcpy_P , ktore kopiuje z rom'u do ram'u
ale to jest czasowo narzutowe

Niestety póki co jest to jedyne wyjście. Ale w praktyce nie jest to
bardzo uciążliwe...



tyle, ze__lpm_inline zwraca zawsze uchar'a
a co w przypadku jak mam inny typ ?

np. float'a

musze go sobie podzielic na 4-ry bajty i tak jeden po drugim
za pomoca __lpm_inline ?

czy moze: memcpy_P( &float_w_ram, &float_w_rom, sizeof( float )); ???

czy mam sobie napisac w asmie rozne rodzaje
__lpm_inline
z roznymi zwracanymi typami ?

czy jest inny sposob ?

Andrzej



Poprzedni Następny
Wiadomość
Spis treści
From: "Piotr Wyderski" <piotr.wyderskiREMOVE_at_nospam_hoga.pl>
Subject: Re: AVRGCC - ?
Date: Tue, 30 Apr 2002 12:25:21 +0200



Andy wrote:

czy mam sobie napisac w asmie rozne rodzaje
__lpm_inline
z roznymi zwracanymi typami ?

Nie wiem, czym dokladnie jest AVRGCC; domyslam sie,
ze to zwykle GCC skompilowane tylko dla AVR-kow,
w zimie kompilowalem kompilator, to taki procesor tez
byl w konfiguracji. Jesli mam racje, to mozesz oszczedzic
sobie sporo pracy dzieki istnieniu rozszerzenia "typeof".
Operator ten zwraca typ zmiennej, wiec wystarczy, ze
napiszesz tylko funkcje (oczywiscie jako extern inline
-- drugie przydatne rozszerzenie :-)) odczytujace pamiec
o ustalonym rozmiarze (tj. 1,2,4, 8(?) bajtow), a nastepnie
stworzysz makro dokonujace odczytu potrzebnej wartosci
i konwertujace do typu zmiennej docelowej. W przyblizeniu
bedzie to wygladac tak:

#define Read(x,adres) ((x) = ((typeof(x)) __lpm_read4(adres)))

I uzycie:

float f;

Read(f,0x1234);

czy jest inny sposob ?

Ten jest bardzo prosty. :-) Wlasnie w ten sposob
zrobilem sobie iteratory do list w C.

Pozdrawiam
Piotr Wyderski

PS. Taki luzny pomysl: a sama deklaracja
"static const unsigned int x = 0" nie wystarczy?




Poprzedni Następny
Wiadomość
Spis treści
From: jfox_at_nospam_poczta.onet.pl (J.F.)
Subject: Re: AVRGCC - ?
Date: Tue, 30 Apr 2002 06:55:54 +0000 (UTC)


On Mon, 29 Apr 2002 17:10:17 +0000 (UTC), <marekmSPAM_at_nospam_amelek.gda.pl> wrote:
Andy <anok_at_nospam_ceti.pl> wrote:
czy avrgcc ma juz albo bedzie mialo mozliwosc rozrozniania przestrzeni
adresowych ?

Chyba nieprędko. Było to dyskutowane już dawno, ale wymagałoby dość
poważnych zmian w kodzie GCC, wspólnym dla wielu typów procesorów
(AVR jest tylko jednym z wielu, a większość to "duże" 32/64-bitowe
z jedną przestrzenią adresową gdzie nie ma takich problemów). A jest
to spory kawał kodu...

A nie ma przypadkiem rozrozniania juz teraz ?
Nawet pod unixem program ma segment programu, dane zainicjowane,
niezainicjowane, stos ...

J.


Poprzedni Następny
Wiadomość
Spis treści
From: "Piotr Wyderski" <piotr.wyderskiREMOVE_at_nospam_hoga.pl>
Subject: Re: AVRGCC - ?
Date: Tue, 30 Apr 2002 12:07:50 +0200



J.F. wrote:

A nie ma przypadkiem rozrozniania juz teraz ?

Nie ma. GCC pracuje wylacznie w trybie flat. Ale ma za to
potezny zestaw rozszerzen, dzieki ktoremu latwo sobie dopisac
potrzebne elementy (w tym i minimalne wsparcie dla segmentow).

Nawet pod unixem program ma segment programu, dane zainicjowane,
niezainicjowane, stos ...

Jesli masz na mysli implementacje systemow Uniksowych na PC,
to na poziomie uzytkownika one nie uzywaja segmentacji. Owszem,
sa sekcje kodu (.text), danych tylko do odczytu (.rodata), danych
zainicjowanych (.data) i niezainicjowanych (.bss), ale one nie maja
zwiazku z segmentacja. To sa tylko informacje dla programu ladujacego,
jak ma rozmiescic dane z pliku w pamieci. Po prostu sekcje .text oraz
.rodata sa odwzorowywane na stronach tylko do odczytu, .data i .bss zas
na stronach do odczytu-zapisu. W systemie istnieja oczywiscie dwa
segmenty: kodu i danych, ale one sa wymuszone przez konstrukcje
procesorow IA-32, a nie przez system. Te segmenty zwykle maja
baze=0 i limit 3GiB, czyli de facto w ogole nie sa uzywane. Uniksy
realizuja ochrone pamieci mechanizmem pamieci wirtualnej, nie
segmentacji -- sam format ELF nie dostarcza wsparcia dla segmentacji.
Na poziomie systemowym segmentacja jest uzywana, ale w stopniu
minimalnym i jawnie -- kompilator rozwija wtedy wstawki, sam nic
przy segmentach nie kombinuje. Tego sie uzywa wylacznie do
implementacji blokow danych lokalnych (dla procesora, procesu,
watku itd.), wiec nie ma potrzeby rozbudowywac kompilatora.
Tym bardziej, ze co procesor, to zupelnie inne mechanizmy
segmentacji: IA-32, Alpha, MIPS, PPC, IA-64... :-)

Pozdrawiam
Piotr Wyderski