A memória limitekkel volt gond reggel. Az FFT méretét 128-ra le kellett vinnem, akkor a sima 10Hz jó lett. Azóta is ok, ha nem keverem a jelet.



Ha 2-vel megszorzom akkor a binek is elmásznak, de legalább valami értelmet adnak.
A csatolt fájlban látszik.

Ha nem szorzom, akkor elkúsznak a binek.

Itt valami gond lesz a frakcionálásnál szerintem. A tömböket így foglaltam le:

Eddig azt hittem jó...

A teszteléshez így állítom elő a jelet. Persze kicsit fura, de ha 128 mintát veszek akkor az dt=1/128 lesz, így elvileg kijön az elméleti jel, amit már megmutattam, hogy 10Hz-re ok.

Az ok, de mi a cos tag benne??

Csak teszteléshez, hogy mi történne ha...

Az exccelben ugyanerre a jelre jó eredményt kapok, ezt elrontja. Gondolom valós eredményekre is fennálna ez. Főleg, ha azok 3.3 lehetnek maximum. Most lefuttattam erre is:



Szóval arra az esetre, ha a jel amplitúdója egynél nagyobb. Az eredmény nem jó. Tuti valami skálázási probléma van. Szerintem nem jó DSP.h fájlt használok, vagy rosszul.
Ha nem próbálom ki, akkor erre a hibára fel sem figyelek, mert lefut minden gond nélkül, de az redmény hibás lesz és nem tudtam volna hol a ahiba a későbbi feldolgozásokkor.

Idézet a H fileból: /* float value in range [-1, 1) */
Az érték 1....-1 közé kell essen! Annál nem lehet nagyobb!

Igen ez igaz, de 0.1-nél csak 0 a végeredmény. 0.5-nél van valami esetleg, de csak akkor, ha két jel összege van, aminek összege 2 is lehet. Sima szinusznál az sincs. A fractcionálás miatt szerintem igen szűk a tartomány, amiben lehetnek az értékek. Valamit olvastam ebben, de még nem értem:

http://ww1.microchip.com/downloads/en/DeviceDoc/70157B.pdf

Az Angolom sem az igazi.

A tört számábrázolás csak egy sok közül, ahogy számokat lehet ábrázolni! Ez ugyanúgy 16 bites érték, az átalakítás után is! Ott van a h fileban a képlet, ahogyan Q15-ös formára alakítja át a float-ot:

Ezért kell, hogy +-1 tartományon belül maradjon a bemeneti érték, máskülönben túlcsordul a 16 bit!

Nagyon elfáradtam, nem értem pontosan. Sok fórumot olvasok, valaki a barrel shift-ről beszél a dspic33f esetében, de nem értem. Amit küldtél láttam, de nem értem pontosan. Ha biztosítom, hogy a bemenet minden esetben -1/1 között legyen, mégpedig úgy, hogy 0.1 szorzom mielőtt a Float2Frac-ot hívnám meg, majd az fft, akkor minden fft eredmény 0.

Azért írtam, hogy valami nem ok, mert nekem 32 bites a float számom. Ezt tudja a dsp.h-ban ez a függvény? Ha igen, akkor nem értem miért nem megy rendesen. Van ennek a PIC-nek 40bites accuja is, meg ilyesmik a OCCON regiszterében.

bit 4 ACCSAT: Accumulator Saturation Mode Select bit
1 = 9.31 saturation (super saturation)
0 = 1.31 saturation (normal saturation)
bit 3 IPL3: CPU Interrupt Priority Level Status bit 3(2)
1 = CPU interrupt priority level is greater than 7
0 = CPU interrupt priority level is 7 or less
bit 2 PSV: Program Space Visibility in Data Space Enable bit
1 = Program space visible in data space
0 = Program space not visible in data space
bit 1 RND: Rounding Mode Select bit
1 = Biased (conventional) rounding enabled
0 = Unbiased (convergent) rounding enabled
bit 0 IF: Integer or Fractional Multiplier Mode Select bit
1 = Integer mode enabled for DSP multiply ops
0 = Fractional mode enabled for DSP multiply ops

az IF-t nézem, de már teljesen összezavarodtam, nem értek semmit. Hogyan módosítsam a kódomat, vagy a dsp.h fájlt, hogy működjön? Pl: sin(x*t+fi0)+sin(2x*t+fi1) lenne a bemenet, aminek az ampiltúdója esetelg elérheti a 2-t. No ha megszorzom 0.5-el nem fog menni.

Ha tudtok segítsetek légyszi, mert totál kétségbe vagyok esve. Két napja ülök rajta, részereményeim vannak csak.

Talán itt jobban megérted, mi is az a fix pontos törtszám ábrázolás, és a konverzió, oda-vissza...

Egy biztos, akárhány sin jelet akarsz egyszerre legenerálni, az összegük nem lehet nagyobb +-1-nél! Tehát a végén el kell osztani annyival, hogy ez teljesüljön! Máskülönben, ahogy írtam, túlcsordulás lesz belőle...

Nézd meg, hogy konverzió után milyen értékek kapsz vissza a Jel tömbben?! Ha ott nem azok vannak, amiket a konverzió után kell kapnod, akkor baj van a konverziónál! Ha az megfelelő, akkor valahol utána lesz a gond....

A konkrét könyvtár használatához én sokkal többet nem tudok hozzátenni, lévén sohasem használtam még! De volt itt legalább 1 kolléga korábban, aki már sikeresen használta, emlékeim szerint. Talán őt kellene megkeresned a konkrét könyvtárhasználattal kapcsolatban..., én csak az elméleti részén tudok segíteni...

Ettől kezdve olvasd el..., hátha segít valamelyest...

Elolvastam, sokat segített, köszönöm!

Átalakítottam a kódomat, de még nem jó sajnos. A srác kódjai nálam nem mennek pontosan, de sok hibát kijavítottam vele.

-Ami működik + tapasztalatok:
1: A nyers adatokat float tömbben kell tárolni.
2: Utána normálni kell, hogy -0.5 és 0.5 közé essen, de úgy, hogy a lehető legjobban megközelítse azokat. Sima 0.1x szorzás ilyesmi nem játszik.
3. Miután a normálás megtörtént át kell adni a fractcomplex formátumú jel tömb real partjának.
4. Twiddle faktor. (megcsináltam excelben, kijönnek az eredmények szépen!, ha -sin() t használok)
5. FFTComplexIP
6. BitReverseComplex

Nálam a hiba szerintem az FFTComplexIP-nél, vagy már a memória foglalásnál kezdődik. Ha másképpen foglalom a memóriát, akkor változnak az eredmények is. Proteusban csak DSPIC33FJ32MC202-t tudok szimulálni, de nekem itthon DSPIC33FJ128MC202-m van, de nem tudom egyelőre az FFT-t futtatni rajta, bár azt kellene inkább már szerintem...

A memória foglalások:

N=128


ez 6.5N komplex szám, ha jól látom. A komplexek float-ok, azaz 13*4=52 x 128=6656 byte, ha a tömbök 128 méretűek.
De szerintem már itt nem ok, azaz a memória foglalásban is hiba lesz....

Így használom a többi függvényt:
A jel már fractcomplex, és a normált jel értéke Float2Fract-al át van adva neki.
log2N=7; mert 128 elemű a tömb



Ötletek? Lehet már valós helyzetben kellene futtatnom, de a memória foglalás még aggasztkicsit.

Egszerűen nem igaz. Egyetlen példa sincs, ami VALÓBAN működne. Egy sem, nem értem. Pakoltam mindenhova az adatokat a memóriában, próbáltam a sima FFT-t, de nem. Semmi. Így ez elég nagy baj, nem fogom fel, hogy SEHOL nincs egy nyomi példa ami működne. Az FFTcomplexIP-ben AKÁRMIT teszek, szinte ugyanaz az eredmény. Egyszerűen nem értem, és igen fáradt vagyok fáj a fejem, a szemem, mindenem. Kipróbáltam más libbel, dsp.h-val, MPLAB IDE 6.0-val is az 5. akármennyi után, de semmi. Totális kudarc ez az egész.

Itt elintézik ennyivel:

https://www.microchip.com/forums/m863356.aspx

Nem pontos annyira, de jobb eredmények, mint az enyém. Három sor... Ráadásul lehet nem is normálja....

Lehetséges, hogy az UART, vagy más interrupja okoz gondot? Vagy a bitreverzálás nem jó? Mplab ide 5.35 és C16. Lehet bug? Vagy ennyire nem látom mi a hiba?

Nálam ez totál nem megy:



Error:
Main.c: In function 'main':
Main.c:205:107: error: Argument to __builtin_psvpage() is not the address
of an object in a code, psv, or eedata section;
the object must not be qualified with any form of index
Main.c:205:67: error: Argument to __builtin_psvoffset() is not the address
of an object in a code, psv, or eedata section;
the object must not be qualified with any form of index

Nem jól hívom meg az FFTcomplexIP-t?

Az FFT végül megy, de nem egszerű.

Sajnos rossz helyre tettem fel a dsPIC33FJ SPI gondokat. Vélertlenül az Arduino-ba.
Az eredmények SPI-n:

Üdv Mesterek!

Megjött az analizátor. Nem volt egyszerű életre keltenem, sokszor már azt hittem tönkre tettem, de nem, még megy.

Az SPI-vel kapcsolatban (Arduino-n is van! ):

Az eddigi legjobb eredményemet a csatolt képen láthatjátok. Sajnos NAGYON nem ok az egész! A kód t1 interruptban 100Hz-enként írna és olvasna a RAM-ba. Szimulációban minden fényes. Szóval a képen az órajel nem jó. Az elején igen rossz, a 3. byte -nál szedi össze magát. A kód úgy működik, hogy mikor az SPI-re ír, az először engedélyezve van, /CS láb lehúz, majd írás, utána SPI nincs engedélyezve. Kipróbáltam úgy is, hogy az engedélyt elsőnek megadtam, soha nem állítottam le, de nem lett jó. Bár most belegondolva azért is lehet, mert 1x elfelejtettem az analizátor GND-t csatlakoztatni. Lehet épp akkor... Az eredmény olyan, mintha az órajel nem szedné össze magát időben. Az utolsó byte-ra kijön a 320KHz, amit beállítottam. Fcy/(64*2) Fcy=39936000.(utasítás frekvencia) Ez legalább jó. A képen a MOSI vonal teljesen halott. A másik probléma az, hogy a képen mintha olvasni szeretne. Kimenne az instrukció (ha jó lenne), majd a 16 bit cím. Node írni is kellene neki, minden másodiknál, de az meg sem jelenik. Annak instrukció (8 bit), cím (16 bit) + 8 bit adat-nak kellene lennie, szenben a képen láthatóval, innen gondolom, hogy az írás egyáltalán nem jó.

Komoly gondok vannak itt úgylátom, de majd ránézek holnapután, mert ma Whisky-van. Elég sokat lehet kínlódni egy ilyennel, de az analizátor eddig sokat segített. Az Enable láb jó, néha az óra is, a többi kuka. Legalábbis edig.
Ha van valakinek tapasztalata/ötlete szívesen fogadom!
Köszi!

Belefutottam egy jelenségbe, aminél kissé tanácstalan lettem...
Adott egy készülék, DsPic-el. Jól működik alapvetően, elég bonyolult feladatokat lát el. Nem sokkal ezelőtt jelezték vissza nekem, hogy egy bizonyos üzemmódban, véletlenszerűen újraindul a cucc, minden előjel nélkül!
Elkezdtem tesztelgetni..., elő is tudom idézni ezt az újraindulást, de nem egy egzakt eseményhez kötve, hanem csak időben valamennyire behatárolva.
Megnéztem, az RCON regiszter mit ad vissza, ott azt láttam, hogy az IOPUWR bit be van állva. Viszont, tegnap kipróbáltam, hogy megfogjam a reset előtti pillanatban, az _AddressError, _HardTrapError, _StackError, _MathError, _SoftTrapError megszakításokkal, de be sem lép ezekbe, úgy tűnik(De itt nem vagyok biztos abban, hogy ezek jól működtek e, vagy valamit még engedélyeznem kellett volna...)!

Jelenleg az egyetlen ötletem az, hogy megpróbálok egy érték szerinti megszakítást beállítani a programszámláló regiszterre, hogy ha az reset vector címet kap, akkor álljon meg. Talán így lenne esélyem megnézni a változóimat, vagy egyéb hardver regisztereket...

Most, hogy ezt írtam, jutott eszembe, hogy elvileg azt is megtehetem, hogy reset után a lehető leghamarabb törésponttal megállítom a programot, és ott még szintén ki tudom olvasni legalább a változóim tartalmát..., nyilván a hardver regiszterek törlődnek, de legalább a saját adataimban tudnék keresni valami rendellenességet...

Szóval teljesen megfoghatatlannak tűnik per pillanat ez a hiba, még nem volt hasonlóval dolgom, nem sok ötletem van hogy kellene ezt elkapni?! Van valakinek bevált ötlete ilyen esetre?

Hát én ezzel kezdeném (mármint a meggyőződéssel arról, hogy ezeket elkapod).

Flash piszkálás bootloader, ilyesmi van?
Mi egyszer futottunk bele olyanba (32MX-el igaz), hogy flash programozás nem volt jó (maradtak ki címek ahol 0xFFFF maradt). A 0xFFFF az invalid opcode szerencsére PIC32-nél így egyből jött az illegal opcode signal amit szépen kivillogott.

Minden (is) van..., de ezek elvileg akkor, amikor elmegy resetbe, egyáltalán nem piszkálódnak! A bootloader itt amúgy is egy külön project, most a fejlesztési módban egyáltalán nincs is jelen.

Azt látom még, hogy az INTCON1 regiszter is tele van status flag-ekkel, mindenféle hibákra vonatkozóan. Ezt is ki kell majd íratnom...

Ha a _AddressError, _HardTrapError, _StackError, _MathError, _SoftTrapError megszakításokon keresztül történne az újraindulás, akkor a #TRAPR bit lenne beállítódva és nem a #IOPUWR, mivel ezek a hibák un. trap megszakítások.
Mivel a #IOPUWR bit van beállítódva, ami illegal opcode vagy illegal address mode miatt történik, ezért én inkább arra tippelnék, hogy valami adatterületnek használt címre fut rá a program. Nincs a program memóriában valami adattáblád eltárolva, vagy valami szöveg, stb.?

Az INTCON1 reset esetén törlődik, de ez a trap megszakítások státuszát tárolja. Ha a program a reset előtt nem fut bele a _AddressError, _HardTrapError, _StackError, _MathError, _SoftTrapError megszakításokba, akkor ebben a regiszterben sem fog egyik bit sem beállítódni.

Ez hol derül ki? Én nem találtam erre vonatkozóan egyértelmű infót....
Adatlapi táblázat szerint az RCON-t is törlődőnek gondolnám, pedig az nem olyan!


A program memória tele van tárolt szövegekkel, amiket folyamatosan megjelenít a TFT kijelzőn! De nem hinném, hogy itt lenne valami, hisz ezeket használom más üzemmódoknál is, ahol pedig nem jelentkezik ez a hiba.

Pedig egyértelműen le van írva: lásd 1. csatolmány.
Ez ugyan egy PIC24 adatlapból van, de gondolom az általad használt dsPIC adatlapban is benne van.
RCON esetén is látszik, hogy reset esetén mi lesz az egyes bitek értéke: lásd 2. csatolmány.

Nem a szöveggel van a baj, hanem, hogy rákerülhet a program futása. Másképp nehéz elképzelni a #IOPUWR bit jelzését, mert nem gondolnám, hogy a fordító illegális utasítást, vagy nem megengedett címzési módot fordítana.

Egyáltalán nem egyértelmű ez a táblázat alapján! Ugyanis ott határozott értékek vannak megadva, fixen! Abból egyáltalán nem következik az, hogy reset után megtartaná az értékét ez a regiszter!
A helyes ábrázolás, amiből táblázat esetén lehetne következtetni, ha pont hogy X-el jelölnék a bitek állását, reset után, mert az azt jelentené, hogy valaminek a függvényében lehet 0 vagy 1 is!

Nade...hogyan kerülhetne oda a program futása? Én nem ugrálgatok a programban mutató alapján, ahol ilyen veszély fennállhatna..., mutatókat szerintem kizárólag adatok eléréséhez használok, az meg elvileg nem módosíthatja a program futását... Szerinted hogyan tudna olyan címre ugrani, ami nem a fordító által határozott meg?!

Ennél egyértelműbben nem tudom, hogy lehetne leírni.
Nem megtartja reset után, hanem a reset folyamatnak ez egyik része, hogy beállítódik.
Megtörténik a reset esemény > a CPU beállítja a megfelelő regiszterek értékét > a CPU a 0. címről végrehajtja az utasításokat (és ezután már nem íródik felül, ha csak te direkt nem írod át, azaz megmarad).
De én itt nem foglak győzködni arról, hogy hogyan működik a mikrokontrollerben a CPU. Leírtam, hogy hol találod meg, ha szerinted ez így nem jó, akkor írj a microchipnek, sok millió embernek elegendő ami oda le van írva.


Elég sok módon lehet. Pl. valamelyik rutinba nincsennek párba a PUSH és POP utasítások, és RETURN-nál rossz címre lép vissza, vagy használsz BRA Wx utasítást és rossz cím van a regiszterben, vagy egy rossz adatcímzés miatt a W15 regiszer felülíródik, stb.
De ahogy látom te mindent jobban tudsz, még az adatlapnál is jobban, így majd biztos kitalálod.

Már vártam ezt a te mindent jobban tudsz szofisztikált beszólást! ) Szerintem nem beszólogatni kéne, hanem érvelni határozottan..., vagy ha az nem megy, akkor ne állítsd be úgy, mintha birtokában lennél az információnak!

Lehet hogy én tudom rosszul, de..., az összes hardver regiszter határozott bit értéket vesz fel reset után(kivételt ez alól speciális regiszterek élveznek). Tehát ha úgy működne, ahogy szerinted, akkor nem tudhatnánk, mi történt reset előtt?! Márpedig pont ez a célja annak a regiszternek, hogy megtudjuk a reset-et kiváltó okokat(amennyiben az lehetséges ennyiből)
Amiről te beszélsz, az a RAM működése! Az valóban nem íródik felül reset esetén, azonban a hardver regiszterek igen! Ezt mutatja az ominózus táblázat, hogy a gyártó szerint reset után milyen határozott értékeket kell felvennie a regiszternek!


Persze, nyilván szándékosan ezer és egy féleképpen elő lehet idézni..., de én arról beszéltem, hogy ha semmi ilyet nem használsz a programban, akkor ugyan hogy állhatna ilyen elő?! Félrefordít a fordító? Mondjuk...nem lehetetlen éppen...
Pl már az is érdekes, hogy úgy tűnik, már akkor sem jelentkezik a hiba, ha semmit nem változtatok a kódon, csak ugyanazt a fordítást debug módban futtatom a procin! Újra ilyenkor nincs fordulva a kód, azt látom, de nem tudom a hardveres debug regisztereken kívül érint e még valami mást is, ha így van futtatva?!

Ha neked nem elég érv, hogy leírtam a tényeket, amelyek benne vannak a specifikációkban, akkor nem tudom mit lehetne még érvként felhozni.
Látom az értő olvasás nem nagyon megy. Pont ezt írtam le korábban:

Ezzel kapcsolatban tettem be képeket, mert ez szerinted nincs leírva sehol. Attól, hogy te nem tudod elhinni ami a specifikációban le van írva (bár az is tele van hibával, de ez speciál pont jó), attól az még úgy van.
De ahelyett, hogy utánaolvasnál, esetleg letesztelnéd, leállsz okoskodni, hogy szerinted nem úgy van.
És ezek után még segítséget vársz?

Én kérek elnézést, hogy mindentudó, és megasszondom személyed állításait meg merem kérdőjelezni! Tudod, más is ért itt egy két dologhoz, nem csak te! Csak jobbik esetben, nem teszünk úgy mintha mi sz...tuk volna a spanyolviaszt, és csak mi tudjuk a tényeket! Te ezzel szemben nem érvelsz, de így viselkedsz! Így is lehet hozzáállni, csak akkor ne csodálkozz, ha kétkedve fogadják a "szakértelmedet"!
Én is érthetően írtam le, hogyan működnek ezek a regiszterek, ha nem érted, akkor emésztgesd még kicsit, egyszer csak összejön neked is
Nem hinném, hogy személy szerint téged céloztalak meg a kérdéssel! A te döntésed volt, hogy érdemi segítség helyett inkább személyeskedés irányába vitted a dolgot, ahelyett hogy tanulnál! Mert hogy senki sem tud mindent...esetleg szemmel láthatóan talán te..., de mi halandók nem ) Én ezt tudom, és ennek megfelelően amiben nem vagyok biztos, nem adom elő úgy, hogy közben lehülyézek másokat. Ennyi a különbség...

Nem az én állításaimat kérdőjelezed meg, hanem ami a specifikációban le van írva.


Ezt nem tudom miből vontad le. Segíteni akartam és leírtam, hogy amit keresel az hol van. Ha te ezt az infót nem tudod elfogadni, az nem az én problémám.


Én leírtam mi van a speckóban, de SZERINTED az nem úgy van. Akkor most ki az aki nem érvelt?


Haha, végtelen vicces vagy. Te nem vagy hajlandó utánaovasni, vagy kipróbálni, amit írtam, ha már nem hiszed el, ami a specifikációban le van írva, és és nem tanulok? Nem, én segítettem neked, de neked nem tetszett a válasz, mert szerinted az nem úgy van.


Én sem tudok mindent (sőt nagyon keveset tudok), de nem is látom, hogy írtam volna ilyet. Viszont a kérdésedre a választ igen, tudom. Az. hogy te a tényeket kétkedve fogadod, arról én nem tehetek.


Hol hülyéztelek le? De hogy nehéz eset vagy, az biztos.

De én itt befejeztem, segítsen neked ezen után más. Leglább már látják mások is, hogy ha valaki segítséget akar adni neked, akkor mit kap vissza.

Vajon, azon túl, hogy a magad elképzelt verzióját szajkózod itt, te megtetted ugyanazokat, amiket szerinted én nem?! Mert ha igen, akkor talán értenéd, hol van az ellentmondás a te verziód és a valóság(?) között!! Amennyire látom, van egy fixa ideád, ahogyan véled értelmezni az adatlap állításait, és a tényeket ezzel szemben nem vagy hajlandó elvben sem értelmezni.

Nade...ez csak egy mellékszál az eredeti problémához nem sok köze van! Így nem is értem, ezzel hogy is akartál segíteni?! Hiszen azóta is jutottam pár új infóhoz, amit itt le is írtam, de arra bezzeg 0 reagálás volt..., pedig engem az érdekelne, nem egy - jelen esetben eléggé - lényegtelen aspektus, bárkinek is légyen itt igaza!


Arra mérget vehetsz!! Főleg az érvelni gyengén tudók akadnak ki seperc tőlem... De, ez az ő bajuk... A te segítséged, és "jóakaratod" leginkább téged járatott le csupán.

Nem túl uras és nem túl okos dolog egymást szidni szakmai vita és érvelés helyett.

Javasoljuk, hogy a vitát emeljétek a minimum elvárható színvonalra és használjatok érveket a személyeskedés helyett. Segíteni fog megoldani minden nézeteltérést.

Köszönjük!

Nekem amikor nagyon woodoo volt a PIC működése, akkor azt tranziensek okozták.
Szóval érdemes a lehetséges hardware okokkal is foglalkozni.