[elektro] ARM ugrás

[Karoly Kovacs]

Srácok!

Úgy belemásztatok az ARM finomságokba, hogy teljesen elment a kedvem. :)

Komolyan: Ti már - úgy látom - nagyon szakik vagytok a témában, nehéz 
követni, amit írtok. Ez persze annak köszönhető, hogy e téren még igen 
zöldfülű vagyok (sőt, mind a két fülem zöld).

Károly

hg12345 wrote:
> Hi
> a probléma nagyon egyszerű, csak egy kicsit komplikáltan fogalmaztam,
>
> a legtöbb FLASH elérési sebesség 25-30MHz efelett már wait-ek kellenek a hozzáféréshez (kivéve valamelyik japán gyártóé, ahol ez a sebesség 60MHz). Amikor folyamatosan fut a program egy ennél nagyobb sebességű uC-ben akkor hiába nagy a kontroller sebessége a program lépésre várakozás lassítja az utasítás végrehajtását. Mivel az ARM load/store felépítésű eszköz, azok az utasítások amik a uC "kinyúlnak" mér több óra ciklust igényelnek, ilyen esetekben az a sebesség csökkenés nem lenne jelentős, de a belső utasítás végrehajtásoknál már igen.
> Ennek áthidalására találták, ki hogy szélesebb FLASH eléréssel és két soros bufferen keresztül olvassák a memóriát. Így ez a megfogás szinte észrevehetetlen tehető.  A FLASH általában (64)128 bites vagyis egyszerre 4db 32 bites vagy 8db 16 bites utasítást olvas soronként bufferbe. A két buffer esetén az a duplája.... Így elenyésző sebesség csökkenéssel lehet a programot futtatni.  Persze minél nagyobb a különbség a uC és FLASH között annál nagyobb lehet a sebesség csökkenés, azoknál a programoknál ahol ez problémát okozhat, közvetlenül csatolt memóriában (RAM) lehet a programot tölteni és innen futtatni, ez a memória csak töredéke szokott lenni az eszközben találhatónak.
> Szerintem egy 8 bites rendszerből fellépő alkalmazásnak ilyenre sohase lehet szükség :-()
>
> Az alkalmazásra több lehetőséged van,
> - elvei erre a címterületre fordítod a programot és induláskor feltöltőd,
> - olyan programot írsz ami memória független futású
> - ha a rendszer tartalmaz MMU akkor bármely fizikai memória részhez akármilyen címet tudsz rendelni, így ha tudod, hogy a programod milyen címterületre lett fordítva az MMU-val alá rendeled a címeket.
>
> De a legjobban akkor jársz, ha veszel egy CORTEX  M7 ami már 1...4K memória CACHE rendelkezik, és emiatt szinte mindegy milyen területen található az éppen futó program
>
>
>
>
> Moravcsik Szilard <levlista.mszilard at gmail.com> írta:
>> Szia!
>>
>> Azt írod:
>>
>> "...mivel mindegyik csak RAM-ból képes közvetlen és teljes sebességű
>> utasítás végrehajtásra..."
>>
>> Ezek szerint ha teljes sebességű utasítás végrehajtást szeretnék, akkor
>> valahogy a lefordított és flash-ben (vagy valami háttér táron) tárolt
>> bináris kódot a RAM-ba kell másolni a boot során?
>>
>> De a belső RAM azért ehhez sokszor nem elegendő kapacitású.
>> Ilyenkor teszel rá valamilyen külső RAM-ot és bootoláskor oda másolod a
>> kódot majd valahogy onnan indítod az utasítás végrehajtást (ez a címbeli
>> ARM ugrás :DDD)? Vagy hogy is van ez? :)
>>
>> Egyelőre csak a kíváncsiság miatt kérdezem, mert látom, hogy nálam
>> sokkal többet tudsz az ARM-okról. Szóval ha majd lesz időd... :)
>>
>> Üdv:
>> Szilárd
>>
>> 2016.01.22. 8:54 keltezéssel, hg12345 írta:
>>> Hi,
>>> igen, de LINKER nélkül egyik se működik, közvetlen memóriába fordítású asm-ról nem tudok.
>>> Minden C fordítónak  GCC és a KEIL-s van önálló ASM fordítója.
>>>
>>> Ha kicsit összetettebb programot szeretnél írni, akkor inkább használj C-t!
>>>
>>> Biztos lehet tömörebb és gyorsabb kódot írni közvetlen programozással, de apró pénzért kapsz nagyobb memóriájú eszközt és hasonlóan gyorsabbat is. De a legtöbb ilyen uC 48Mhz-ről indul...
>>> Ha nagyon sebességre hajtasz, akkor itt ez nem olyan egyszerű. mert ugyan az az utasítás címzéstől függően 1...6 óraciklus alatt mehet végbe, arról nem is beszélve, hogy mivel mindegyik csak RAM-ból képes közvetlen és teljes sebességű utasítás végrehajtásra, FLASH-ből csak bufferen keresztül, ezért amire számítasz az akár lassabban is történhet, és még a DMA miatt busz hozzáférés megosztás miatt futási sebesség változásról nem is beszéltünk.
>>> Maga az ASM és az gépi kódú utasítások is elég összetettek, és nem homogének, a THUMB utasítás készlet hasonlóan a legtöbb 8 biteshez, két operandusos, míg a normál és THUMB32 bites utasítások 3 operandusossak, a legtöbb operandust még lehet indexelni, és post vagy pre-incrementálni, az növelés csökkentés szinkronban van a hozzáférés szélességével... A blokkos beolvasás és töltésnél regiszterenként lehet állítani, hogy melyik regiszterre legyen érvénye "16 univerziálisból" persze ebből 3 foglalt. A teljes méretű konstans megadás nem létezik (32bites), ezt általában PC relatív címzéssel olvassák be, a program részletek között tárolják.
>>>
>>> Szóval érdemes a C felé kacsingatni, sokkal gördülékenyebben lehet vele dolgozni.
>>>
>>> A CORTEX magokat úgy hirdetik, hogy nem kell hozzá ASM betét, és ez tényleg igaz!
>>>
>>>
>>>
>>>
>>> VFX <info at vfx.hu> írta:
>>>> Hali!
>>>>
>>>>
>>>> Engem meg az érdekelne, hogy ARM-re létezik-e önálló assembly fordító?
>>>> Van-e olyan, hogy nem kell egy halom valamit feltelepíteni csak 1 vagy 2
>>>> db exe és fordul is, hasonlóan, mint avr-hez az avrasm2.exe
>>>>
>>>> ÜDV. VFX.
>>>>
>>>>
>>>> 2016.01.21. 11:40 keltezéssel, elight írta:
>>>>> Sziasztok...
>>>>>
>>>>> Nemrég írtátok , hogy előbb utóbb megugranátok
>>>>> az arm felé.
>>>>>
>>>>
>>>> -----------------------------------------
>>>>            elektro[-flame|-etc]
>>>>
>>>
>>> -----------------------------------------
>>>             elektro[-flame|-etc]
>>>
>>
>>
>> ---
>> A levél vírus, és rosszindulatú kód mentes, mert az avast! Antivirus védelme ellenőrizte azt.
>> https://www.avast.com/antivirus
>>
>> -----------------------------------------
>>           elektro[-flame|-etc]
>>
>
> -----------------------------------------
>            elektro[-flame|-etc]
>