[elektro] STM32f4 interrupt : volatile tombok

Pal Lukacs ekegep at yahoo.com
Tue Dec 10 13:25:36 CET 2013


Sziasztok !

HW float szamolja a dolgokat. Ellenorizve, mukodik az FPU.

Nem 12 bit, 24 ADC, 16 DAC :)
Kimertem a szures idotartamat. ~25ms

Ha igy szamolok, hogy 1/48kHz (mintaveteli freki) = ~20us, ez szorozva 1536-al (ennyi a tomb merete) ez kb 32ms. Ebben benne van az is hogy az IT-k kozben hozzak be az adatot, tehat beleszakitanak a szuresbe.
Tehat amig megtelik a masik puffer, addig megtortenik a szures is, es meg ido is marad.

A szuro algoritmusoknak tomb cime van megadva. (CMSIS DSP library)

Kerdes:
Van-e hatranya sebesseg szemontjabol annak, hogy a tomb(ok) (left/right) es a hozza tartozo indexek, meg allapotok strukturaban vannak tarolva ?
A valtozo deklaralasoknal pedig volatile-t az elotag.

Tehat: volatile struct adc_buf adc_buf_inst1, adc_buf_inst2;
Igy remelem az egesz valtozo a strukturan belul volatile lesz?

Udv.
Szabi




On Tuesday, December 10, 2013 1:06 PM, hg12345 <hg12345 at freemail.hu> wrote:
 
Hi,

az STM32 eleve 32bites (int) rendszer egy beolvasás és egy kiírás 32 biten történik.
Ha a lebegö pontos változódat real ként definiáltad, akkor az méretre azonos egy int-tel vagyis ezen nem múlok a sebesség. Ha double ként annak a megfelelő long long  ez 2x32bit tárolódik.
A pointer (index) számításban lehet különbség, mert több belső ciklust használ el a címzésre, ez elérésben is különbség van, mert két beolvasás (kiírás) kell, de ezt is lehet optimalizálni, ha engedélyezed a blokkos ki és beolvasást, akkor kevesebb utasítás lehívás lesz.

Milyen sebességgel veszed a mintákat, képtelenségnek tartom, hogy STM34F4xx uC egy ~40Khz 12bites adatfolyam kiüsse :-(

A tömböt érték vagy pointerként adod át ? :-)




Pal Lukacs <ekegep at yahoo.com> írta:
>Sziasztok !
>
>Lehet hogy hulye kerdes,...a float adat elerese memoriaban tobb ido mint az int elerese?
>
>Mert en az adat behozas utan egybol konvertalom (int to float) es ugy irom, olvasom a memoriaba (memoriabol).
>
>
>Udv.
>Szabi
>
>
>
>
>
>
>On Sunday, December 8, 2013 12:12 PM, Pal Lukacs <ekegep at yahoo.com> wrote:
> 
>Hi!
>
>Vegulis mindegy milyen hosszu a tomb, ha egy adatot meg tud szurni addig amig jon a masik, akkor barmekkora hosszu tombot meg tud szurni, amig megtelik a masik puffer.
>Itt csak azert kellett tomb, mertdecimalni , interpolalni kell, es nem mindegy hogy mekkora hosszu az adatsor. 
>
>
>
>On Sunday, December 8, 2013 11:04 AM, hg12345 <hg12345 at freemail.hu> wrote:
> 
>Hi
>sokkal jobb a ping-pong buffer 
>1, DMA-val is kezelhető,
>2, 1.5K nem memória foglalás 
>3, a szűrő algoritmus gyári megírt és csak a pointert kell átadni :-)
>
>De szerintem célszerű lenne 3 fix méretű tömböt lefoglalni a heap-en vagy fixeni, és
> ezeket a tömböket cirkulárisan használni... Gondolom a tömb mérete határozza meg a hang késleltetését... A tömb méretét akkorára kell választani, hogy a szűrés tudjon vele végezni míg az következő szűrendő mennyiség  beérkezik. (ez a szűk kapacitás, de ha növeli a felhasznált tömbök számát, ez ezen nem tud segíteni, csak a verseny helyzet esetén később fog adatot veszíteni, a folyamatos késlekedés növekedés mellett)
>
>egyiket tölti a DMA
>másokban számol a szürő
>harmadikat kiküldi a DMA
>
>
>"Móczik Gábor" <pm_levlista at progzmaster.hu> írta:
>>2013.12.07. 18:41 keltezéssel, Arnold Fuzesi írta:
>>> Lehet cserelgetni a
> buffer kezdocimet is, ugy gyors. Csak a kettos buffereles memoriazabalo, cirkular buffer jobb kihasznalast ad.
>>
>>Na jó, de jelen esetben mit érsz el buffer cím cserélgetéssel?
>>
>>Ugyanaz, mintha circular lenne, csak még egy plusz pointert cserélgetsz 
>>az rd/wr-en kívül, valamint jobban "kvantált" az anyag, csak diszkrét 
>>buffernyi darabokban férsz hozzá, a circ. bufferben meg tetszőleges 
>>hosszban, folyamatosan akár.
>>
>>Doublebuffer olyan esetben lehet jó, amikor nincs annyira ráhatás a 
>>kiolvasó folyamatra, pl. képernyőn megjelenítés. Ha nem a video drivert 
>>írod, hanem valami magasabb szintű rétegben vagy, nem tudod mikor fog 
>>kelleni a kijelzőnek egy adott sornyi pixel, jobb ha egyben odaadod
> az 
>>egész képtartalmat, aztán majd kiírja amikor akarja, te meg a háttérben 
>>összeállítod a következő képet.
>>
>>-----------------------------------------
>>          elektro[-flame|-etc]
>>
>
>-----------------------------------------
>          elektro[-flame|-etc]
>-----------------------------------------
>          elektro[-flame|-etc]

-----------------------------------------
          elektro[-flame|-etc]


More information about the Elektro mailing list