Elvileg jó lenne ilyesmi is, de ezeket nem tudom úgy összerakni, hogy a nagyfrekvenciás SPI vonalak jók legyenek, illetve nem minden mikrokontroller tud igen magas frekijű SPI-t. Az SPI-n ki kell küldeni pl. 8 bit adatot, előtte lábak fel/le huzogatása majd a lábakat fel/le húzni megint. Ilyen magas szinusz frekin már pl 256 ezerszer kell ezt megcsinálni, hogy 1KHz szinusz menjen ki. Ok, 32 pontban ismerve csak 32 ezer lesz. De gondoljunk bele, mekkora SPI freki kell ehhez. 8xennyi minimum. 10KHz szinusznál 32*10 000*8 = 2.56MHz SPI freki. Ami nem sok, de 40-nél már 10MHz, amit nem midegyik tud. Főleg úgy nem, hogy az SPI frekvenciájának minimum a 2x kell legyen a saját óra frekvencia. Esetleg ezt ESP, PIC tudja, de ismétlem, olyan szép antennákat hajtogatok, hogy nem megy el a jel... Legalábbis nekem nem, de dolgozok majd ilyenen is mégegyszer. Szóval szimuláltam ilyet is, ment is, de a valóságban elakadtam az SPI jelek továbbításakor. Néztem direkt címzéső DAC-ot, az gyorsabb lenne, mert az input 8 bitet a lábakról egyszerre kapja meg. Ez ok, de lassabb mint a létra, mert még kell pár láb le/fel húzás, mire az input lábakon lévő 8 bitből megtörténik a konvertálás. De azok a legjobbak, de elsőnek ezt próbálom ki. A létra megadta volna az adott mcu elvi maximumát, mert mikor a loop-ban rögtön írok a portra a memóriából kiolvasott értékkel, és növelek egy indexet, akkor megkapom az elvi maximum szinusz frekit amit elő tudok állítani.

Viszont gyanítom, hogy az ESP jobb lesz az SPI-ben, de még nem adom fel...
Van itthon SPI-DAC, majd rákötöm az ESP-re azt is.
Szóval:
-ESP létra mínuszos...
-Most összedobom a DAC példa kódot amit kaptam icserny kollégától, ha jól tippelek fejből.
-SPI DAC ESP-re.

Oszt meglátjuk melyik tud itthoni remegő kezekkel, vaksin összetákolt körökkel a legtöbbet.

Kicsit később, kb 1-2 óra múlva küldöm az ESP beépített DAC példára a szkóp képet.

Milyen gyakran kell frissíteni a szinuszjel frekvenciáját, vagy amplitúdóját?

Ez egy chirp jel lesz majd, szóval elég sűrűn. Nem lesz pontos jelalak, mert olyan kis időközönként nem lehet váltani, de jó lesz az is. Majd korreláláskor azt veszem alapul, nem a tisztán matematikai alakot.
Szóval sűrűn, de azt is csak akkor, mikor a freki váltás értéke egész számú lesz. Ezt csak 1x szimuláltam, jónak mondható, de nem keresem most meg a kódot, hogy végül mit találtam ki erre. Az increment a lényege, szóval kell még azt is figyelni az interrupt-on belül. De PIC-en már van ilyenem szerencsére.

Ajaj..

Ez a kód fut, remélem jó, de már fáradt vagyok, elnézhettem.



Az eredmény a csatolt képen látszik.
Ha 256 pontban ismerjük az 1 periódust, akkor ha 150Hz a kapott szinusz, akkor a mintavételi freki maximum 150*256= 38400Hz

Ennél az Arduino a létrán gyorsabb volt szrintem.

Azért a helyedben én megnézném azt, hogy ugyan mi is van abban a dacWrite függvényben. Csak mert gyanús, hogy a keretrendszer beállít valami alapértelmezett frissítési frekvenciát pl. egy timer-el (jelen esetben 38400Hz-et), és minden függvényhívásnál várakozik amíg a DA konverterre nem teheti az aktuális értéket.

Ok, megpróbálom, de fáradt vagyok nagyon. Nem tudod hol van ez fejből?
Nekem is gyanús ez, de azért gondoljunk bele, hogy a létra alkalmazásakor csak a port írás sebessége és a néhány increment növelés és memóriából kapott érték kell. Az igen gyors lehet.

Megnéztem. Időzítő az nincs benne, de más időhúzó dolog az rendesen van benne:

Ez ugye minden alkalommal meghívja a pinMode függvényt, amiben ez van:


Ezek után ne csodálkozz hogy ilyen lassú.

Köszönöm!

Akkor neked sincs ötleted, hogyan lehetne növelni ezt?

Itteni kérdéseim alapján vettem az ESP-t, ami amúgy tök jó, de ezek szerint:

- Port írás létrára: kapufa (bár össze tudnék rakni bipoláris tranzisztorokbol kapcsolókat.)
- Beéptett DAC: úgy néz ki kapufa
- Koszinusz generátor piszkálása: Még lehetséges. (Chirp kell, szóval...)
- SPI DAC meghajtása ami a csövön kifér: Még össze kell drótoznom egy példát. Szerintem holnap azt is kipróbálom!

Köszi MINDENKINEK aki segített, holnap jelentkezem ismét!

Ebből gyerekjáték felgyorsítani:
- bemásolod a __dacWrite függvényt a saját programodba
- átnevezed mondjuk mydacWrite-ra
- kitörlöd a felesleget
- a setupba egyszer meghívod az eredeti változatot, hogy a lábakat beállítsa analógra
- a loop-ban pedig a mydacWrite-ot hivogatod

Miert nem probalod ki peldaul LEDekkel, hogy a megfelelo kimeneteket kapcsolja e, vagy, hogy kapcsolja-e egyaltalan a program ahelyett, hogy itt kerdezoskodsz, hogy mi nem jo. Hibat keresni nem tudunk helyetted. Maximum ha feltoltom a sajat ESP-mre es megcsinalom helyetted (amire nincs idom). Egybol kiderulne, hogy portbeallitas, vagy portszamozas, vagy mas gond van.

Mert van multimétrem azért. Leírtam azt is, hogy mi okozza problémát, azon már túlvagyunk és nincs megfelelő megoldás. Olvass vissza. És nem szoftver hiba.

Valamint azt is leírtam, hogy szimuáltam is, mégpedig Ledekkel. Hát ezért.

Valamint, ha megnézed, már régen más megoldásokat tesztelünk, amik szintén problémásak, de megoldom és nem teszek fel képeket, kódokat, mert nehogy valaki aki később idejön tanulhasson a dologból. Vagy a hibáimból.

Mi a bajod mnyugger? Miért szóltad le? Már tényleg teljesen mást csinálunk. Nekem nyugodtan be lehet?

Amúgy pedig DAC-al max 338Hz-et lehet kicsikarni. Az API-val meg amit kimértem. Le is írják.
Eddig nem a legjobb, de még kipróbálom az SPI-t.

Bocsánat. Rossz helyre nyomtam.

Kerdesem arduino alatt mivel irtad a portot ?
Arduinos fuggvennyel (digitalwrite) logikai H L vagy direkt a port regiszter DDRx es PORTx vezerlesevel.
A ketto port irasi mod kozott 1.5 dekadnyi sebesseg kulonbseg van.
A digitalwrite() jocskan elhuzza az idot a direkt port irashoz kepest.
Jo tudom az ardus atmel kornyezetet csak teszt uzemben vegezted el , de melyik modszerrel?
Lehet ezt is irtad mar fentebb akkor csak nem derult ki szamomra.

Milyen frekire kell a chirp szeruseg?
Si5351 I^2C portos 8kHz ~ 160MHz futo 3 portos PLL ic nem lenne jo?
Mar eleve a vivofrekit chirp-elne persze akkora sebeseggel ami a I2C porton kifer 400kHz orajel mellett.
Esetleg lesd meg a uSDR radios projektet.
Abban atmega324 "telefonsavszelesseggel" 3 4 kHz jelet pakol at(modulal) nagyfrekire modulaciot.
Ott direkt hajtjak a pll ict es + 1 kimeno digit porton pwm jellel a kimeno amplitudot is a kivant uzemmodnak megfeleloen rangatjak. Opensource githubon N+1 utanepitese megtalalhato.

Direkt port írással.

Most egy DAC-ot próbálok rákötni, de az SPI megint kereszte tett. Lehet már a DAC-sem jó!

?

Nem ismerem, de lehet. PLL-el próbálkoztam, de olyan kicsi az időkülönbség a freki váltásban, amit nem tud időben lekezelni. Azaz 1-2 periódus kiment, mire változott a freki. Az nem jött be, de lemondok a 40KHz-ről, megoldottam hangfrekvencián, de most tesztelem a tempót.

De lehet jó amit küldtél, nem ismerem sajnos...

ESP-re találtam érthető SPI DAC-ra példát. Olyat, ami nekem is van itthon... ÉÉÉÉÉÉS, nem.
Nekem az SPI lesz a kriptonitom, 1x sem sikerült még! DSPIC UART,I2C egyéb ment, regiszter szinten, időzítőkkel, timerekkel, PWM, motorvezérlés H híddal minden. SPI egyszer sem! Most ESP-n sem!!!

Egész pontosan:

Ez RH 3 - 50 MHz adovevo lenne.
De ha csak digitbitfolyam kell akkor az alapsavi AD el is hagyhato igy gyorsabban tekerheto a pll nem kell varni az ado oldali hangfrekit kodolo dsp algoritmusra se.

Ez igen!

Nem tudom hogy lehet megoldani a problémámat vele, (mert még nem merültem bele egyáltalán) de nem semmi ketyere az tuti. Köszönöm!

igen talan ez az egyik legegyszerubb sdr softdefinedradio 8bites uCre fejlesztve , igaz vannak neki nemi hianyossagai de ennek ellenere mukodik ... atmega 8 bitje es orajele feldolgozasi sebessege " kilett maxolva" a cel erdekeben/

Neked I2S protokoll kellene. SPI DAC nem kifejezetten erre való.
De a direkt írás egyik esetben sem megfelelő, mindenképpen DMA, (esetleg IRQ) vezérlés kell! Az ESP32-höz van I2S arduino könyvtár, még a szinuszjelet is kirakja neked.

Mindegyik lassú lesz, azt látom már, bár nem megy rendesen még az SPI. Szoftveresen jó, de fizikailag valami mindig közbejön. (szoftver SPI-t tudtam összerakni, mennek is szépen az adatok, de mikor meghajtom, akkor kesze kusza jelek jönnek ki. Ha csak 1-1 adatot írok ki, akkor azok tökéletesek)

A SPI DAC ami itthon van, egy MCP4821-es. Arra 2x kell írni SPI-vel, mert 12 bites és az első 4 bit állít be pár dolgot. 16MHz órajellel próbálkozom. Vannak eredmények, de gondok is vannak. (Szerintem nem jó a táp, de ráaggatok egy logikai anaizátort holnap)

No de az SPI gyorsabb szerintem mint az I2C, de tévedhetek. Ha 16MHz-nél maradunk, akkor 16 bitet 1MHz-el visz át. 256 pontos szinuszal ekkor 3900Hz-elméleti maximumot kapunk. De nem lesz annyi, mert az ESP SPI-beállításai elvisznek pár értékes órajelet, valamint tologatni kell a 16 bites adatot. DE ami a legfontosabb, hogy 4.5us a setting time a DAC-nak... Ami 868Hz lesz 256 elemű táblával.

Összerakom, hogy működjön rendesen, kimérem, összevetem a számolásokkal, majd dokumentálom. A dSPIC-el is meghajtom az R-2R létrát, mert ha a pin olyan mint az Arduino-n akkor igen gyors lesz. 5x nagyobb az óra frekije, Harward architektúrájú, 2 vagy 4 óraciklus kell neki egy port íráshoz.

Nem tudom a feladathoz kell-e ennyire a pontos szinuszforma, azaz nem tudom kell-e a 256 pont. Amennyiben nem szükséges, akkor sokkal magasabb is lehet a kimeneti jel. Például az ESP (nem emlékszem, mondjuk legyen) 1 MHz-es DAC-ja 500kHz-es jelet is kiadhat, habár ebben az esetben messze vagyunk az ideális jelalaktól. A kimeneti jel frekvenciájának csökkenése esetén a kialakult jel már egyre inkább hasonul a szinusz jelhez. Ezen megoldás esetén azonban felejtsd el a diszkrét pontos megoldást, nem ez a jó út! Egyébként a gyári DDS chipek is így működnek. Ez utóbbi esetben lehetséges a frekvencia változtatása is, akár jitter (fázishiba) nélkül is.
A dsPIC-es verziót valamelyik rádiótechnika lapszámban már láttam, de ott sem a diszkrét pontos megoldás lett megvalósítva.

Köszönöm!

Ki fogom próbálni és utána is nézek, de egyelőre még ezt nyúzom még egy kicsit. Ezek a mérések alátámasztják az indokaimat, szóval nekem kellenek, meg néha jó ezekkel játszani.

Annyira nem kell hogy pontos legyen, de a frekvencia menetnek reprodukálhatónak kell lennie, az a fontos. Azaz, ha egy periódus csak 64 vagy 32 pontban van ismerve, nem gond. 256-ot kényelmi szempontok alapján, illetve gyorsaság alapján választottam. Az könnyen túlcsordul és kezdi a számolást előről, nem kell if-ekkel lassítani a dolgot. A frekit meg a lépésközzel könnyedén állíthatom később.

SPI:

Mondanám, hogy jó, de sajnos nem az. Levittem 1MHz órajelre, mert az analizátor 24MHz mintavétellel megy, 16-nál nem volt jó.

Az adatok szépen kimennek, az első byte 0011 és 4 bit adat, míg a másik byte is adat. Szerintem tökéletes.

Na de az Enable láb nem marad néha nullán. Éppen az adatátvitelbe szól bele egy rövid magassal. A láb d5 output és én a kódból írom. Gondoltam, ha már az SPI-lábak be vannak drótozva, akkor ez is, azaz a kódból kivettem, de ekkor nem jó semmi sem.

Amit hívok a loop-ból:



A loop-ban teszteltem késleltetésre is, és az nélkül is:



Az eredmények a csatolt képeken. Nekem az Enable láb nagyon nagyon nem tetszik.... Természetesen zagyva a kimenő jel.

Az első képen fixen 3-t írok a lábra. A második az ehhez tartozó enable. A harmadik, mikor ráengedem a szin táblát. Ekkor több tüske is van. 500,333 KHz -eket mutat. Néha mást.

Ez nekem még soha nem ment... Egyszerűen megfog minden esetben. Regiszter szintem mindent megoldottam, még FFT-t is, de ez nem akar összejönni...

Szerintem hardver SPI-re kellene átállni, mert lehet, mikor a begin transmission settings akármi lefut, újra definiálja a lábakat és ekkor van a gond. De nem tudom hogy kell hardver SPI-re átállni, még nézem, mert ez az ötlet csak most jutott eszembe. A másik, hogy próbáltam kivenni a settings-t, hogy csak 1x fusson, de nem sikerült.

ESP32 még sok egyelőre nekem, de küzdök, nem adom fel! :.-)