STM32F4, latence/rezie preruseni

[Josef Štengl]

Ahoj,

Cortex-R4 má AXI (jako u Cortex-A) sběrnici. A všechno jí trošku trvá 
(AXI je 64-bitová sběrnice. A nejhorší na tom je, že ať přenášíte 16 
nebo 64 bit, tak to trvá stejně dlouho, nejméně na EMIF na kterém je 
FIFO bufer FPGA pověšený na 16-bit EMIF a přenáší se 
word-pauza-pauza-pauza-word-…. Možná že se mi to jen nepodařilo správně 
zkonfigurovat. Beru veškerý podněty).

Doba od vzniku ISR události do vyvolání přerušení je 16 HCLK (CPU) + 2 
VCLK takty. - někdy nutno připočítat ke zpoždění obsluhy.

Chip má FPU a je zapnuta.


Hmm nemáte někdo tušení co znamená P10 a P11? Jen co mám hledat. Zatím 
jsem se trochu seznámil jen s P15. Dle instrukce STC nějaký koprocesor? 
FPU? Hmm. Zajímavé… .

ISR vstup:

STMFD         R13!, {R0-R3, R12, R14}
MRC           P10, #0x7, R12, C8, C0, #0x0
STMFD         R13!, {R12}
MRC           P10, #0x7, R12, C1, C0, #0x0
STMFD         R13!, {R12}
STC           P11, C0, [R13, #-0xFFFFFFC0]!
SUB           R13, R13, #0x10


ISR: výstup
STMFD         R13!, {R0-R3, R12, R14}
MRC           P10, #0x7, R12, C8, C0, #0x0
STMFD         R13!, {R12}
MRC           P10, #0x7, R12, C1, C0, #0x0
STMFD         R13!, {R12}
STC           P11, C0, [R13, #-0xFFFFFFC0]!
SUB           R13, R13, #0x10

Což mě trochu vyděsilo. Používám ARM mód, zejména kvůli registrům. Mám 
lokální funkce plné lokálních proměnných a ono mi to používalo jen R12 
a A registry!.

Tak jsem jsem zapnul optimalizaci a už to používá celou sadu :-). 
Vypnutý jsem to měl kvůli ladění, hraji si s vlastním schedulerem a je 
jednodušší hledat chybu tam kde jsem ji napsal, a ne tam kde se 
přeložila :-)

No zase jsem se zase rozkecal. K věci.

ISR vstup: (O2)
STMFD         R13!, {R0-R10, R12, R14}
MRC           P10, #0x7, R12, C8, C0, #0x0
STMFD         R13!, {R12}
MRC           P10, #0x7, R12, C1, C0, #0x0
STMFD         R13!, {R12}
STC           P11, C0, [R13, #-0xFFFFFFC0]!
SUB           R13, R13, #0x4

ISR Výstup (O2)
ADD           R13, R13, #0x4
LDC           P11, C0, [R13], #0x40
LDMFD         R13!, {R12}
MCR           P10, #0x7, R12, C1, C0, #0x0
LDMFD         R13!, {R12}
MCR           P10, #0x7, R12, C8, C0, #0x0
LDMFD         R13!, {R0-R10, R12, R14}
SUBS          PC, R14, #0x4

Takže po zapnutí optimalizace to ukládá skoro všechny registry. Jak tak 
koukám, dle obsahu funkce. Jiný isr zůstal původní, je jam jen podmínka 
a volání funkce. Vypadá to, že se to inteligentně rozšiřuje dle 
použitých registrů resp. počtu lokálních proměnných.

R11 se neuložil (nevím proč, nebyl potřeba?),

R13 (SP) ne, protože je daný CPU modem a R15 také ne, protože je to PC a 
ten není k čemu ukládat a návratová adresa je v R14(LR). To R16 jste se 
upsal nebo vážně existuje?

Kompilátor TI tms470 V5.0.3.

Zajímalo by mě, které stavové wordy to ukládá. Cortex-M nemá bankované 
registy CSPR, SP a LR pro přerušení?
…nemá. Nebo jsem je nenašel. A ty registry se jmenují zřejmě CCS a SCS, 
ať je už cokoliv. Hmm…

ced


+++

Mimochodem pokud váháte a jedna z možností na výběr je TI tak nebrat. HW 
hezký, ale ovladače to je utrpení. Snažil jsem se je použít, ale musel 
jsem si je napsat znovu. A jejich Placený SW má už rok stejnou chybu, 
která je potřetí odstraněna a zase simulátor dekóduje instrukce ve 
špatné endianitě.
	Ale abych jen nenadával, tak to vypadá, že jejich poslední Beta verze 
Code composer studio mi už neshazuje grafický server.


Dne 16.4.2013 20:35, Jan Waclawek napsal(a):
> Pri vstupe do prerusenia sa ukladaju na zasobnik registre R0-R3 a R12-R16 (t.j. aj SP, PC, LR) a este dva stavove wordy, a trva to 10 cyklov vratane fetchu prvej instrukcie prerusenia (vsetko za predpokladu nulovych waitstatov). Je to z pohladu pouzitelnosti dost vela, najma ak je clovek zvyknuty riesit realtime veci v preruseni, ale jednak , a tiez vzhladom na dohody o tom, kto kedy ake registre uklada (tzv. ABI), toto zabezpecuje to, ze v preruseni moze byt pouzita akakolvek funkcia, nie je nutne ju prekladacu nijako specialne oznacovat. Ta latencia je samozrejme dlhsia tiez o trvanie neprerusitelnych instrukcii v prerusovanej urovni, sice ARM velkoryso pise ze to je vzdy len jeden cyklus (a su tam fakt vychytavky ako prerusitelne a po ukonceni preruesnia restartovae delenie ktore inak trva dlhsie), ale ked sa clovek zacita do celeho toho stroja, nuz tak to nemusi byt (a v drvivej vacsine pripadov veru ani nie je) len ten jeden cyklus... Plus samozrejme nasledky z "pomalo
 st
>   i" FLASH, co je na dalsie dlhe rozpravanie.
>
> Co sa tyka FP registrov u Cortex-M4, tie sa pri defaultnom nastaveni neukladaju, len ak sa v preruseni pouzije FP operacia. Toto sa vola lazy stacking a je k tomu appnote ktory vrelo doporucujem precitat.
>
> Pri odchode z prerusenia to iste v opacnom smere, ak nenastalo ine prerusenie atd.atd.atd. Takze minimalne prerusenie bez akehokolvek tela trva 20 cyklov.
>
> Pan kolega Stengl by nam pre pobavenie mohol pripadne prezradit, kolko to trva u tych Cortex-R; pocitam ze to bude tiez dost dramaticky rozdiel vzhladom na to ze u Cortex-M ARM machruje s "extremely low latency interrupt"... ;-)
>
> Opakujem sa, ale je to tak - toto vsetko je dan za to ze to nie je mikrokontroler ale SoC. Ako aj pisete, pre realtime treba preferovat pracu s hardwarom, robit realtime softwarom je vyrazne tazsie ako u mikrokontrolerov. Je to fajn az do okamihu, ked toho hardwaru sa zacne nedostavat - proste to nie je tak flexibilne ako ked sa clovek nauci poriadne programovat mikreokontrolery.
>
> wek
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list