In the darkest hour on Mon, 30 May 2011 22:21:15 -0700 (PDT),
slawek7 <s...@w...pl> screamed:
> 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

do góry

W dniu 30.05.2011 23:44, Marcin Wasilewski pisze:
> Użytkownik "Michoo" <m...@v...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

do góry

slawek7 wrote:
> 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/T
ECHNICAL_LITERATURE/REFERENCE_MANUAL/CD00171190.pdf

od strony 123 wzwyż. Chyba bardziej dogłębne "wyjaśnienia" nie są potrzebne?

Pozdrawiam!
Portal

do góry

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?

do góry

W dniu 2011-05-31 11:29, slawek7 pisze:
> 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.

do góry

On May 30, 11:29 pm, Michoo <m...@v...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, 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.

do góry

W dniu 2011-05-31 17:06, shg pisze:
> On May 30, 11:29 pm, Michoo<m...@v...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.

do góry

CZyli chodzi o to że tym parametrem nadzwyczjniej zwieksza się
wydajność proądową tranzystora wyjściowego w chwili przełączania. Czy
dobrze rozumiem?

do góry