ARM- interrupt/event

Pátek Duben 12 01:07:51 CEST 2013

Sice nevím co myslíte C-kódem (načítání z FLASH?).

Asi jsem to nepochopil správně. Těch 42 instrukcí je doba trvání SRT pro 
GIO operace (nastavení jednoho bitu). Dá se to zkrátit nastavením 
způsobu přístupu do paměti v MPU, ale za cenu toho, že po skončení 
instrukce na výstupu ještě nebude zapsaná hodnota, ta se tam objeví 
později. A asi  příliš nepomohu bezprostřední další změnou, protože se 
zápis musí dokončit. Ještě jsem to netestoval, není bohužel čas.

Jen mě překvapilo, že je R4 a M3(4) je stejná architektura ARM v-7 ale 
co se týče GIO periferií je velký rozdíl. Pochopil bych to pro A řadu na 
GHz, ale pro M4 na 168MHz a R4 na 160(180) je tam řádový rozdíl. Vím, že 
R architektura má podle powerpointových prospektů blíže A řadě. Princip 
komunikace musí být jiný a já bohužel neznám rozdíly (prakticky je 
důležitý výsledek, jen by mě to zajímalo :-)

Řadu R jsem viděl na frekvencích  i ke 400MHz, tím je to asi dané.
No nic, zajímavá informace.

ced

Dne 12.4.2013 00:30, Tomas Dresler napsal(a):
> C-M3 a C-M4. R-ka neznam a nemame je.
>
> Otazka je, odkud merite a zda pocitate instrukce nebo C-kod. C-kod je
> obecne mnohem delsi kvuli nutnosti cist konstanty z FLASH - pak kod trpi
> na hromadu WS. Asm to muze vyrazne ptimalizovat, ale kdo to bude psat, ze
> jo :-)
>
> Tomas
>
>
>> Tohle platí pro jaké cortexy? M4? Možná spíše tohle platí pro jaký čip?
>> Mě to zní jako pohádka. Proč? protože mě blbé nastavení GIO bitu trvá 42
>> CPU intrukcí. CORTEX-R4.
>>
>> ced
>>
>>
>> Dne 10.4.2013 19:38, Tomas Dresler napsal(a):
>>> Instrukce STR [adresa], registr trva v jadre 1 CLK. Pokud je volny Write
>>> buffer na interni sbernici jadra, zapise se a jadro pokracuje dal. Pokud
>>> ovsem obsahuje predchozi zapisovou opraci, musite si pockat na uvolneni.
>>>
>>> AHB je transakcni, takze si ten zapis prebere sama. Problem je s IO
>>> porty,
>>> pokud jsou umistene na APB. Pak zpozdeni kvuli resynchronizaci mezi
>>> frekvencemi AHB a APB si vezme az (1+pomer hodin), tj. 3 az 5 cyklu.
>>>
>>> Pokud je GPIO port primo na AHB sbernici (novejsi procesory),trva
>>> transakcena AHB dalsi hodinovy takt a tim je to vyrizeno (tj. 2 takty od
>>> vykonani instrukce STR).
>>>
>>> Nyni zpet k prikladu s GPIO. Bit-banding je velmi ucinny pro praci s
>>> RAM,
>>> pro praci s porty se nehodi (zvlast ne pro zapis). Proc? BB musi vykonat
>>> read-modify-write na urovni vnitrni sbernice jadra (nikoli AHB, ale tu
>>> pouzije 2x), takze precte ODR, zmeni a zapise zpet, tj.4-5 cyklu v
>>> idealnim pripade. AHB je behem teto transakce zamknuta a jadro to
>>> zapisem
>>> do write bufferu ukoncilo, takze operace je atomicka, ale cas na
>>> sbernici
>>> si vezme... Navic meni jediny bit.
>>>
>>> To je duvod, proc STM32 nabizi v GPIO registry BSRR a BRR, ktere
>>> umoznuji
>>> jedinym zapisem zmenit hodnotu libovolneho poctu bitu. Cela operace si
>>> vezme 2 takty a hotovo, zadne R-M-W cykly navic.
>>>
>>> Tomas
>>>
>>>
>>>
>>>> Nie.
>>>>
>>>> Tie zapisy su buffrovane na rozhrani procesor/AHB, t.j. sa do portu
>>>> nezapisu okamzite (a je mozne, ze su nejako buffrovane aj v samotnom
>>>> GPIO
>>>> module, kedze sposobuju v skutocnosti read-modify-write na skutocnom
>>>> vystupnom buffri).
>>>>
>>>> Detaily sa bohuzial nemate sancu dozvediet. Toto je jedna z dani za to,
>>>> ze
>>>> tie 32-bitove jednocipy nie su mikrokontrolery (t.j. jednoliaty obvod
>>>> navrhnuty na riadiace ucely) ale SoC (zlepenec procesoroveho jadra,
>>>> pamati, periferii a roznych medzikusov) (aj ked sa vyrobcovia zurivo
>>>> snazia, aby terminologia na tento rozdiel nepoukazovala).
>>>>
>>>> wek
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message ---------------
>>>>
>>>> Subject: Re: ARM- interrupt/event
>>>>      From: Jan Smrz<jan.smrz na email.cz>
>>>>      Date: Wed, 10 Apr 2013 15:34:35 +0200
>>>>        To: HW-news<hw-list na list.hw.cz>
>>>>
>>>>> Jak je mozne, ze vystup rizen registrem je dlouhy jen jeden clock?
>>>>> Jadro
>>>>> umi
>>>>> paralelni zpracovani vice instrukci?
>>>>>
>>>>> J.S.
>>>>>
>>>>>
>>>>> On 04/10/2013 03:21 PM, 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.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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list