[elektro] AVR IRQ -> ARM

[hg12345]

Hi,

Igen nehezen fogod "megnyuvasztani" uC, hogy a 5-7% teljesítmény vesztés észrevehető legyen.
De ha ilyet akarsz csinálni, pl: egymástól 39byte távolságra tegyél le 16 ugró utasítást amivel körbe ugrálsz, majd a minden körbe ugrás után számolj. Ez a kód kiüti FLASH buffert, így észrevehető lesz a sebesség csökkenés. De kisebb lesz a csökkenés mint gondolod, mert az egy JMP utasítás minimum 3 vagy 4 óra ciklus, így 2WS esetén még a végrehajtás előtt újra tudja tölteni a prefetch feldolgozót.

minden memóriából futtatható a kód :-), de mint írtam a közvetlen csatolású memória pl. ez a 4K-RAM ezen nem osztozik mással az AHB buszon keresztül. Vagyis ha valami nagyon időérzékeny futást igényel azt innen lehet futtatni. De a többi RAM-ból is futtatható a kód, de ha nem tetszik akkor a memória cím elrendezés változtatható (MMU)....

Azért a helyzet nem ennyire rossz, erre van a legkisebb szükséged, mert a DMA, ill. a perifériák összeköthetőek eseményekkel, ha jó szervezed ezeket, akkor a legtöbb müvelet automatikusan felügyelet nélkül lefuthat, a uC csak az eredménnyel kell foglalkoznia.

Érdemes tudni, hogy egy ARM-s eszköznek hol van a határa, de ez a határ nem annyira éles mint 8/16 bites eszközöknél. Amennyiben egy adott feladat határos a periféria szám vagy esetleg teljesítmény, akkor tervezésnél kell arra ügyelni, hogy legyen tovább lépési lehetőséged.  1xx -> 33x -> 46x... pici lábkompatibilitási eltérés, de annál kellemetlenebb, ha a panel nincs felkészítve. Árban biztos 2x alatt marad a különbség..
 

Ha már keretek... Szerintem sokkal inkább fontosabb mindenki számára a SYSTEM IT megértése és kezelése, mert ebben igen más mint egy 8/16 bites uC, itt ha valami nem tökéletes a belső HW-rel, akkor könnyen ezekre az IT-re tudsz ráfutni, arról nem is beszélve, hogy egy az áramkört immunitását meghaladó elektromos zaj is ide ugrasztja a programot. Az utóbbi nagyon kellemetlen.... ez jelzés és legtöbbször a programba nem tudsz visszatérni, szerencsére jól megtervezett HW esetén ilyen nincs..

Sokan vannak akik nem szeretik a debuggert, persze lehet így is ellenőrizni, de a debuggeren keresztűl minden változó és regiszter  (memória terület) kiolvasható átírható, tud korlátos sztatisztikát csinálni a hol tartózkodik a program, törés pont feltételes töréspont, és érték WATCH  stb, és nagyon sok listázó lehetőséget biztosít.... Ez mind mind HW-ből a belső beépített debuggerrel, a "DEBUGGER" csak a fejlesztő számítógép kapcsolatot biztosítja.




VFX <info at vfx.hu> írta:
>Hali!
>
>
>2016.02.29. 12:54 keltezéssel, hg12345 írta:
>> HI,
>>
>> Nem tudom mennyire kell nagy teljesítmény számodra, hogy a FLASH WAIT-ket kell figyelni, de ha már erre is vigyázo,l akkor sok esetben azt is figyelembe kell venni, hogy a AHB buszon sok minden dolgozhat egyszerre ráadásul úgy hogy azonos prioritással rendelkeznek az egyik ilyen ha nem a legfontosabb a DMA,
>> 1/3, 2/5 -ben osztozhat a AHB-n és ez is befolyásolhatja a konkurens hozzáférést FLASH/RAM/PERIFÉRIA halmazhoz.
>> Ha nagyon cikis a végrehajtás a közvetlen csatolású RAM-ból kell futtatni a programot, azt hiszem ilyen létezik a 3xx sorozatban! Ez esetben semmi nem akasztja meg a program futását.
>>
>> Teljesítmény vagy időzítés problémád van?
>
>Egyik sem. Most ismerkedem az ARM-mal és szeretném itt az elején 
>kifigyelni mit tud, mielőtt döntök, hogy melyik platform legyen a 
>befutó. Szóval inkább nyúvasztás íze van a dolognak. Kihajtani a keretek 
>szélére, hogy lássam hogyan viselkedik.
>
>STM32F334-ben van 4k RAM amiből futtatható kód.
>
>
>> A legolcsóbb HW debugger a ST-nál a NUCLEO minden kivitelben kapható, a debugger rész letörhető, és telje értékú minden ST-hez. FDH Kft Bp az asztalodra teszi ~3K-ért.
>>
>Igen, itt van az asztalon 2db is, de egyenlőre nem sikerült jól 
>használni a  debuggerét (konkrétan sehogy). Igaz sok időt nem is 
>fordítottam még rá.
>
>ÜDV. VFX.
>
>-----------------------------------------
>          elektro[-flame|-etc]