Fórum témák
» Több friss téma |
Arduino alatt gyerekcipőben jár a debugger (jtag adapter kell hozzá), csak valami az új 2-es verzióban, van, ott meg mintha lennének kompatibilitási hibák... A "gyári" espressif fejlesztőkörnyezetet nem ismerem. Ha necces időzítések kellenek, lehet mégsem jó, mert ugye vannak háttér folyamatok is, amik befolyásolhatják/megszakíthatják a program futását. Vagy bele kell mászni a DMA-ba - nem ismerem...
Szerintem ilyen jellegű problémád itt nem lesz.
Már eleve 240MHz-vel ketyeg a procid, és a megszakítás rutinodat rakhatod IRAM-ba: Bővebben: Link leirás
A problémádra itt a megoldás: Bővebben: Link
Ilyesmit olvastam én is, de már fáradok, lehet félreértem, akor bocsánat.
A leírásban elmondják mennyire precíz, meg fontos, meg minden. Ezt tudom én is, de nem nagyon válaszol a kérdésemre. Ha ebben a rutinban kiolvasok a memóriából, vagy egy tömb elemére hivatkozok aminek az értékét DAC2-re küldöm, akkor ha a timert pl 200KHz-re állítom és felteszem, hogy az ISR-ben ennél sokkal rövidebb idő a kiolvasás, küldés, de mégis valamennyi időbe telik, akkor ez pontos lesz? Azt nem írja le. De lehetnek függetlenek a timerek, elképzelhető, hogy az IDE fordításkor ezt megoldja, de nem tudom. (timer flag kinulláz, érték megadás, indítás az ISR függvényben lévő utasítások nélkül, így ha belefér a két interrupt közé a kód, akkor ok) A másik, hogy az Arduino IDE gcc-je optimalizációt használ, lehet más lesz a kódom!  Csak mert nekem 400K 8 bit adatom lenne, és 400KHz-en kellene etetni a DAC-ot, minimális csúszással lehet (PIC-nél ezt korrigálni lehetett), csak ne növekedjen ez az idő. De értem, lehet tényleg nem gond, csak szeretem precízen kiszámolva utasításciklusokban megadva mi mennyibe kerül! Rendelem, kipróbálom.
Ahha!!!
Köszi! Holnap átnézem jobban, de érteni vélem.
Írtam, de elveszett az éterben!
Szóval kis kerülőkkel, de meg lehet oldani, hogy kiírja, mennyi timer utasításba került a kód. Azaz le tudom kérni, hogy maga a timer write mennyibe kerül stb. Így menni fog! Köszönöm!
Ezt érdemes lenne meg építeni? : A valaha készült legjobb ESP32-vel készült frekvenciamérő – fantasztikus!
Bővebben: Link Csak mivel hitelesítjük?
Vettem oszcilloszkópot. Ha már eszem nincs, akkor villogjak ketyerékkel nem?
200MHz, 1Gsample, 2Mbyte mélység, vagy több. A hozzászólás módosítva: Máj 8, 2023
A kérdésedre a választ itt találod az 500. oldaltól: Bővebben: ESP32 adatlap Link
Minden programozható regiszter szinten. jóval bonyolultabb a PIC-nél sajnos, vagy szerencsére?
Ezt is nézd át: Bővebben: Link arduino ESP32
A kész rutinokkal azért könnyebb a dolgod mint regiszter szinten!   A hozzászólás módosítva: Máj 9, 2023
Idézet: Ha van egy stabil (termosztált) oszcillátorod, akkor hosszú idejű számlálással, a pontos idővel összehasonlítva...„Csak mivel hitelesítjük?” Vannak 10 MHz-es OXCO oszcillátorok 0.5 ppm stabilitással már kb. 20 USD-től kezdődő áron, és vannak egy nagyságrenddel drágábbak, amelyek GPS műholdakhoz "igazítják" magukat.
Ezt a leírást kerestem!!!! Nem kell megijedni, hogy 700+ oldal, mert emészthető. A PIC leírása is van ennyi mindennel együtt, de ott több az elektronika. DE nem annyira bonyolult szerintem. A PIC PWM, meg Timer, meg egyéb is van ennyire bonyolult, mikor az ember afrekiket számolja. De ha megvan, utána már könnyű.
Idézet: „Figure 1622. Options for Setting up the Dead Time Generator Submodule” Ez fontos. Szóval sokat tud, sőt többet mint egy PIC. Legalábbis ezt látom egyelőre.Köszönöm! A hozzászólás módosítva: Máj 9, 2023
Idézet: „Szóval sokat tud, sőt többet mint egy PIC” Csak halkan jegyzem meg, az ilyen butus kijelentések miatt léteznek a hoaxok, hogy hát mit is tudhat egy PIC?! Gyanítom a 32 bites ESP-t egy 8 bites PIC-el hasonlítasz össze. Mint azt legtöbbször teszik, amikor "bezzeg a PIC csak.... tud" sokatmondó, kezdőket alaposan megtévesztő monológok jönnek! Javaslom ilyenkor vess egy pillantást akár csak egy 16 bites, kicsit is modernnek számító típusra, mondjuk pl egy xxxEPxxGS sorozatra. Meg fogsz lepődni a több mint 100(!) darab 16bites PWM vezérlő regiszteren! Szerintem amit az nem tud, az nem is létezik...
Nem. dSPIC-et hasonlítok össze, aminek pl. a motor kontrollere jobb, meg úgy látom, hogy pl a pwm frekvencia 8 bites felbontáson jobb. Amire gondoltam, hogy többet tud, az a sebesség, wifi+ Bt+ USB+Sd card. Mindezt PIC-en összehozni nem könnyű + kell pickit programozó 10+pénzért. A sima dSPIC33FJ128MC802 majdnem annyiba kerül mint ez, még kell hozzá programozó, forrasztani kell esetleg, kell táp ilyesmi. Mindezt végigjártam és tetszik is különben. A leírást sem véletlenül kértem. Ez a PIC 16 bites, 80MHz-en pörög, és ha megnézed a hozzászólásaimat a körülmények ellenére pl. az MPLAB jobb, mert könnyen lehet szimulálni, számítani az időkritikus dolgokat, ráadásul Proteusban is van lehetőség szmulálni. Szóval nem rossz egyáltalán a PIC-sem, de mire összerakom 3-4x annyiba fog kerülni. De nem vetettem el azt a megoldást sem, mert ott mindent nekem kell programozni, tudom mi miért történik, nem csak előre gyártott függvényekkel operálok, ami vagy jó, vagy nem.
Nem szólom le a PIC-et egyáltalán.
Ha így kifejted, mindjárt másképpen hangzik!
Csak amikor oda van b***va egy 3 szavas mondat, aminek a lényege, hogy mert "csak" PIC, mindenféle objektív ismeret, és okfejtés nélkül(most nem feltétlenül rád gondoltam), ráadásul legtöbbször 32bites valamit egy 8bites PIC-el vetnek össze, az kissé unalmas már...Igen, ha ár/érték arányt nézünk, akkor ma már felejtős többnyire a legtöbb PIC(és egyéb 8/16bites mikrovezérlő). Én magam is ilyen megfontolásból tértem át a 32bites STM-ekre, de nyitott lettem más korszerűnek számító, olcsó platformra is. A lényeg, hogy 32bit alá már nem fogok menni, nincs értelme(az igényeimnek sem felel meg), és valószínűleg a 8bites PIC-jeimet el fogom adni, vagy kidobom, talán a min. 16biteseket még megtartom.
Az említett témához tartozó APIK: Motor Control Pulse Width Modulator (MCPWM)
Bővebben: Link
Naná! Csak én mazsola vagyok az ESP-hez.
Sziasztok ismét!
Létezik olcsóbb 19 bites bináris impulzus számláló IC? DIP tokozású kellene, olyan, ami a kimenetén 19-21 bit-en számolja az impulzusokat. Megrendeltem az ESP-ket, de ezekkel is játszanék kicsit. De nem találok. Lehet többet kellene összekötnöm, de azt nem szeretném. 512K-ig kellene elszámolni... Köszi!
CMOS cd4020 cd4040 ezek binárisak , jobb esetben minden bitet elérik (kivezetik) .
De csak 12 14 mélyek tehát több kell belőlük. 4020 14bit mély ... de van benne ugrás mivel a Q0 és Q3 között nincs kivezetve semmi . 4040 12 bit mély és minden bináris osztó pontja kivan vezeteve . Lessél CD4040 adatlap. A hozzászólás módosítva: Máj 10, 2023
Köszi!
Olvasgatom az adatlapokat, de nem tiszta egyelőre. Ezekből kettő kellene. Azonban a lábkiosztásokon nem látom azt a lábat, ami jelezné, hogy megtelt. Mert annak segítségével Resetelni lehetne önmagát, és léptetni 1-el a másikat. Így sokáig lehetne számolni. De még nem néztem ennyire utána, fejből írom. De tényleg nem látom a lábakon, melyik ez a láb. DE még nézem.
Azthiszem értem, nekem hogy kell ezeket használni. Szóval a legmagasabb bit, mikor beüt, akkor azt használhatom erre a célra. Így az első 2^11 ig megy el, a következőre reset és a másik léptet. Jól gondolom, hogy ezeket így kell használni? Szerintem igen, működhet így is.
512 ezerig számolnál ?
Milyen felső határ frekvenciáig ? Ez is fontos az alap CMOS kb 10 MHz-ig jó HC/HCT család kisé feljebb is. Bemeneti jel szintje mekkora ? mV vagy Voltok ? mV esetén előerősítő jel formáló kell . Tápfesz függvényében a standard CMOS és 74HC akár 12-15 V is lehet , a 74HCT sorozat csak 5 Voltot kaphat. Erről nem tudunk.
Akár az utolsó bit is resetelhet ami a második felfűzött számláló kimenetén jön létre.
1szerre mindkét számláló reset lábát billentheti. Persze kérdés , hogy tovább mi fogadná a leosztott jelet? ESP egyik portja ami nem tud túl gyorsan pörögni mint mérendő jeled soros bevitel ? Mind a 19 20 bitet egyszerre szeretnéd párhuzamosan kiolvasni ? Ekkor kell egy latch szerű állapot is. Avagy az átírás idejére megállítani a számlálók pörgését és amikor már ezt kiolvastad akkor egy reset és újra beengedni a mérendő jelet és újra számolják az osztók? Ekkor kell egy kapuzó , átíró vezérlő , reset áramköri egység, mindezt ütemezettten vezérlve pontos időzítéssel.. Klasszikus frekvencia mérő / időtartam mérő logikai áramköri egységekkel. Csak akkor minek az ESP ehhez ?
Párhuzamosan fut két projekt is. Mármint egyelőre szimulátorban, míg meg nem jön az ESP32. De ez a számláló nem ahhoz kell, ki szeretném próbálni ezt SRAM-al, ezek a számlálók állítanák elő a címeket. Utána egy DAC-ra is ráengedném. Elvileg működhet a dolog, 400KHz a maximum, de még az is sok lehet. 512K azért kell, mert van olyan SRAM ami ennyi címen tud tárolni 8 bitet.
Idézet: „Mind a 19 20 bitet egyszerre szeretnéd párhuzamosan kiolvasni ?” Igen, ezt szeretném. 3.3V lenne a cél, mármint a kimeneteknek. Na szép, csináltam Proteusban kis próbát, működik, de nem jó a kimenet feszültsége...
Talán ezt a kis projectet talán segít neked az ötletelésben: Bővebben: Link
Playing hard-coded audio on an ESP32 via DAC
A precíz időzítésnek az a trükkje, hogy utasítás órajel számolgatás helyett egyszerűen soha nem nullázzuk a számlálót, hanem mindig az utolsó eseményhez képest számoljuk, hogy mikor jön a következő. Így annyira kell valósidejűnek lenni a rendszernek, hogy két esemény között lefusson az IRQ handler, de nem számít, hogy mennyi idő alatt fut le ezen belül.
Aminek komplexebb architektúrájú memóriája van, ott az utasítás végrehajtás idők nem számolhatóak úgy, mint a 8 bites rendszereken. Jó móka volt ezeket számolni, de itt már nem működik. (Valamikor olvastam egy cikket, hogy a cache-t letiltva mégis lehet ilyet csinálni, de nem emlékszem pontosan.) Példával elmagyarázva a legegyszerűbb. Legyen egy olyan hardverünk, amin van ez a két alapeszköz egy timerhez kötve: * input capture: le tudod olvasni milyen számláló állásnál történt az esemény * output compare: tetszőleges számláló értéknél át tudsz billenteni egy kimenetet És az a cél, hogy egy bejövő jel után adott jelformát teljesen pontosan kell kiadni válaszként. Hogy csináljuk: * IRQ-t konfigurálunk az input capture-re és az output compare-re is * Input capture IRQ-ban kiolvassuk mikor történt az esemény (a számláló értékét a hardver lemásolja az esemény hatására ugye). Amikor kiolvassuk, akkor már egy kicsit később van, de még a szükséges válaszidő előtt. * A szükséges kimeneti jel időpontját kiszámoljuk úgy, hogy az input capture időponthoz körbefordulósan hozzáadjuk a szükséges válaszidőt * Az output compare-t beállítjuk, hogy a szükséges jelformát adja ki (tehát le vagy felmenő élt a megfelelő lábon) az adott időpontban. Tehát a számolt időbélyeget az output compare regiszterbe írjuk * Az output compare interrupt az él kiadása után fog meghívódni valamikor hamar. Ebben a kezelőben az előző kimeneti időponthoz hozzáadjuk a szükséges differenciát - körbefordulósan - és beállítjuk, hogy az adott időpontban a megfelelő irányú jelváltás történjen meg. Ezzel a módszerrel az óra órajele szerint teljesen pontosan fognak történni az események, semmilyen bizonytalanság nem lesz benne. Például egy 16MHz órajelű Arduino UNO ezzel a módszerrel 1/16-od mikroszekundumnyi tévedésen belül lesz minden esemény kiadásával. Látható, hogy ebben a megoldásban nincsen benne pontos futásidő. A számláló átfordulósan pörög. A legésszerűbb ha úgy állítjuk be, hogy a 16 bitet kitöltve forduljon át, így az aritmetika is automatikusan jó lesz, ha uint16_t-ben számolunk. Példa: előző esemény 0xFFA0 -kor történt, és 0x100-al későbbi időpontban kell a következő eseményt elkövetni, akkor simán hozzáadjuk, és 0x100A0-t kapunt, de a legfelső bit már kiesik az ábrázolásból, a szám tehát átfordult, 0x00A0 lesz az értéke. Ezt írjuk be az output compare regiszterbe, és akkor az esemény pontosan 0x100-al lesz később az előzőnél. Azzal kell csak számolni, hogy két esemény között csak egy átfordulása legyen az órának, tehát a 16 bites számláló körbeforgásánál kisebb legyen az események közötti idő. Ha hosszabb, az is megoldható a timerekkel, csak az már egy kicsit bonyolultabb, számolgatni kell az egyezéseket, de az outputot letiltani ameddig el nem jön a számláló ideje. Az időzítés bizonytalanságát tehát a nullázás okozza, de maga a nullázás teljesen felesleges. Nem mondtad, hogy pontosan mit kell adott időpontokban csinálnod, de ha mondjuk adott időnként kell SPI outputot indítani, akkor én azt úgy csinálnám, hogy a számlálót úgy konfigurálnám be, hogy pont annyi időnként forduljon át, és az átfordulás interruptra kötném simán a kimenet kiadását. Ha magától fordul át a számláló, akkor nincsen benne bizonytalanság, hogy mennyi idő alatt történik ez meg. És utána egyből előkészíteném a következő mintát, hogy a következő interruptra már elő legyen készítve, tehát a lehető legkisebb bizonytalansággal lehessen kiadni. IRQ->adatelőkészítés->kiadás helyett tehát IRQ->kiadás->következő előkészítése sorrendben. Ha az adatelőkészítésnek akkora a bizonytalansága, hogy néhány mintát tovább tart előállítani, akkor pedig egy pici ringbufferbe kell pufferelni az adatokat. Ha például SD kártyáról olvasol, ott ugye 512 bájtos blokkok vannak, egy 1024 mintát tároló ringbufferbe töltheted a főprogramból az adatot és az IRQ innen etetheti a DAC-t.
Nem értem egyelőre az ESP-t, de ezzel a szimulátorral összehoztam pár dolgot:
https://wokwi.com/projects/322410731508073042 Ide bemásoltam ezt:
Amiket a netről ollóztam össze. Van benne egy hiba. de lefut. Próbáljátok ki, hogy a linken megjelenő kódot erre cserélitek ki. A gondok: -Nem lehet csak úgy 400 000 byte méretű tömböt lefoglalni, de másképpen esetleg lehet, nem tudom. -A DAC írása lassú nagyon. -Mivel nincs direkt port manipuláció (nem találtam) ezért bonyolult függvényekkel oldották meg. Ami működik, de igen lassú. -Ha a fent említett módon PWM kitöltési tényezőt állítok, az is igen lassú. 45 mikro sec. Ami 22KHz, ha jól számolom. Emlékeim szerint a PIC-ben 40KHz-en kijött. (400 Kellene ugye... )Tudtok ennél sokkal gyorsabb kódot? Mindegyik megoldásra? Port írás, vagy a DAC- lehetne sokkal gyorsabb (8 biten) vagy a PWM-nek kellene 400KHz-en futnia, hogy a kitoöltési tényezőt tudjam manipulálni (baromi gyorsan... ) De ehhez célhardver fog kelleni azt hiszem... Parallel SRAM, Parallel DAC, számlálók, stb. A hozzászólás módosítva: Máj 12, 2023
Szia!
Azok a "Serial.Print....." ek nagyon meg tudják ám fogni a program futási sebességét. |
Bejelentkezés
Hirdetés |
