ARM- interrupt/event

Andrej Jancura aj.hwlist na gmail.com
Pátek Duben 12 10:28:36 CEST 2013


Dobry den,

dakujem za trochu osvetlenia problematiky. Priznam sa, ze ked som to zacal
hlbsie citat, tak som akosi intuitivne pochopil z textu, ze problem je v
tom, ze raz ten bit set trva 10 cyklov a raz 15... A snazenie nasho experta
je zistit, kedy je to 10 a kedy 15. To som fakt netusil, zeby na 160MHz
toto mohlo niekoho zaujimat. A uplne absurdne je to v pripade
bit-bandingovej I2C na pinoch portu, ktora bezi na 100kHz resp. 400kHz...
To len hrana medzi log. urovnami je niekolko instrukcii procesora.

No nic ludia su rozny, a kazdy je uleteny nejako inac.

A.

Dňa 12. apríl 2013 1:02, Tomas Dresler <dresler na hw.cz> napísal(-a):

> Hezky receno :-) Hromadu tech detailu lze zjistit tak, ze se na veskerou
> dokumentaci ARMu a ST rozprostre ucici algoritmus, ktery da dokromady
> vsechny podminky a definice a neco vyplivne.
>
> Vec se ma tak, ze tak slozity stroj uz je nepopsatelny mimo vyrobni
> dokumentaci. Proto se pro analyzu pouziva simulace na urovni RTL pro FPGA,
> kde lze nasimulovat log. analyzator v libovolnem bode toho designu.
>
> Treba prave latence AHB/APB zalezi na tom, kdy o transfer dat pozadate.
> Pokud je delici pomer frekvenci 1/4, APB prebere data ve 4. pulzu hodin
> AHB, ale procesor je muze vystavit v 1., 2., 3. nebo 4. taktu, takze
> latence je 1-4 takty. Je to deterministicke, ale na urovni programu
> nevite, jak jste synchronizovani.
>
> Dtto zapis na nikoli defaultni pamet skrz AHB pridava jeden takt, takze
> pokud pouzivate RAM s DMA (asynchronni k jadru), pokud byla pouzita jadrem
> v predchozim taktu, je tam 0 WS, ale pokud byla "prepnuta" k DMA, trva
> prepnuti k jadru 1 WS. A takovych podminek je tam stovky.
>
> T.
>
> > Dobry vecer,
> >
> > nechcem sa do tohoto vlakna moc rypat, pretoze ak mam pravdu povedat, len
> > velmi matne tusim o co ide v tomto vlakne. Ked som to dobre pochopil,
> > problem je v rychlosti nastavovania nejakych bitov na porte pripojenom na
> > jadre Cortexu.
> >
> > Osobne si myslim, ze tieto veci nie su z pohladu praktickeho designu
> > relevantne, pretoze ak chcete pocitat cykly medzi bit set a bit reset,
> tak
> > na 168MHz je asi vhodnejsie pouzit FPGA nez tu STM32F4. Druha vec je to,
> > preco je to tak. Povedal by som ze to ma background v emc a aj
> > potencionalnej identifikacii systemu. Aj ked si myslim, ze to jadro ma
> tak
> > 30 rokov, predsa len pouzivaju sa uz dost vysoke pracovne frekvencie a
> > riesit tuto problematiku nie je jednoducha vec ani v dnesnej dobe. Osobne
> > si  myslim, ze sa tam pouziva viacero netrivialnych technik
> ovplyvnujucich
> > filozofiu celkoveho navrhu toho procesora cez obvodove riesenia az po
> > rozne
> > vychytavky v layoute. Jednoducho povedane, dali vam 168MHz a dan za to
> je,
> > ze nevidite do vsetkych detailov. Bud s tym dokazete zit, alebo ich
> > nepouzivajte.
> >
> > A.
> >
> >
> > Dňa 11. apríl 2013 12:56, milger <milger na pobox.sk> napísal(-a):
> >
> >> Zda sa, ze tipy mi nevysli...
> >> Kazdopadne rad sa dozviem odpoved ak niekto "zamachruje" rozumnym
> >> vysvetlenim.
> >>
> >> Milan
> >>
> >>
> >>
> >> On 11. 4. 2013 10:37, Jan Waclawek wrote:
> >>
> >>> K odhaleniu tychto veci mal sluzit dnesny ranny prispevok. Ale este
> >>> stale
> >>> som z toho jelen.
> >>>
> >>> Skusil som   while(1) {
> >>>      __SEV();
> >>>
> >>>      GPIOA->BSRRL = (1 SHL 2);
> >>>      __SEV();
> >>>      GPIOA->ODR = ~(1 SHL 2);
> >>>      __SEV();
> >>>      GPIOA->BSRRL = (1 SHL 2);
> >>>      __SEV();
> >>>      GPIOA->ODR = ~(1 SHL 2);
> >>>      __SEV();
> >>>      GPIOA->BSRRL = (1 SHL 2);
> >>>      __SEV();
> >>>      GPIOA->ODR = ~(1 SHL 2);
> >>>
> >>>      __SEV();
> >>>      __SEV();
> >>>      __SEV();
> >>>      __SEV();
> >>>      __SEV();
> >>>      __SEV();
> >>>
> >>>      GPIOA->BSRRH = (1 SHL 2);
> >>>      __SEV();
> >>>      GPIOA->ODR = 1 SHL 2;
> >>>      __SEV();
> >>>      GPIOA->BSRRH = (1 SHL 2);
> >>>      __SEV();
> >>>      GPIOA->ODR = 1 SHL 2;
> >>>      __SEV();
> >>>      GPIOA->BSRRH = (1 SHL 2);
> >>>      __SEV();
> >>>      GPIOA->ODR = 1 SHL 2;
> >>>
> >>>      __NOP();
> >>>      __NOP();
> >>>      __NOP();
> >>>      __NOP();
> >>>      __NOP();
> >>>      __NOP();
> >>>    }
> >>>
> >>>
> >>> http://www.efton.sk/STM32/r3.**png <http://www.efton.sk/STM32/r3.png>
> >>>
> >>>
> >>> wek
> >>>
> >>>
> >>> ----- Original Message ---------------
> >>>
> >>>> To je hodne poucne, len ma napadlo ci by bol rovnaky vysledok aj pri
> >>>> impuze opacnej polarity, t.j. najskor "0" potom "1"?
> >>>> Take male percento na objasnenie tejto zahady by som tipol na rozne
> >>>> riesenu logiku pre SET a RESET. V tom zmysle ze oneskorenie je rozne.
> >>>> A dalsie male percento na vysvetlenie typu "ak zmena sa tyka rovnakej
> >>>> logiky(bitov) ako naposledy, usetrime jeden takt na oneskoreni lebo
> >>>> nemusime nieco robit". To by sa asi dalo tak isto otestovat.
> >>>>
> >>>>
> >>>> Milan
> >>>>
> >>>> On 10. 4. 2013 15:21, Jan Waclawek wrote:
> >>>>
> >>>>> SEV je vykonana okamzite, takze potrebujete-li nejak zobrazit
> >>>>>> casovou vzdalenost mezi dvema udalostmi, SEV reaguje rychleji (ale
> >>>>>> trva 1
> >>>>>> HCLK!) nez zapis na port.
> >>>>>>
> >>>>> Tak som si to vyskusal.
> >>>>>
> >>>>> http://www.efton.sk/STM32/r.**png <http://www.efton.sk/STM32/r.png>
> >>>>> http://www.efton.sk/STM32/r.c
> >>>>>
> >>>>> Hore su tie dva SEV, v strede su tie dva zapisy na port (jeden do
> >>>>> nastavovacieho registra, druhy do nulovacieho, t.j. BSRRL/BSRRH),
> >>>>> dole
> >>>>> su
> >>>>> hodiny (HCLK).
> >>>>>
> >>>>> Ten posun zapisu na port voci tym SEV, a najma vzajomny posun tych
> >>>>> dvoch
> >>>>> zapisov na port - zapisy su od seba vzdialene minimalne 2 clocky
> >>>>> vdaka
> >>>>> tomu SEV vlozenemu medzi nimi, ale pulz je dlhy len 1 clock - to
> >>>>> vsetko
> >>>>> je
> >>>>> poucne.
> >>>>>
> >>>>> wek
> >>>>>
> >>>>>  ______________________________**_________________
> >>> HW-list mailing list  -  sponsored by www.HW.cz
> >>> Hw-list na list.hw.cz
> >>> http://list.hw.cz/mailman/**listinfo/hw-list<
> 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<
> 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
> >
>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20130412/6deb0f3e/attachment-0001.htm>


Další informace o konferenci Hw-list