ARM- interrupt/event

Pátek Duben 12 01:02:18 CEST 2013

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
>