[elektro] ARM ugrás

Pataki István pataki.istvan at freemail.hu
Sun Jan 24 01:42:23 CET 2016 

Vajon mennyire megbízható egy ilyen kütyü egy felhasználónak átadott 
készülékben?
pi


----- Original Message ----- 
From: "fi F" <flaist at gmail.com>
To: <elektro at tesla.hu>
Sent: Sunday, January 24, 2016 12:40 AM
Subject: Re: [elektro] ARM ugrás


> Szia!
>
> http://hu.farnell.com/stmicroelectronics/stm32f746g-disco/dev-brd-stm32f746ng-cortex-m7/dp/2480961
>
> Nézem ezt a demó board-ot, nagyon brutál, az ár / tudás arány.
> ~100-as szériánál  meg sem lehet közelíteni, saját gyártással.
> Eddig PIC32MZ-t használtunk, de drágább a saját gyártású, kisebb 
> tudású HW-ünk.
> Most akartunk PIC32MZ-re átállni, de ha ezt kapni pár évig, akkor nem 
> érdemes.
>
> Milyen környezet kell, hogy fejleszteni lehessen rá?
>
>
> FI.
>
> -----Original Message-----
> From: elektro-bounces at tesla.hu [mailto:elektro-bounces at tesla.hu] On 
> Behalf Of elight
> Sent: Friday, January 22, 2016 12:26 PM
> To: elektro at tesla.hu
> Subject: Re: [elektro] ARM ugrás
>
> Ne tedd.
> ( mármint félre azt a kedvedet : )
>
> Helyette szerintem első lépésben,
> úgy ismerkedésileg töltsd le:
> http://www.mikroe.com/mikroc/arm/
>
> ingyenest, kezdetben elég lesz ez is
> azután mehetsz tovább más IDE-k,
> libraryk felé.
>
> Szerezz modnjuk egy kicsi discoveri modult:
> http://www.aliexpress.com/store/product/STM32VLDISCOVERY-STM32F100RB-STM32F100-STM32-Evaluation-Development-Board-Discovery-Kit-Embedded-ST-Link/216233_699394601.html
>
>
> Telepíts egy ST-link utilitit hozzá.
> Én a proc leírását is átfutottam előtte, annyira , hogy képbe kerüljek 
> kicsit.
>
> És már minimum szinten készülhet
> a tanuló programod.
> Tápot USB-ről kapja, csak kapcsolót , ledeket vagy displayt kell 
> hozzákötnöd esetleg.
>
> De ha szükséges küldhetek mintát,
> amelyik a protokat birizgálja,
> és alap dolgok vannak benne
> ( ja és hibátlanul elsőre betölthető,
> nem kell hozzá egyéb library
> meg bármi bűvészkedés. )
>
>
> Üdv István
>
> 2016-01-22 11:44 keltezéssel, Karoly Kovacs írta:
>> 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]
>>>
>> -----------------------------------------
>>            elektro[-flame|-etc]
>
> -----------------------------------------
>          elektro[-flame|-etc]
>
> -----------------------------------------
>          elektro[-flame|-etc]

More information about the Elektro mailing list