[elektro] Nuvoton Cortex-M0...STM32F4

[Bali Zoltan]

>Kiváncsivá tettél! Hogyan méred, mert nem olyan egyszerű szkóppal, vagy freqvenciamérővel.

Hát, irtam hogy portbillegtetéssel.
IT elején felkapcsolok egy GPIO port kinetet,
IT végén lekapcsolom. Ugynez a DMA elkezdése,
és befejezésekor, egy másik porton.
Aztán MiniLa-val nézem, trigger a két GPIO magas
szintjénél.

Közben rájöttem, hogy van ott 140ns eltérés és
ez lehet végül is az a 11 adatmozgatás, ami
ez alatt az idő alatt történik. Elvileg 48MHz-es
órajel esetén ~230ns lenne a 11 mozgatás,ha
1 órajel alatt meg tudja csinálni . Lehet mérési
pontatlanság is a 20ns-es felbontás miatt, de
teljesen ez sem magyarázza. Este átrendezem
a portokat, mert csak az alsó 4 porton tudok
2.5ns-es felbontással mérni.

Köszi

Üdv.  Zoli



----- Original Message -----
From: "hg12345" <hg12345 at freemail.hu>
To: <elektro at tesla.hu>
Sent: Sunday, November 27, 2011 11:00 PM
Subject: Re: [elektro] Nuvoton Cortex-M0...STM32F4


> Nem ismerem a Novuton megoldását.
>
> Lehet is meg nem, téma eléggé összetett, ezek sokkal összetettebbek mint egy 8 bites.
>
> pl. az általad is említett ST a kisebb F10x sorozatban, de az NXP is hasonlóan müködik, igy :
>
> A belső szervezése nem 8, 16, 32 bites, hanem 64(ST) vagy 128(NXP) bites, igy egy beolvasásra több utasításnyi kódot képes
beolvasni. Az M3 mag esetén változó az utasítás hossz, 16 vagy 32 bit lehet.
> Általában két buffert tölt fel a uC és ez bufferként 2-4 utasítás végrehajtási időt jelent.  Ezzel a megoldással 25MHz flash
eléréssel elágazás nélkül 50...75...100MHz végrehajtási sebesség érhető. A két buffer majd nem folyamatosan tartható ez a sebesség.
>
> A fenti esetben is lehetséges 1-2 utasítás késlekedés, de ilyet még nem tapasztaltam. Ha nem ilyen megoldás akkor egyértelmű a
késlekedés.
>
> A komolyabb eszközöknél, vannak programozható események melyek a beállítástól függetlenül végig csinálják az elöre beállított
szekvenciákat függetlenül a program futásától.
>
> Kiváncsivá tettél! Hogyan méred, mert nem olyan egyszerű szkóppal, vagy freqvenciamérővel. A belső timer felhasználva meg nem
lehetséges, mert az debug kommunikáció is IT-s, minden IT latency ugyan adott, de az éppen végrehajtott utasítástól is függ. A
cortex magban vannak olyan utasítások melyek nem ATOMIC szerkezetüek, igy egy utasítás feldolgozás is felfüggeszthető, de vannak
olyanok is több órajel hosszúságúak és nem felfüggeszthető, ez még kiegészul a ciklus lopással, ha benfoglalt cim vagy adat nem
érvényes (3 lépcsös feldolgozási sor). Ez még kiegészül a nop utasítás automatikus optimalizációjával, ami kikapja a sorból, de ha
sok a nop akkor kénytelen mégis végrehajtani, de idözítésre nem használható :-()
>
> Ennél sokkal hosszabb idözítéseket nem volt problémám, +-0 órajel pontossággal generálni, egy ST32F100 -on, SW + timer
felhasználásával.
>
>
>
> Bali Zoltan <eltexto at freemail.hu> írta:
> >Na, megmértem. A TIMER0  IT   19880 ns,>
> a DMA alatt pedig 20020 ns. 20ns-es felbontással.>
> >
> Akkor itt nem fogja vissza a procit a DMA ?>
> >
> Köszi>
> >
> Üdv.  Zoli>
> >
> >
> 2011. 11. 27. 19:45 keltezéssel, Bali Zoltan írta:>
> > Bocsi, rosszul fogalmaztam. Tudom, hogy HW végzi a DMA-t,>
> > a programkódra értettem, ami elindítja a DMA-t.>
> > Nálam a DMA transzfer elindítása után, csak egy várakozás van>
> > a DMA végére, aztán mehet tovább. Közben az IT-k lefutnak és>
> > ezekhez nekem be vannak rakva portbillegtetések. Az analizátoron>
> > nem láttam hogy "megnyúltak" volna az IT idők a DMA alatt.>
> > Nem erre  koncentráltam, most majd lemérem.>
> > Amit a továbbiakban írtál, nagyjából értem, ez meg is magyarázza>
> > a kérdésem.>
> >>
> > Köszi>
> >>
> > Üdv.  Zoli>
> >>
> > 2011. 11. 27. 19:16 keltezéssel, hg12345 írta:>
> >    >
> >> Bali Zoltan<eltexto at freemail.hu>   írta:>
> >>>
> >>      >
> >>> Igen, ezt az árkülönbség is takarja.>>
> >>>>
> >>>        >
> >> Mindegyiket ott érdemes használni ahol belefér az árban....>
> >>>
> >>>
> >> Ha megnézed a perifériakat akkor talán érthető, a NOVUTON elég szüken bánik a perifériákkal, a M0-M3 mag között is van
sebességben és teljesítményben különbség. (High speed USB, Ethernet, camera intrface, MMC....  +  DSP utasítás készlet)>
> >>>
> >>>
> >>      >
> >>>>
> >>>        >
> >> Vajon a 168MHz-nél a DMA alatt itt milyen>>
> >> sebességgel futhat a programkód ? Full ?>>
> >>>
> >> Ezt hogy értéd?  A DMA alatt nem fut program kód az csak egy adatmásoló HW.>
> >> A busz megosztás a nem a processor végzi, hanem a busz kontroller, ha emlékeim nem csalnak akkor 1/3 DMA és 2/3 CPU a
megosztás. Ez is csak a maximumot ad, mar a beápített 10<   feletti atmeneti pufferelhető DMA busz igénye eléggé impulzes terhelésű
lehet, az ST-ben 4 szinten állítható a DMA busz kérési igények egymás köszött.>
> >> A processor se közvetlenül éri el a FLASH-t (ha igy lenne akkor max 30MHz....) van közte az ART ami egy fajta cache külön a
program és külön a flash-ben tárolt adatok részére, ez ART osztozik a buszon a DMA-val.>
> >> Amúgy a FLASH olvasás állítható wait-tel történik és akár 7 órajel ciklus is lehet 168MHz-en,igy megkapod a várható kiolvasása
sebességet ami 25-30MHz lehet.>
> >>>
> >>      >
> >
> ----------------------------------------->
>           elektro[-flame|-etc]
>
> -----------------------------------------
>           elektro[-flame|-etc]