Goto page Previous 1, 2
T.M.F.
Guest
Sun Nov 08, 2009 11:15 am
Quote:
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.
J.F.
Guest
Sun Nov 08, 2009 11:22 am
On Sun, 08 Nov 2009 11:15:34 +0100, T.M.F. wrote:
Quote:
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 ?
Quote:
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.
J.F.
Guest
Sun Nov 08, 2009 11:49 am
On Sun, 8 Nov 2009 02:33:23 -0800 (PST), slawek7 wrote:
Quote:
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.
slawek7
Guest
Sun Nov 08, 2009 12:33 pm
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?
Paweł
Guest
Sun Nov 08, 2009 12:35 pm
Quote:
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ł
Adam Dybkowski
Guest
Sun Nov 08, 2009 9:23 pm
Paweł pisze:
Quote:
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.
100% true. A do tego jeżeli już mówimy o AT91SAM7Sxx to tam wewnątrz
jest AFAIR pamięć Flash o organizacji 16-bitowej i dlatego wykonywanie
programu w trybie ARM (o instrukcjach 32-bitowych) jest powoolne.
Dodatkowo pamięć Flash ma 1 waitstate powyżej chyba 33 MHz zegara (a ten
procek musi śmigać na 48MHz gdy działa USB). Pobrania z pamięci programu
są "pakowane" w kawałki 32-bitowe (taki mini cache). Ale i tak w
praktyce warto kompilować wszystko w trybie Thumb (z instrukcjami
16-bitowe) - nie dość, że kod jest krótszy to jeszcze szybciej działa
niż w trybie Thumb. A krytyczne czasowo funkcje kompilować w trybie ARM
i wykonywać z RAMu.
Jak miło, że nie trzeba takich kombinacji alpejskich robić w ARM9 (np.
AT91SAM9260), bo pamięć cache programu śmiga z pełną prędkością (a dane
pobiera np. z SDRAM całymi liniami do cache). W tym przypadku kompilacja
w trybie Thumb daje co prawda krótszy kod wynikowy, ale wolniejszy.
--
Adam Dybkowski
http://dybkowski.net/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
Goto page Previous 1, 2