ARM- interrupt/event

[Tomas Dresler]

Od rekneme 72 MHz vys mame v ST nektere periferie take na mensi frekvenci
nez je jadro a pameti, od 120 MHz dokonce polovinu na 1/2 a polovinu na
1/4 HCLK. To samozrejme prinasi ne uplne deterministicke zpozdeni na
mustku AHB/APBx. APB2 je bezne rychlejsi nez APB1.

Od 24 MHz vys je samozrejme viditelny vliv WS (na F4 az 5 WS), ktere se
kompenzuji nekolika principy:

1. vetsi sirka FLASH (az 128b na slovo)
2. prefetch queue
3. ART (code + data cache)
4. Cortex-M prefetch (6 x 16bit) a Thumb-2 (16/32bit opcode)
5. branch prediction uz ve fetch fazi

Kombinace vsech principu je viditelna na F2/F4 rodine, na nizsich radach
je vynechany ART a vliv zmeny WS na vykonu je videt.

Tomas

> Ups moje chyba. HCKL jsou na taktu hodin CPU. Spletl jsem se rychlým
> pohledem na CORTEX-R4F, což je architektura která má dvě jádra ale v
> lock-stepu; to znamená že to není dvoujádrový procesor, z
> programátorského hlediska je to jednojádro, z HW, jsou HCKL systémové
> hodiny jader, od kterého se fázově posunuté hodiny pro jednotlivá jádra
> (pokud znáte, omlouvám se za zbytečné vysvětlování)
>
> Hodiny periférií běží násobně nižších frekvencí některé hodiny periférií
> jsou synchronní s HCKL jiné jsou asynchronní.
>
> Řada R je podobná řadě A, CPU hodiny běží na vyšší frekveci než
> periférie. M ková řada je zdá se více „periferně“ orientována s menší
> latencí při komunikaci s perifériemi, ovšem cenou je nižší možná
> frekvence CPU a absence cache (spíše je to výhoda a číst by se to mělo
> „nejí nutná cache“).
>
> Jestli jsem to správně pochopil, tak to STčko má takt hodin periférií
> (minimálně GIO) stejný s hodinami CPU, což je zajímavé pro latence u GIO
> periférie.
>
> Děkuji za vysvětlení. Řada M je trochu jiná než znám já z R.
>
> ced
>
>
>
> Dne 11.4.2013 23:30, Jan Waclawek napsal(a):
>>> Já ST èip neznám. Nevìdìl jsem že je možno nìjak vyvést HCLK hodiny, i
>>> nepøímo. Nebo alespoò nìjaké hodiny za bìžného provozu. Jediné co mì
>>> napadlo je mít je synchronnì s OSC. Ale to by pak nebyla øeè o 163MHz
>>> (max pracovní frekvence, tipuji),
>>
>> 168MHz u STM32F4xx. Je to momentalne asi najrychlejsi Cortex-M, co sa aj
>> naozaj da kupit.
>>
>>> protože takový krystal jde dost
>>> obtížnì sehnat :-).
>>
>> U vacsiny jednocipov zalozenych na Cortex-M3 a M4 (nielen ST) je jadro
>> dost
>> rychle na to aby ho bolo neprakticke "krmit" priamo z oscilatora, preto
>> je
>> v nich integrovany PLL v nejakej podobe - ma to byt predsa jednocip.
>> Kupodivu u casti (vacsiny?) z nich nie je mozne tak vysoke hodiny vobec
>> zvonka priviest a pouzit PLL je vlastne nevyhnutnost.
>>
>>> Nevím kolik má HCLK oproti CPU clk, tipuji polovinu
>>
>> HCLK *je* CPU clock, napr.
>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337g/BEIEFGDB.html
>>
>> Ak myslite AHB clock, ten sa konkretne u STM32F4xx je defaultne na 1:1
>> voci
>> HCLK, ale aj da vydelit, myslim ze :2, :4 a :8 (nepamatam si presne).
>> Uprimne povedane som neprisiel na dovod, preco by som ho delil -
>> teoreticky sice vplyva na spotrebu, ale nenachadzam rozumny dovod pri
>> poziadavke na nizsi vykon neist na polovicnu frekvenciu aj s CPU. Ale ta
>> delicka v kremiku stoji asi viacmenej nic, tak ju tam dali... :-)
>>
>>> a je
>>> nemožné vyvést cokoliv nad 30 MHz.
>>
>> To je samozrejme dane implementaciou pindriveru.
>> Aj u STM32F4xx je dost problem najst relevantny udaj o tom, co sa da
>> vyviest; datasheet a manual si jemne odporuju; ale ak je vsetko pravda,
>> tak datasheetove maximum je 100MHz. Mal som vyvedenych aj tych 168MHz a
>> nejako to islo, ale tam uz konci vsetka sranda aj vratane moznosti LA co
>> mam (a je samozrejme pripojeny len tak ledabolo dodavanymi drotikmi),
>> takze tie obrazky uz boli dost skarede (pulzy neboli take pekne
>> pravidelne
>> symetricke, v susednych kanaloch boli presluchy, apod.). Preto to, co je
>> zverejnene, je pri hodinach odvodenych z vnutorneho RC oscilatora, tzv.
>> HSI (High Speed Internal), cca 16MHz. Ale pri tych 168MHz funguje vsetko
>> uplne rovnako, aspon vsetko co sa tyka tych obrazkov (t.j. kde sa jedna
>> len o jadro, AHB a porty) (samozrejme programova pamat FLASH by
>> nestihala,
>> ale kedze tieto programy su len trivialne slucky, tu bez problemov
>> zafunguje kombinacia prefetch a jumpcache, t.j. ich slavny ART (TM)).
>>
>>
>>> Pak ještì píšete o mezikusu mezi procesorem a AHB, což jsem odhadl na
>>> asynchronní sbìrnici GPIO periférie,
>>
>> Nie, GPIO su u STM32 pripojene korektne cez AHB. Ten medzikus je tzv.
>> bit-banding - cast pamate (vratane tej, kde je namapovana vacsina
>> periferii) je aliasovana do inej pamatovej oblasti takym sposobom, ze
>> zmena celeho wordu v tom aliase zmeni jediny bit v povodnej pamati. Ten
>> medzikus vlastne vykonava (pre uzivatela transparentne) pri zapise
>> read-modify-write, a pri citani read-shift-mask. Zaujimavy je najma ten
>> zapis, lebo je konstrukcne zarucene, ze je atomicky, neprerusitelny;
>> inak
>> vzhladom na uz uvedeny fakt, ze sa po zberniciach tie data skutocne
>> musia
>> presuchtat, to az taky mohutny prinos nie je.
>>
>> wek
>>
>>
>> _______________________________________________
>> HW-list mailing list  -  sponsored by www.HW.cz
>> Hw-list na list.hw.cz
>> http://list.hw.cz/mailman/listinfo/hw-list
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>