[elektro] ARM ugrás

Fri Jan 22 14:20:41 CET 2016

Én sem azt mondtam hogy kell féljetek!

De magamról tudom
hogy akadnak olyan lelkek , akiket
kezdetben összezavar a túlsok lehetőség.
Ilyenkor elég sokat hezitálok azon hogy
a lehető legjobban döntsek! ;-)
És persze (közhely) az idő pénz,
   és meetközben a tétlenség meg a tett halála..

Tehát bármely bevált séma mellett kikötve sokkal haldósabb lehet az ügy...

( Persze , annak nem is szóltam, aki nagyon szereti a
                a mindig mindenben  magábanküzdést! )

Üdv István

2016-01-22 14:08 keltezéssel, hg12345 írta:
> Szerintem meg ne félj a nagyobbtól.
>
> Ha már van uC/uP tapasztalatod, akkor teljesen mindegy milyen eszközön dolgozol.
> ((Ráadásúl az ARM mag mivel igen szimmetrikus felépítésű, inkább oktatási darab mint más eszközök)))
>
> A perifériák meg ugyan olyanok mint a más eszközökben. Ki választod mit szeretnél használni felprogramozod, és utána már úgyse látod, mert a program ezen része mindent ápol és eltakar :-)
>
> Ha tanulni kell és még nem dolgoztál ilyen környezetben, a modern eszközök belső felépítése kicsit univerzálisabb a perifériáknál:
> itt a pollingos és az IT kezelés mellé bejön az DMA és EVENT alapú kezelés. Az utóbbi akár több periféria működését is összehangolja a nélkül, hogy a uC dolgozna velük.
>
> Ha érted a periféria működését, akkor már az IT, DMA és EVENT se fog gondot okozni.
>
> Ha már az ST-t választottad, akkor a HAL minden megcsinál neked, a CUBE beállítod a perifériat, innen kezdve lesz néhány függvényed és kész. Mindenre van példa program.
>
> Amennyiben kijelzőt is szeretnél akkor a DISCOVERY panelekben szintén van $10 árkategóriában ilyen panel, de a debugger része nem leválasztható róla....
>
>
> elight <elight at gmail.hu> írta:
>> Szerintem nézd meg a Proc-ok doksiját..
>> De ha mindjárt nagyban szeretnél kezdeni ?
>> .. :-)
>>
>> KB olyasmi mint ha PIC 16 helyett PIC 24 sorozatot
>> ajánlanád indulásra kezdőknek,
>> mármint  ha a M0 és a M4 között választanál ilyentént.
>>
>> Tehár sokkal több regisztert át kell nézned az M4 -nél elsőre
>> ha mindennel tisztába szeretnél kerülni.
>> Fordítva némileg elég jól igaz: Azok a
>> dolgok amiket megismertél  következetesebben
>> találhatók meg a továbbfejlesztett
>> típusokban , mint...
>> Szóval  ahogy azt a PIC -ek esetében
>> már néhányszor ezt a problémát bepanaszoltam.
>>
>>    De ezt a hasonlítgatást talán majd
>>        a gyakorlotabbak,  szakavatottabbak részletezik nekünk.
>>
>> ( Egyébként ez a modul is ugyan olyan olcsó volt
>> mikor vettem, már talán nem gyártják
>> mert apránként úgy látom kúszik felfelé az ára. )
>>
>> Döntő érvem?
>> Én is ezek kezdtem, és értem el könnyű sikereket.
>> Könnyebben tudnék segíteni,  ha belefutsz valami
>> éppen pillanatnyilag feloldhatalanba.
>>
>> ( Ja és én laikus autodidakta perszón vagyok,
>> nem képzett programozó! Ők,
>> már többször megtapasztaltam , egy "miértnem"-el
>> és kézlegyintéssel  , meg a "nézz utána
>> olvasni tudsz" felkiáltással intézik el sokszor
>> az én belterjes kis problémáimat. ; )
>>
>> Döntő érvem , rádugod és pár lépéssel működik.
>>
>> Üdv István.
>>
>>
>> 2016-01-22 12:31 keltezéssel, Karoly Kovacs írta:
>>> Köszi!
>>>
>>> Mennyivel jobb/más ez a modul, mint a tegnap(előtt?) említett?
>>> Itt a linkje annak: http://fdh.hu/products/780370
>>>
>>> Károly
>>>
>>> elight wrote:
>>>> 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]
>> -----------------------------------------
>>           elektro[-flame|-etc]
> -----------------------------------------
>            elektro[-flame|-etc]