W dniu 07.11.2009 20:09, slawek7 pisze:
> To jakie są te chwalone zalety pisania programów na ARM w
> architekturze v. Neumanna?
> Przecież tak samo mogę to napisać w AVR. To kompilator dba gdzie
> umieszcza zmienne a ja je tylko deklaruje. wiec o czym mowa w tych
> zaletach?

Tylko, ze w przypadku AVR dbaja o to wylacznie kompilatory komercyjne
(chyba dbaja), gcc niestety nie i stale zadeklarowane jako const laduja
w SRAM zamiast FLASH. Zreszta w przypadku AVR jest dodatkowy problem -
inne instrukcje realizuja dostep do SRAM a inne do FLASH, w efekcie
trzeba miec dwie wersje. No ale nie ma co narzekac, to sa kompromisy w
8-bitowym mikrokontrolerze. Wprowadzenie ciaglej adresacji spowodowaloby
koniecznosc uzycia wiekszych niz 16 bitowe wskaznikow, czyli overkill
dla takiego malego procka.

--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.

do góry

slawek7 pisze:

> Jakie są wady i zalety architektury Von Neumanna w uC ARM np
> AT91SAM7256.
> Ostatnio słyszałem o takim stwierdzeniu że ta architektura ma same
> zalety w pracy uC a porównaniu do architektury Harwardzkiej stosowanej
> w AVR'ach.
> Nie było jednak wyjaśnienia tego.
> Możecie mi wytłumaczyć o co tu chodzi. Ja rozumiem że Von Neumanna to
> połączenie pamięcie danych i programu w jedną ciągłą ale co mi to daje
> jako programiście.

Możesz załadować plik (do pamięci danych) i wykonać go jako program.
Taka z gruntu prosta operacja jest kompletnie niemożliwa np. w
procesorach AVR z architekturą harwardzką.

Druga sprawa to dostęp do danych - np. w funkcji printf podajesz jako
pierwszy parametr adres ciągu znaków do wypisania. No i w ARMach adres
to adres - może sobie być w obszarze programu (np. w pamięci Flash),
może być w danych. A w AVRach to dopiero jest jazda - wymagane są
oddzielne funkcje pobierające ten ciąg z pamięci danych (printf) oraz z
pamięci programu (printf_P) i specjalne makra nakazujące umieszczenie
ciągu znaków w pamięci programu.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

On Sat, 7 Nov 2009 11:09:49 -0800 (PST), slawek7 wrote:
>To jakie są te chwalone zalety pisania programów na ARM w
>architekturze v. Neumanna?
>Przecież tak samo mogę to napisać w AVR. To kompilator dba gdzie
>umieszcza zmienne a ja je tylko deklaruje. wiec o czym mowa w tych
>zaletach?

Nie rozumiesz. Zeby dobrac sie do danych, trzeba w AVR uzyc instrukcji
LD dla RAM, albo LPM dla programu.

Jesli w programie odwolujesz sie do zmiennych, to kompilator wie gdzie
umieszczonych, i uzywa wlasciwych instrukcji.

Ale jesli piszesz funkcje, ktorej parametrem jest wskaznik/adres
danej, to ktorego rozkazu ma kompilator uzyc w srodku funkcji ?

Musialby ambitnie program sledzic, zeby wiedziec z adresem do ktorej
pamieci jest wywolywana ta funkcja. A przeciez moze byc wywolywana
wielokrotnie, ze wskaznikami na oba rodzaje pamieci.

J.

do góry

J.F. pisze:

> Nie rozumiesz. Zeby dobrac sie do danych, trzeba w AVR uzyc instrukcji
> LD dla RAM, albo LPM dla programu.
>
> Jesli w programie odwolujesz sie do zmiennych, to kompilator wie gdzie
> umieszczonych, i uzywa wlasciwych instrukcji.
>
> Ale jesli piszesz funkcje, ktorej parametrem jest wskaznik/adres
> danej, to ktorego rozkazu ma kompilator uzyc w srodku funkcji ?
>
> Musialby ambitnie program sledzic, zeby wiedziec z adresem do ktorej
> pamieci jest wywolywana ta funkcja. A przeciez moze byc wywolywana
> wielokrotnie, ze wskaznikami na oba rodzaje pamieci.

W kompilatorze sdcc dla 8051 przyjęto bardziej uniwersalne rozwiązanie -
we wskaźnikach na dane przekazywana jest oprócz samego adresu również
informacja o typie pamięci. To niestety zabija sporo wydajności
(pobranie jednego bajtu takim wskaźnikiem jest w praktyce wywołaniem
funkcji obsługującej różne typy pamięci).

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry

On Sat, 07 Nov 2009 23:49:54 +0100, Adam Dybkowski wrote:
>W kompilatorze sdcc dla 8051 przyjęto bardziej uniwersalne rozwiązanie -
>we wskaźnikach na dane przekazywana jest oprócz samego adresu również
>informacja o typie pamięci. To niestety zabija sporo wydajności

Otoz to. Tez zle.

J.

do góry

> Druga sprawa to dostęp do danych - np. w funkcji printf podajesz jako
> pierwszy parametr adres ciągu znaków do wypisania. No i w ARMach adres
> to adres - może sobie być w obszarze programu (np. w pamięci Flash),
> może być w danych. A w AVRach to dopiero jest jazda - wymagane są
> oddzielne funkcje pobierające ten ciąg z pamięci danych (printf) oraz z
> pamięci programu (printf_P) i specjalne makra nakazujące umieszczenie
> ciągu znaków w pamięci programu.

Wiele tych niedogownosci jest gcc-specyficznych, bo gcc nie obsluguje
segmentow pamieci - ale ma sie to wkrotce zmienic. Ale ma to tez zalety
- w AVR mozesz miec 64kB FLASH i 64kB SRAM i ciagle adresowac je za
pomoca 16-bitowych wskaznikow, co daje istotne zyski, a przy madrze
napisanym programie korzystanie z oddzielnych funkcji nie jest az tak
uciazliwe. Inaczej musialbys miec wskazniki co najmniej 17 bitowe, czyli
w praktyce 24 bitowe, niezly overkill dla procesora, ktory wlasciwie nie
ma instrukcji operujacych nawet na 16 bitach.
Funkcje tez mozna napisac uniwersalne - ja np. w jednym z programow
zdefiniowalem sobie makra, ktore powoduja, ze najstarszy bit adresu
interpretowany jest jako wskaznik rodzaju pamieci - jak jest 1 to FLASH,
0 - SRAM, oczywiscie zaweza mi to ilosc obslugiwanej pamieci do 2x32kB,
ale mi to wystarczylo. W C++ mozna to zrobic jeszcze bardziej elegancko
i transparentnie dla programu.



--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.

do góry

On Sun, 08 Nov 2009 11:15:34 +0100, T.M.F. wrote:
>> Druga sprawa to dostęp do danych - np. w funkcji printf podajesz jako
>> pierwszy parametr adres ciągu znaków do wypisania. No i w ARMach adres
>> to adres - może sobie być w obszarze programu (np. w pamięci Flash),
>> może być w danych. A w AVRach to dopiero jest jazda - wymagane są
>> oddzielne funkcje pobierające ten ciąg z pamięci danych (printf) oraz z
>> pamięci programu (printf_P)

>Wiele tych niedogownosci jest gcc-specyficznych, bo gcc nie obsluguje
>segmentow pamieci - ale ma sie to wkrotce zmienic.

Ale jak to sobie wyobrazasz ?

>Inaczej musialbys miec wskazniki co najmniej 17 bitowe, czyli
>w praktyce 24 bitowe, niezly overkill dla procesora, ktory wlasciwie nie
>ma instrukcji operujacych nawet na 16 bitach.

No wlasnie.

J.

do góry

Dzięki za pomoc.

Jeszcze mam jedną sprawę tak trochę tylko związaną z tematem.
Mówi się ze dane z pamięci Flash są pobierane wolniej niż z RAM. czy
jest to gdzieć napisane. Przykład. Spotkałem opis programu na ARM typu
AT91SAM7S256 w którym w celu przyspieszenia pracy zrobiono "sztuczkę"
polegającą na przerzuceniu programu z FLASHa do RAM.
Dlaczego.Przecież to odczyt. Rozumiem zapis do pamięci, ale odczyt
miałby być dłuższy?
Skąd to się bierze?

do góry

On Sun, 8 Nov 2009 02:33:23 -0800 (PST), slawek7 wrote:
>Mówi się ze dane z pamięci Flash są pobierane wolniej niż z RAM. czy
>jest to gdzieć napisane. Przykład. Spotkałem opis programu na ARM typu
>AT91SAM7S256 w którym w celu przyspieszenia pracy zrobiono "sztuczkę"
>polegającą na przerzuceniu programu z FLASHa do RAM.
>Dlaczego.Przecież to odczyt. Rozumiem zapis do pamięci, ale odczyt
>miałby być dłuższy? Skąd to się bierze?

Z osiaganych czasow dostepu w technologii SRAM i FLASH ?

Bo tak jak siegam pamiecia to SRAM byly szybsze, choc to czasem trudno
porownac.

J.

do góry

> Mówi się ze dane z pamięci Flash są pobierane wolniej niż z RAM. czy
> jest to gdzieć napisane. Przykład. Spotkałem opis programu na ARM typu
> AT91SAM7S256 w którym w celu przyspieszenia pracy zrobiono "sztuczkę"
> polegającą na przerzuceniu programu z FLASHa do RAM.
> Dlaczego.Przecież to odczyt. Rozumiem zapis do pamięci, ale odczyt
> miałby być dłuższy?
> Skąd to się bierze?

Wszystko jest dokładnie opisane w dokumentacji do procesora.
W zależności od częstotliwości zegara programuje się odpowiednie
opóźnienia przy dostępie do pamięci Flash. Tak więc w praktyce
wykonywanie programu w pamięci RAM zwykle jest znacznie szybsze.

Paweł

do góry