Goto page Previous 1, 2
Michał Smolnik
Guest
Mon May 30, 2011 9:13 pm
W dniu 30.05.2011 23:05, Michał Lankosz pisze:
Quote:
Program można też uruchomić z SRAMu.
Ale program będzie wolniej się wykonywał, przynajmniej korzystający z
pamięci danych (w RAM).
W datasheecie to rozwiązanie jest zaznaczone jako dla debugu.
Michał
Michoo
Guest
Mon May 30, 2011 9:29 pm
W dniu 30.05.2011 23:05, Michał Lankosz pisze:
Quote:
Użytkownik "Michał Smolnik" <msmolnik@fims.pl> napisał w wiadomości
news:is0qld$h50$1@news.onet.pl...
Program można też uruchomić z SRAMu.
Ale program będzie wolniej się wykonywał,
Ztcw będzie się szybciej wykonywał (i z mniejszym poborem prądu) - FLASH
powyżej 24MHz musi mieć 1 a powyżej 48 - 2 wait-state. RAM - nie.
Quote:
przynajmniej korzystający z
pamięci danych (w RAM).
Dlaczego?
--
Pozdrawiam
Michoo
Marcin Wasilewski
Guest
Mon May 30, 2011 9:44 pm
Użytkownik "Michoo" <michoo_news@vp.pl> napisał w wiadomości
news:is128v$i0b$1@news.onet.pl...
Quote:
Ale program będzie wolniej się wykonywał,
Ztcw będzie się szybciej wykonywał (i z mniejszym poborem prądu) - FLASH
powyżej 24MHz musi mieć 1 a powyżej 48 - 2 wait-state. RAM - nie.
przynajmniej korzystający z
pamięci danych (w RAM).
Dlaczego?
Elementarne. Jeśli instrukcje programu są pobierane z jednej magistrali, w
tym samym czasie na drugiej magistrali mogą być pobierane dane. W opisywanym
przypadku, gdy będziesz pobierał z SRAM dane, to nie będziesz mógł w tym
czasie pobierać instrukcji. Oczywiście nie każda instrukcja polega na
przesyłaniu danych. Ale na pamięci SRAM zapewne i jakieś DMA działa. A to
wszystko pochłania cykle dostępu.
Portal
Guest
Mon May 30, 2011 10:36 pm
Quote:
Tylko dlaczego w dokumentacji pamięć jest pokazana jako ciągła czyli
flash potem RAM w adresach rosnących?
Czy jeśli była by to faktycznie harwardzka to czy Flash i RAM nie
powinny zaczynać się od zera?
To co siedzi w tych prockach nosi nazwę zmodyfikowanej architektury
Harvard czyli dwie oddzielne szyny do pobierania instrukcji i przesyłu
danych, ale wspólna przestrzeń adresowa. To jest w zasadzie najbardziej
elastyczne rozwiązanie dzięki któremu program i dane mogą ale nie muszą
być umieszczone w fizycznie oddzielnych pamięciach włącznie z
możliwością odseparowania tylko fragmentów kodu np. procedur obsługi
przerwań. Dosyć adekwatnie przedstawia sytuację chociażby ten diagram:
http://www.eetimes.com/ContentEETimes/Images/Products/NewFolder/2010-11-30_crh_STM_Cortex_MCUs_matrix.jpg
Jak widać, oprócz tradycyjnych szyn I i D jest jeszcze szyna systemowa z
oddzielną przestrzenią adresową umożliwiającą alokację zarówno
instrukcji jak i danych (z przewagą tego drugiego - m.in połączenia z
peryferiami).
Ogólnie we współczesnych architekturach z wielowarstwowymi magistralami
oraz złożonymi hierachiami pamięci i przestrzeniami adresowymi
mapowanymi na wiele równolegle dostępnych zasobów te podziały na
Harvardy i von Neumany wg mnie powoli tracą rację bytu - trzeba patrzeć
na "pełen obrazek".
Pozdrawiam!
Portal
Artur M. Piwko
Guest
Tue May 31, 2011 6:55 am
In the darkest hour on Mon, 30 May 2011 22:21:15 -0700 (PDT),
slawek7 <sholojda@wp.pl> screamed:
Quote:
A powiesz mi jeszcze gdzie znalezc opisy (wyjasnienienia) sygnalow
zegarowych wystepujacych w STM32 i ich preskalerow.
Tylko prosze nie mowcie ze jest to w pdfach, bo pewnie tak jest.
Problem w tym, w ktorym?
Pewnie w tych od STM32. Za ciebie moze wyszukac te dane jedynie
Google... Odnosze wrazenie, ze bardziej chcesz zrobic sobie wlasnego
ARMA zamiast po prostu pisac na niego programy...
--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:226B ]
[ 08:53:51 user up 12819 days, 20:48, 1 user, load average: 0.90, 0.04, 0.64 ]
I speak Esparanto like a native. -- Spike Milligan
slawek7
Guest
Tue May 31, 2011 7:21 am
A powiesz mi jeszcze gdzie znaleźć opisy (wyjaśnienienia) sygnałów
zegarowych występujących w STM32 i ich preskalerów.
Tylko prosze nie mówcie że jest to w pdfach, bo pewnie tak jest.
Problem w tym, w którym?
Michoo
Guest
Tue May 31, 2011 7:24 am
W dniu 30.05.2011 23:44, Marcin Wasilewski pisze:
Quote:
Użytkownik "Michoo" <michoo_news@vp.pl> napisał w wiadomości
news:is128v$i0b$1@news.onet.pl...
przynajmniej korzystający z
pamięci danych (w RAM).
Dlaczego?
Elementarne. Jeśli instrukcje programu są pobierane z jednej magistrali,
w tym samym czasie na drugiej magistrali mogą być pobierane dane. W
opisywanym przypadku, gdy będziesz pobierał z SRAM dane, to nie będziesz
mógł w tym czasie pobierać instrukcji.
Tylko Cortex-M3 pracuje w pipeline:
- fetch
- decode (register fetch)
- execute (data fetch/store)
Nie znam na tyle tej architekturze, żeby stwierdzić jak wygląda
dokładnie dostęp do pamięci (zwłaszcza, że może, ale nie musi być osobna
magistrala na dane i instrukcje) - _wydaje_ mi się, że opóźnienie może
się jedynie pojawić przy dostępie zarówno kodu jak i do danych w FLASH.
SRAM jest szybki.
--
Pozdrawiam
Michoo
Portal
Guest
Tue May 31, 2011 7:30 am
slawek7 wrote:
Quote:
A powiesz mi jeszcze gdzie znaleźć opisy (wyjaśnienienia) sygnałów
zegarowych występujących w STM32 i ich preskalerów.
Tylko prosze nie mówcie że jest to w pdfach, bo pewnie tak jest.
Problem w tym, w którym?
Eh lenistwo...
Nie wiem czy odnosi się również do procka którego używasz, ale np. tu:
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/REFERENCE_MANUAL/CD00171190.pdf
od strony 123 wzwyż. Chyba bardziej dogłębne "wyjaśnienia" nie są potrzebne?
Pozdrawiam!
Portal
Zbych
Guest
Tue May 31, 2011 10:09 am
W dniu 2011-05-31 11:29, slawek7 pisze:
Quote:
Nie nazwę tego lenistwem bardziej tym że może nauczyć muszę się
szukać.
To jeszcze jedno może mi wytłumaczycie o co proszę. O co chodzi z
parametrem GPIO_speed_2MHz? lub 50MHz?
Ale tak fizyczne. Czy Zmiana na wyjściu nie jest zależna od szybkości
wykonującego sie programu?
Ten parametr wpływa na szybkość narastania/opadania sygnału na wyjściu.
Przy pojemnościowym obciążeniu i dużej częstotliwości widać ładnie
zmianę stromości zboczy.
slawek7
Guest
Tue May 31, 2011 11:29 am
Nie nazwę tego lenistwem bardziej tym że może nauczyć muszę się
szukać.
To jeszcze jedno może mi wytłumaczycie o co proszę. O co chodzi z
parametrem GPIO_speed_2MHz? lub 50MHz?
Ale tak fizyczne. Czy Zmiana na wyjściu nie jest zależna od szybkości
wykonującego sie programu?
shg
Guest
Tue May 31, 2011 5:06 pm
On May 30, 11:29 pm, Michoo <michoo_n...@vp.pl> wrote:
Quote:
Ztcw będzie się szybciej wykonywał (i z mniejszym poborem prądu) - FLASH
powyżej 24MHz musi mieć 1 a powyżej 48 - 2 wait-state. RAM - nie.
Chyba że jest tam taki myk jak w LPC. Magistrala danych flasha jest
128-bitowa i może sobie mieć nawet kilka WS, ale w jednym cyklu
dostępu pobiera więcej instrukcji i całość działa tak szybko, jakby WS
nie było, chyba że zdarzy się jakiś skok.
Zbych
Guest
Wed Jun 01, 2011 6:00 am
W dniu 2011-05-31 17:06, shg pisze:
Quote:
On May 30, 11:29 pm, Michoo<michoo_n...@vp.pl> wrote:
Ztcw będzie się szybciej wykonywał (i z mniejszym poborem prądu) - FLASH
powyżej 24MHz musi mieć 1 a powyżej 48 - 2 wait-state. RAM - nie.
Chyba że jest tam taki myk jak w LPC. Magistrala danych flasha jest
128-bitowa i może sobie mieć nawet kilka WS
W każdym Corteksie M3 tak jest. Prefetch jest częścią rdzenia, tylko
pobiera 64 bity, nie 128.
slawek7
Guest
Wed Jun 01, 2011 9:02 am
CZyli chodzi o to że tym parametrem nadzwyczjniej zwieksza się
wydajność proądową tranzystora wyjściowego w chwili przełączania. Czy
dobrze rozumiem?
Goto page Previous 1, 2