-
GAMEPOD.hu
Arduino hardverrel és szoftverrel foglakozó téma. Minden mikrovezérlő ami arduinoval programozható, és minden arduino program, board, és hardverrel kapcsolatos kérdések helye.
Új hozzászólás Aktív témák
-
ecaddsell
aktív tag
Vsz. kétszer gondold meg mielőtt beleugrasz ilyen nagyon olcsó cuccokba.
Én nemrég szívtam meg freki mérővel.
OLED kijelzős, vámhatár alatt 2.4GHz-ig mér. Ez kell nekem. (Ne legyen teljesen off, ESP32-ről vezérelt ADF4351-hez).Valóság: Valóban mutat valamit, sőt ha elég nagy jelet kap elmegy egészen kb. 3 GHz-ig is.
Viszont a pontossága nulla. Alapból van kb. egy fix 0.5%-os eltérés (normális mérő 10^-6 tól indul). Nem mellékesen nagy ugrásokkal változik a mutatott érték. A számláló mintha kb. csak 10 bites lenne.Na most mivel nekem is hobbi, kicsivel többért sokkal jobbat tudtam volna építeni (persze még szétszedhetem azt is amit vettem, de nem hiszem, hogy sokkal többet ki lehet belőle hozni).
Az ESP32-vel simán lehet akár 40 Mhz-ig tudó freki mérőt csinálni (15 bites PCNT, ablakozás RMT-vel van rá netes példa). Még hozzá téve egy előosztót akár feljebb is tudtam volna menni frekiben mint amit vettem (és úgy már nemcsak CMOS jelszintekkel megy).Visszatérve a szkópra: Kicsit alul specifikált. Mennyi a mintavételezés sebessége? Digitális (négyszög) jeleknél a mintavételezési sebesség tizedével kell számolni mint (felső) határ. Milyen a tárolás mélysége? Milyen érzékenységi tartományban használható? Milyen triggerek vannak?
(A dekódolást nem említem, bár pl. ami nekem van tudja, sosem használtam, annyira nehézkes a beállítás. Simán fe/lelfutó élre triggerelve megnézem a lényeget, sokkal gyorsabban így.)
Egyéni igény az, hogy a jel spektruma FFT-vel megnézhető legyen. Nem feltétlen a készülékben, hanem pl. offline PC-vel. Viszont az FFT freki felbontása függ a mintaszámtól, szóval van helyzet ahol simán kellhet 1M minta...
Sajnos konkrét cuccot, pláne ennyiért nem tudok ajánlani. Viszont saját tapasztalatból kiindulva, nem érdemes a nagyon olcsó cuccokba gyorsan beleugrani.
-
ecaddsell
aktív tag
Van valakinek jól működő prellmentesítő rutinja?
A jelgenerátoros projektemben eljutottam oda, hogy KY-040-el lehetne szabályozni a frekvenciát.
Ehhez ESP32-vel az egyik PCNT unit 0. csatornáját használom. Az encoder CLK-ja megy ctrl_gpio_num-ra a DT meg pulse_gpio_num-ra (vagy fordítva, elég sok kombinációt próbáltam).
A szuper ebben a dologban az lenne, hogy a számláló szépen számlálgat a háttérben a program másik része meg 1-2ms-onként ránéz, és ha van valami (0-tól eltér), akkor változtatja a frekvenciát (ill. alapállapotba teszi a számlálót).
A prellmentesítésre gondoltam jó lesz, ha valamit beállítok a pcnt_set_filter_value hívásnál.
Aztán rádöbbentem, hogy a filter csak 10 bites (0-1023) és mivel ABP clock-ban mér (80MHz) a max az kb. 12.5us. Ami édeskevés prellmentesítésre...
(Ugyanígy akartam használni a nyomogatás részét is, szóval a SW egy másik unitra ment volna).Ami kül. bosszantó, hogy a PCNT rém egyszerű megoldás lett volna, majdnem mindent a HW csinál, a felprogramozás után.
Sajnos a forgatásnál is hibázik (néha a másik irányba ugrik) az SW nyomogató meg totál használhatatlan, mert 0-5 között kellene állítható legyen (ez lenne az encoder frekvencia lépésköze), de egyszer megnyomva a kapott eredmény szinte egy 0-5 közötti véletlen szám.
Elkezdtem nézni az irodalmat.
Talán ez a legjobb leírás:
https://www.best-microcontroller-projects.com/rotary-encoder.htmlVégül-is az állapotugrásos megoldás megoldható (persze ehhez teljesen dobni kell a PCNT-s totál egyszerű megoldást), de így nem lehet megoldani a gombnyomós részét (SW).
Ott arra gondoltam, hogy az első él után (interrupt) egy ideig nem lenne nézve a gomb (interrupt tilt). Viszont azt is olvastam, hogy a forgatásnál is képes lehet 1 nagyon rövid SW impulzust generálni, szóval jobb lenne azt nézni, hogy mennyi időt tölt el H ill. L szinten. Viszont ez meg amellett, hogy nem egyszerű, nyomogatásnál tolni fogja a megszakításokat és az időmérés meg extra logika miatt az időt is rendesen viszi.
A furcsa az egészben, hogy a fórumok tele vannak ezzel a problémával és megoldási ötletekkel (van aki a HW-es kondist nyomja,van aki a SW-re esküszik én is jobban kedvelném ezt) de jó megoldást még nem láttam.
A legbosszantóbb persze, hogy a 10 bites PCNT filter totál meg tönkre vágja azt amit egyébként tudhatna a HW...
Na most jól kibosszankodtam magam. -
ecaddsell
aktív tag
válasz
ecaddsell
#9425
üzenetére
Aktuális ötletem prellmentesítésre:
Külön threadben (thread nem gond, frekvenciát is így mérem) X millisec-enként beolvasom a pint. Gombra X mondjuk 5ms.
Ha változott (L lett) akkor Y microsec-enként megmintavételezem (Y microsec-enként beolvasom Z alkalommal). Gombra Y mondjuk 100us, Z mondjuk 20 alkalom. Ha a Z alkalomból W alkalommal tartja a változást akkor elfogadom. Tehát 20-ból mondjuk legalább 6 szor (W) L akkor meg lett nyomva a gomb (Az encoder forgatásnál keletkező nagyon rövid virtuális nyomást ez szűri.)Ez után pedig egy hosszabb várakozást (csendes időszak) után (mondjuk 200-500ms) újraindul az egész.
Gombra ezt elég biztosra lehet hangolni (sőt ebben az esetben külön előny, hogy tartva magától lép, nem kell több lépéshez extra nyomogatni), a rotary részre meg vsz. marad az állapotváltozás figyelés...
Persze, ha valakinek van jobb ötlete szívesen olvasnám
-
ecaddsell
aktív tag
Bár lehet jó eséllyel meg tudnám csinálni (legalábbis az esetek egy részére), de ez nem annyira triviális mert a kondi a jelalakot is torzítja.
Szóval méretezni kell zavaró és kívánatos jeltől függően stb. A zavaró jel meg gombtól, öregedéstől stb. is függhet (meg encodernél forgatás sebessége miegymás).
A SW-ben 1 változót sokkal gyorsabban változtatok mint a kondit újraforrasztom.Példának okáért gyorsan összedobtam a gomb kódját a lenti logikának (mivel most per pill. még fordítani sem tudom, szóval lehet nemcsak hibás is, hanem esélyes, hogy már a fordító sem eszi meg), nekem ez sokkal gyorsabb mint forrasztgatni, tárolós szkópon nézegetni a lehetséges hibákat stb.
(Alsó rész init-be megy, meg GPIO-t változókat stb. be kell állítani).
#include <pthread.h>
#define ROTE_SW GPIO_NUM_xx
#define RENC1_STPLIM 6
typedef struct {
gpio_num_t swpin;
uint16_t step;
} roteswT;
roteswT rote1par;
pthread_t rotethrdsw1;
void* roteswbgrd(void* pars){
roteswT* swpar = (roteswT*) pars; // switch parameters
gpio_num_t swbut = swpar->swpin;
uint32_t bcount;
while (1){
if(digitalRead(swbut) == LOW)
{
bcount = 0;
for(int i=0; i<20; i++){
delayMicroseconds(100);
if(digitalRead(swbut) == LOW) bcount++;
}
if(bcount>=6){
swpar->step = (swpar->step +1) % RENC1_STPLIM;
delay (300);
}
}
delay (5); // could pthread_cond_wait() for interrupt from pin
}
} // roteswbgrd
pinMode(ROTE_SW, INPUT);
rote1par.swpin = ROTE_SW;
rote1par.step = 0;
pthread_create(&rotethrdsw1, NULL, roteswbgrd, (void*) &rote1par);Az encoder számláló része persze kicsit húzósabb és ami dühítő, hogy a HW akár tudhatná is (nagyon közel van hozzá)...
-
ecaddsell
aktív tag
Nem kérdés, sok mindent tudok írni ld lentebb. A kérdés az volt, kinek milyen bevált módszere van készen.
Meg ugye az sem mindegy hogy 5 SPI cucc vezérlése (többek közt TFT kijelző), meg AD bemenet (jelszint mérő), meg frekimérő meg 2 rotary encoder meg stb. stb. mellett pont az integrátor+hiszterézises komparátor (klasszikus HW megoldás) a legjobb módszer (egyszerűségben, gyorsaságban), ha meg akarom őrizni az interaktivitást ill. a kód átláthatóságát.
(OK, kicsit bonyolultabb lett ez a hobbi project mint eredetileg indult, de evés közben jön meg az étvágy...)
Nekem pl. a megengedett állapotváltozás nézése sokkal egyszerűbbnek tűnik. -
ecaddsell
aktív tag
Jelenleg 160x128 színes TFT (Bangood, 6 USD alatt), de már tervezem, hogy áttérek 320x240-re, mert egyre csak hízik ez a projekt aztán mindig kicsi a kijelző...
tvamos
Nincs időm arra, hogy mindenkinek mindent részleteiben elmagyarázzak. Vsz. elég jól leírtam a problémát meg az ötletet is, sőt adtam kódot is. Ennyi mindent meg kell magyarázzon.
A kód amit lent leírtam nem mellékesen (most próbáltam ki öt perce) nemcsak hibátlanul fordult, hanem hibátlanul is fut (csak a az encoder nyomógombjára). Nem tudom ki hogy van vele, de nekem nem mindig megy elsőre...
Amit meg kell oldjak még az a számláló. -
ecaddsell
aktív tag
Én teljesen elégedett vagyok a betekintési szögével (arra amire használom tökéletes).
Fektetve használom, alul-felül nézve hibátlan, oldalra képes romlani. Ahhoz képest milyen olcsó volt több mint jó.Viszont ha te ilyen nagyban utazol akkor biztos számít a sebesség. Itt (is) keresek valami megoldást. A változásokat elég lassan frissíti a kijelző, de vsz. ez nem a kijelző hibája, hanem nem tudom, hogyan kellene rávenni az Adafruit ST7735 könyvtárat, hogy HW SPI-t használjon (ESP32). Én a jelgenerátor chipet már rég így használom és tökéletesen megy.
Szóval, ha így indítom akkor megy de láthatóan lassú:
Adafruit_ST7735 tft = Adafruit_ST7735(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);Az irodalom szerint a HW SPI-hoz így kellene:
Adafruit_ST7735 tft = Adafruit_ST7735(TFT_CS, TFT_DC, TFT_RST);
Viszont így egyáltalán nem megy.Nem mellékesen nem is értem honnan tudja a fenti hívásból melyik SPI-t kell használni (VSPI vagy HSPI) . Amikor a generátorhoz csinálom az inicializálást ott meg kell adni, melyiket hozza létre...
hspi = new SPIClass(HSPI);
(A VSPI is hasonló).
Az SPI könyvtár viszont automatikusan tudja, hogy pl. HSPI esetén ezek a pinek:
CLK 14
MOSI 13 -
ecaddsell
aktív tag
Azt vettem észre a mérettel nagyon meredeken emelkednek az árak, szóval még akár reális is lehet amennyiért vetted. Én se vennék mást csak soros interfészes kijelzőt (hiába olcsóbb az ilyen-olyan shield).
A könyvtár linkjét köszi, ezt láttam is, csak annyi a könyvtár mint csillag az égen...
Viszont jó eséllyel megvárom amíg megjön a nagyobb kijelző, mert nemcsak a frissítéssel van gondom.
(A frissítéssel is azért inkább, mert jó pár adatot kell kiírni és ha 1 változik, akkor jó eséllyel az összes megy utána, szóval több részletben lényegében teljes újraírás van).
Minden kijelző, könyvtár variáns stb., pár extra #ifdef-t indukál és már most is rontja a kód minőségét a sok #ifdef, szóval most inkább még várok.Eredetileg 128x64-es OLED-el indult ez a projekt (dual color monochrome, felső 1/4 sárga, többi kék), aztán mikor kitaláltam legyen még ez meg az akkor láttam, kevés lesz a kijelző és megvettem a 160x128-as TFT-t.
Viszont ennél meg kiderült, hogy a textsize() az 10, 20, 30 stb. pixelt állít. Az 1-es méret az még nekem is kicsi, a 20-as mérettel meg nem fér ki az eddigi 4 sorból 2 (pl. frekvencia 9 digiten amit azért ultra gáz lenne több sorra osztani). Szóval hiába lett most 6 sor a 4 helyett, ha vízszintesen meg nem férek el (újabb tapasztalat: érdemesebb 1-el nagyobb kijelzőt venni, mint amiről azt gondolja az ember hogy elég lesz).Egyébként egy hasonló óra progi volt vsz. az első progi amit futtattam az EP32-n, ott volt a példaprogramok között és gond nélkül felment. WiFi-n szedi le a pontos időt. Nem is akartam WiFi-t használni (azóta se használtam), de pont ez esett kezem ügyébe.
-
ecaddsell
aktív tag
Én is újraírással frissítem. Korábban a kék háttérszínnel írtam újra, de nem volt jók a színek, szóval most nálam is fekete (de #define mondja meg mi a háttérszín szóval flexibilis).
Csak string-et használok, sprintf formáz.
Az alakzatokból max a filled rect lehet érdekes, ha az gyorsabb mint a háttérszínnel újraírás...Nem mondanám, hogy könnyebb kezelni az OLED-et, csak más. Sajnos könyvtáranként lehet más az inicializálás, kurzor kezelés (vagy nem kezelés), font méret beállítás (konstans, font nevében a méret stb), színbeállítás stb. Ezek egy része jól makrózható (én is ezt tervezem, ha eldől mik maradnak), más része nem annyira.
-
ecaddsell
aktív tag
Nekem méretileg elég lenne az 1.8-as kijelző is, ha kiférnék rá, lévén a nézési táv max 1m.
Egyébként megoldottam a ST7735-el a HW SPI-t is.
Mint sejtettem is fogalma sincs a könyvtárnak mit kellene használni ezért a default-ot használja.
Innen már csak az SPI default-ot kellett megkeressem és meg is lett az SPI.cpp-ben:if(sck == -1 && miso == -1 && mosi == -1 && ss == -1) {
_sck = (_spi_num == VSPI) ? SCK : 14;
_miso = (_spi_num == VSPI) ? MISO : 12;
_mosi = (_spi_num == VSPI) ? MOSI : 13;
_ss = (_spi_num == VSPI) ? SS : 15;Ezek meg a HSPI pinek amit a generátor chip-re használok, nem csoda, hogy összeakadt.
Áttettem a generátort VSPI-ra a TFT-t meg a HSPI pinekre és láss csodát megy a HW SPI és relatíve gyors is lett a frissítés (de még van mit javítanom).Na szóval összegzésnek ezek az SPI pinek ESP32-n:
HSPI
CLK 14
MOSI 13VSPI
CLK 18
MOSI 23A TFT HW SPI meg szépen lefoglalja a HSPI-t, szóval nekünk marad a VSPI...
Azért túl nincs dokumentálva a dolog...
-
ecaddsell
aktív tag
Fogadd meg a lenti tanácsot. Én is használtam Nano-t, kedveltem is mert a kis méret miatt gyors fordítások ill. feltöltések voltak, de mikor 128x64-es kijelzőt kezdtem el használni nekem is kevés lett a memória.
Nem mellékesen a Nano nem 3.3V kompatibilis és a legtöbb cucc amit használok meg igényli a 3.3V-ot.Szóval ha nem tömegével kell, ahol számíthat az ár akkor ESP32 (relatíve persze sokkal drágább, de absz. értékben még mindig megfizethető kategória). Ott sokkal nehezebb belefutni a korlátokba, és ha mégis, könnyebb a kiút. A környezet meg lehet tök ugyanaz.
-
ecaddsell
aktív tag
Sikerült a 160x128-as TFT-n 4 sorra préselni ami eddig is 4 soron volt. Nem lett túl szép, mert nem tudtam semmi szeparátort tenni a MHz és a KHz közzé (a vessző már a kétszínű OLED-en sem működött, mert átlógott a sárga sorból a kékbe, de ott legalább volt hely egy szóközre), szóval marad a különböző színre színezés.
(A színek valójában sokkal szebbek mint a fotón, ami nem adja vissza az igazi színeket.)
Az alsó sor a ténylegesen mért frekvencia, amit az ESP32 mér (egy Fujitsu mb506 előosztó után mert ugye az ESP nem tud 40MHz felé menni mérésben). Nemcsak ezért nem kerek, hanem az ADF4351 itt már csak kb. 6KHz-enként léptethető (25 MHz/4096).
A jobb zöld meg a jelszint amit 1 AD8318 mér. Mivel ennek az érzékenysége meg kb. 25mV/dBm ez is ingadozik némiképp még átlagolás után is (itt sokkal stabilabb tápfeszek kellenének).Idővel át kell térjek a 320x240-es kijelzőre, amíg nem jön meg van még 2 sorom. Meg egyre kevesebb időm erre a projektre.
-
ecaddsell
aktív tag
Létezik valami módszer arra, hogy az ESP32 GPIO34-GPIO39 pinjeit outputként használjam?
Ezen oldal szerint:
https://github.com/makeitlabs/ratt/wiki/ESP32-Pin-MappingEzek a pinek "GPIO input only/no internal pullup".
Gondoltam ha csak annyi a gond, hogy nincs internal pullup akkor teszek egy ellenállást kivűlre és kész, de nem megy (nem kizárt valamit elrontottam persze).Arduino IDE simán megeszi a pinMode(pin, OUTPUT);-ot ill. még a digitalWrite(pin, HIGH);-ra sem volt panasz...
Ha ezek tényleg input only pin-ek akkor számolásom szerint összesen 21 pin marad kimenetre (és ebben már az USB serial pin is benne van).
Egyébként van olyan (olcsó) board amin GPIO37 ill GPIO38 ki van vezetve mert azokon amik nekem vannak nincs is ilyen pin?
-
ecaddsell
aktív tag
Ennek van OLED nélküli változata is? Úgy egész szimpatikus lenne, pláne ha még valamivel olcsóbb lenne OLED nélkül...
Nekem olyan OLED-es ESP32 van, amin az OLED által használt összes pint lehagyták és az az OLED eléggé felejthető (a mérete sem túl nagy, de mellé a fényereje sem túl acélos), szóval az végül csalódás volt.
Mostanában nekem inkább a TFT a cél. Az OLED-el az a bajom, hogy annyira nem jó mint amennyire drága pláne nagyobb méretben.A gyári support nem annyira érdekes, annak ellenére, hogy doksi eddig sem nagyon volt, még mindig mindent megtaláltam.
-
ecaddsell
aktív tag
Lehet van valami speciális funkciójuk, mindenesetre én nem tudok róla, szimplán csak több pint szeretnék.
Pl. mostanában kezdtem el foglalkozni az AD9959 (DDS) kártyával ami elég sok pint igényel...Ami nekem furcsa az egészben, hogy rengeteg olyan kártya van ahol ki van vezetve a pin 6-11 amit a belső flash használ és még azokon sincs meg a 37-38 pin. Nekem úgy tűnik a pin 37-38 tök általános input pin lenne, ehhez képest meg a belső flash pineket meg nem tudom mire használják (bootloader HW debug?) ahhoz képest elég sok kártyán ott van...
A Wemos amit írtál elég közel van ahhoz amit keresek. Köszi a tippet.
-
ecaddsell
aktív tag
válasz
Teasüti
#9562
üzenetére
Már rég nem foglalkozok HW cuccokkal (amikor csak lehet készen vett modulokat huzalozok össze), de két videót tudok ajánlani a témában (amibe akkor is érdemes belepörgetni, ha valaki nem érti teljesen):
EEVBlog #1116 - How to Remove Power Supply Ripple
https://youtu.be/wopmEyZKnYoEEVblog #859 - Bypass Capacitor Tutorial
https://youtu.be/BcJ6UdDx1vgA "capacitance multiplier" különösen ajánlott, mert sokkal hatékonyabb lehet táp felelő jövő kapcsolási zaj szűrésére adott esetben mint kis zajú stabilizátor chip-ek (pl. LT1763 sorozat vagy LM1117 stb).
-
ecaddsell
aktív tag
válasz
MrChris
#9576
üzenetére
Az UNO-t nem ismerem, de vsz. pont ugyanolyan quartz kristály van benne mint a többibe, pl. ESP32-be amit jobban ismerek. Szóval ezek simán kell hozzák az 5 digitet ami nemhogy 30 percre, hanem akár 1 napra is elég jó esetben (1 másodperces eltéréshez). Ami esetleg gáz lehet az az alapból meglévő offset, az hogy nem pontosan annyi mint kellene legyen a kontroller órajele (kifogsz egy ilyen szempontból gyengébb példányt). Ezt is simán lehet kompenzálni, de itt már timer-t kell használni (timer interrupt).
A drift, az hogy hőmérséklettel változik az órajel frekvenciája kevésbé zavaró, ez még relatíve nagy változások esetén is tudja hozni az 5 digitet.
Viszont az nem kérdés, hogy a GPS 1pps (pulse per second) kimeneténél házi barkács szinten aligha van olcsóbb megoldás, mert ez alapból kb. 7-8 digit és stabilan tartja (sőt mivel alapvetően a jitter rontja, a hosszútávú átlag még jobb is).
Pont ezért tervezem, hogy a frekvenciamérés pontosságomat erre a szintre emelem (most ha megvárom a bekapcsolás utáni bemelegedést kb. 2*10 exp -7 et tudtam elérni, de ezzel az a gond, hogy az aktuális hőmérséklethez kell kompenzálni, mármint kontroller quartz kristály hőmérsékletéhez...)
-
ecaddsell
aktív tag
válasz
gyapo11
#9603
üzenetére
A NiZn felejtős, nagyon hamar tönkre megy (még hideg sem kell hozzá) és a kapacitása is gyatra (mindig a teljesítménnyel marketingelik). Próbáltam (szerencsére az őrült drága töltő jó a NiMH-hez is, azaz legalább azt nem buktam).
Szóval vonzó a nagyobb feszültség, de nem 1 hosszú távú megoldás...Szerk: A NIZn-nek nagyon gyors az önkisülése is...
xboy89
Ezek a boost konverterek ha még deep sleep-be teszed az ESP32-öt, akkor is fognak fogyasztani.[ Szerkesztve ]
-
ecaddsell
aktív tag
válasz
fpeter84
#9637
üzenetére
"azt keresem hogy egy adott LCD-t mivel tudnék a létező leggyorsabban meghajtani"
HW referencia regiszterekkel:
https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manual_en.pdfMivel az EP32 nem tartalmaz kijelzőt (a kijelzős board-ok is tipikusan valamilyen soros protokollal vannak hozzákötve tip. SPI) ezért soros protokol esetén HW SPI-t kell használni, vagy ha direktbe van a GPIO pinekhez kötve a kijelző akkor a pineket írva.
A direct GPIO-ra meg ezt a fórumbejegyzést találtam, szóval mennie kellene.
Most, hogy látom, így esetleg több pint is lehet írni (remélhetőleg tökéletesen egyszerre), lehet engem is fog érdekelni a dolog...
Viszont ha jól látom ennek a sebessége a HW SPI alatt van (valamiért), szóval a soros protokolhoz képest nem biztos, hogy akkora a nyereség.
Még 1 link:
GPIO.out_w1ts = (1 << TogglePin);
GPIO.out_w1tc = (1 << TogglePin);[ Szerkesztve ]
-
ecaddsell
aktív tag
OK, de fogadjuk el, hogy lehet olyan nagy felbontású kijelző sok gyors változással ahol ez szükséges lehet.
Neked meg nekem nem, de másnak esetleg igen (én erre annyi pint ami ehhez kell nem áldoznék be, meg mivel ez nincs offloadolva a procit is megfogja kicsit, de ha valakinek ez a legfontosabb rész miért ne). -
ecaddsell
aktív tag
Mert ipari használatra minden amit ki lehet hagyni kihagynak (extra költség) azaz direktbe hajtják a kijelzőt.
Nekem meg hobbizni (ami leginkább a prototípus készítéshez hasonlatos) sokkal fontosabb, hogy felesleges dogok nem viszik az időm, pl. úgy használhatok 3 fajta kijelzőt, hogy mikor most rá akartam keresni a kijelző kódra, hogy hány % rájöttem, hogy tűt keresek a szénakazalban... -
ecaddsell
aktív tag
válasz
fpeter84
#9675
üzenetére
A kulcs az amit korábban is írtam:
GPIO.out_wlts = <set for lower 32 pins>
GPIO.out_wltc = <clear for lower 32 pins>
GPIO.out1_wlts = <set for higher pins>
GPIO.out1_wltc = <clear for higher pins>Persze ügyesen is kell maszkolni, hogy csak azokat a pineket módosítsd amit kell, ill. ha jól értem két írás kell a set ill. clear miatt (közte meg kizáró vagy/bit invertálás).
-
ecaddsell
aktív tag
Ne viccelj ilyen könnyen feladod?
Pl. megnézted, hogy kompatibilis a jeladód szintje a kontrollerével? Az, hogy a jeladón villog a LED semmit sem mond arra vonatkozólag, hogy tényleg megtörténik-e az interrupt.
Pl. a loop-ból kiírathatnád a számlálót ha az változik. stb.Emlékszem rád a Fedorás topikból, olyan dolgokban tudtál segíteni nekem (meg kb. mindenki másnak) amit már rég feladtam(unk), itt meg hozzá sem kezdtél a debughoz... Ki kell íratni dolgokat a soros porton.
ESP32-vel még az interruptból is kiírattam, pedig elvileg azt nem szabad (lehet itt nem is menne) mert mi történhet alapon, max újra fel kell töltenem a módosított kódot.
Ha nincs soros portra lehetőség akkor rá teszel valamelyik pinre egy ellenálláson keresztül 1 LED-et amit ki be kapcsol az interrupt stb.Kevesebből mint az általad írt összeg tervezek 10digit/s-es frekvenciamérőt csinálni, Arduino környezetben ebből a pénzből már egy egész hobbi labort lehet építeni. Persze, ha eléggé motivált vagy...
-
ecaddsell
aktív tag
Na akkor rotary encoder prell mentesítés még egyszer.
Az alapötlet innen:
https://www.best-microcontroller-projects.com/rotary-encoder.html
Én KY-040-el használom (sokat), hibázni még nem láttam. A logika megszakításban megy, a lekérdezés poll.
A speed control arról szól, hogy ha gyorsabban tekered akkor nagy ugrásokkal megy. Frekvencia beállításnál igen hasznos, máshol ahol fontos, hogy az elmozdulással legyen arányos az érték meg nem kell (ki kell kapcsolni).
Mivel ez is olyan téma, hogy jó megoldást még nem láttam (ezért voltam kénytelen egyet írni), hibásat annál többet, érdemes eltenni a linket.
Kommentelni akkor szoktam kódot, ha nagyon kell. Sorry./*
This code is free software; you can redistribute it and/or
modify it under the terms of the CC BY-NC-SA 3.0 license.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND...
*/
#define ROTE_CLK GPIO_NUM_xx
#define ROTE_DT GPIO_NUM_xx
#define ROTE_SPCTM 50000 // speed control time limit, not defined no speedctrl
volatile int32_t rotval = 0;
void IRAM_ATTR isrrot() {
volatile static uint8_t pinsta = 0x3, cwi = 0, ccwi = 0;
volatile static uint8_t cwexp[] = {0xD, 0x4, 0x2, 0xB};
volatile static uint8_t ccwexp[] = {0xE, 0x8, 0x1, 0x7};
int32_t rvchg;
#ifdef ROTE_SPCTM
volatile static uint32_t tc = 0, tm = 0;
uint32_t ctm, td;
#endif
pinsta = (pinsta << 2) & 0xf;
if (digitalRead(ROTE_DT)) pinsta |= 0x2;
if (digitalRead(ROTE_CLK)) pinsta |= 0x1;
if (pinsta == cwexp[cwi]) cwi++;
else if (pinsta == ccwexp[ccwi]) ccwi++;
if (cwi == 0x4 || ccwi == 0x4)
{
if (cwi == 4) rvchg = 1;
else rvchg = -1;
pinsta = 0x3; cwi = 0; ccwi = 0;
#ifdef ROTE_SPCTM
ctm = micros();
td = ctm - tm;
tm = ctm;
if (td < ROTE_SPCTM / 2) rvchg *= 7;
else if (td < (ROTE_SPCTM * 2) / 3) rvchg *= 4;
else if (td < ROTE_SPCTM) rvchg *= 2;
#endif
rotval += rvchg;
}
} // isrrot
int16_t getrotv() {
static int32_t lval = 0;
int32_t cval = rotval;
int16_t rotc = 0;
if (lval != cval) {
rotc = cval - lval;
lval = cval;
}
return (rotc);
} // getrotv
void inirotein(gpio_num_t clk, gpio_num_t dt) {
pinMode(clk, INPUT);
pinMode(dt, INPUT);
attachInterrupt(digitalPinToInterrupt(clk), isrrot, CHANGE);
attachInterrupt(digitalPinToInterrupt(dt), isrrot, CHANGE);
} // inirotein
...
inirotein(ROTE_CLK, ROTE_DT);
... -
ecaddsell
aktív tag
Ja bocs, akkor amit írtam nem lesz jó (de mintha valami rotary encoder leírást linkeltél).
Ha valami pulzusos jeladó az sem nehezebb.Ugyanúgy minden élre kell interrupt és mérni kell a legutóbbi interrupt óta eltelt időt.
Két összegző kell (static volatile) ami minkét állapotban eltöltött időt összegi. Ha pulzus ideje meghaladja az elvárt időhossz mondjuk kétharmadát (vagy 3/4-ét ez jelalakból vagy próbával) akkor elfogadjuk, léptetjük a számlálót és mindkét idő összegző nullázva.Szóval amit lent írtál még így nem elég.
-
ecaddsell
aktív tag
válasz
ecaddsell
#9932
üzenetére
Szóval ha fix szélességű impulzusokat ad akkor valami ilyesmi kellene (tudni kellene, hogy HIGH, vagy LOW a pulzus értéke):
#define MINPLENGTH 15000
void szamlalo(){
volatile static uint32_t thi = 0, tlo=0, tm = 0;
uint32_t td, ctm = micros();
td = ctm - tm;
tm = ctm;
if (digitalRead(PULSE_ENC)) tlo += td;
else thi += td;
if(thi > MINPLENGTH){
thi = tlo = 0;
currentpulse++;
}
else if (tlo > MINPLENGTH) thi = tlo = 0;
}Ha nem, akkor a túl gyors változásokat figyelmen kívül kellene hagyni (olyan kód kellene).
Szóval látszik jó lenne tudni milyen annak a jeladónak a jele, kisebb meg nagyobb forgási sebességnél.
De innen már vsz. te is meg tudod oldani.
Arra figyelni kell a kódolásnál, hogy ha LOW értéket olvasunk a megszakításban akkor az előző időszak HIGH volt... -
ecaddsell
aktív tag
válasz
Johnny_vT
#9942
üzenetére
Nekem CO2 szenzor (MH-Z14A), ami a mai napig megy és napi szinten használjuk. Nem mellékesen az egyetlen amit rendesen bedobozoltam (mini OLED kijelzőre írogatja az aktuális értéket meg a trendet).
Viszont mivel elsődleges, hogy ne veszítsd el a motiváltságot, lehet maradnod kellene a drón témában, amihez talán kevesebbeknek van itt ötlete (viszont a súly miatt kezdésnek húzós lehet mert paneleket építeni 0603-as meg 100 lábú CPLD alkatrészekből mint pl. a XC2C128 teljesen más mint evaluation bord-okból valamit összehuzalozni). Szóval nem árt a realitások talaján maradni, hogy ne legyen kudarc.
-
ecaddsell
aktív tag
Ugyan nem mikrokontroller, de nem találtam jobb topikot, és talán itt van a legjobb esélyem, hogy választ kapjak.
Szóval van egy VHDL kód amit nem teljesen értek aminek az oka (azon felül, hogy ebben a témában nem vagyok jó) az, hogy ugyanahhoz a jelhez több értékadás történik a processen (folyamaton) belül.Egyszerűsítve:
process(sck,index)
begin
if RISING_EDGE(sck) then
index <= index + 1;
end if;
if clear='1' then
index <= "1111";
end if;
end process;Az első if az ugye triviális, az órajel felfutó élére növeli az indexet (ami egyébként a teljes kódban sehol máshol nincs módosítva). Viszont a másik if-ben ugyanahhoz a jelhez van még 1 értékadás. Nem mellékesen a process érzékenységi listáján is ott van az index.
A kérdés az, hogy mi lesz az index értéke, ha a clear input be van állítva?Tippem szerint "1111". A miértre is fel tudok állítani valami teóriát (a folyamat újra indul az index változása miatt ahol már csak a második if fut), de szívesen olvasnám valakinek a véleményét aki jobban ott van ebben a témában.
Bónusz kérdés: Jól értem-e, hogy ha van egy másik folyamat aminek az érzékenységi listáján csak az index van akkor ha a clear értéke be van állítva akkor az nem fog elindulni?
-
-
-
ecaddsell
aktív tag
válasz
kbhuinfo
#9998
üzenetére
A kérdés pedig: mire van szükség (ellenállás, kondenzátor, stb.), hogy jól működjön az áramkör? Feltételezem, hogy valami hiányzik és a mérés az, ami ezt az űrt betölti
Jó eséllyel árnyékolás az ami hiányzik. De ha nem is ez kellene legyen az első lépés. Az ESP32 nekem pl. bezavarta a GPS vevőt amíg jó távol nem tettem a GPS vevő antennáját.
-
ecaddsell
aktív tag
válasz
Tankblock
#10148
üzenetére
Ha csak ez az egyetlen gondja lenne az ESP32 ADC-jének, akkor igen, de sajnos több sebből vérzik.
A nemlinearitás egyébként máshol jobban vesézve van:
https://github.com/espressif/esp-idf/issues/164Amit linkeltél meg van említve a zaj is, amibe már korábban is belefutottam és amit sokkal nehezebb kezelni.
Amit ajánlgatnak az vicc, 100nF-os kondit csak az tehet oda, aki valami lassú szenzort olvas. Eleve az ESP32 ADC-je nem valami gyors, szóva tipikusan a multisampling se opció.Visszatérve a zajra: A zaj forrása tipikusan a digitális kapcsolási zaj és erősen függ attól, mennyi kimenet változik szimultán módon. Na erről nem szól az ábra.
Ma (meg már 1 ideje) a komolyabb analóg és digitális részt is tartalmazó chipek több tápfeszt igényelnek. Azaz külön kellhet szűrni és stabilizálni a digitális mag tip. alacsonyabb tápfeszét (1V tól 1.8V környéke), a digit interface-t (tip. 1.8-3.3V) ill. az analóg részeket. Ez persze megdrágítja a dolgot és ott spórolnak ahol tudnak.
Kb. ennek az eredménye, hogy a spec szerint 12 bites ESP32 ADC kb. 7 vagy max. 8 bites valójában...Amivel ezzel kapcsolatban mostanában küzdök: Miután az ESP32-vel a 8 digit/s reciprok freki mérőt megcsináltam, elkezdtem áttérni a 10 digit/s-es interpoláló reciprok freki mérőre. Ennek az a lényege, hogy nemcsak azt mérjük, hogy a jel egy adott egész számú periódusára hány egész referencia jel periódus tartozik, hanem a referencia jel tört periódus idejét is mérjük.
Ez úgy történik, hogy a tört periódus ideje alatt 1 kondenzátort töltünk konstans árammal és a töltés végén megmérjuk a kondenzátor feszültségét (ennek a digitális részét CPLD adja nem az ESP32).
Mivel nálam a referencia periódusa 10ns (100MHz) max. ennyi ideig tölt a kondenzátor, ami túl nagy nem lehet, mert akkor nagyon nagy tötlő áram kellene. Szóva a kondenzátor kb. 1 nF, és 30mA körüli töltőárammal kb. 280mV feszültség emelkedést lehet elérni max (azaz normálisan 0-280mV emelkedés, ami nem nulláról indul, szóval lényegtelen, hogy kis értékeket nem tud az ESP32 mérni).
Azaz a két digithez kb. 3mV felbontással kellene mérni. Viszonylag gyorsan, mert a kis kondenzátor gyorsan veszti a töltést még nagy impedancián is.
Na itt az ahol az extra 100nF nem opció.
Oszcilloszkópon frankón látszik a jel. A filléres Aneng 8008 multiméter is konzisztensen tudja indikálni az feszültség emelkedést.
Csak az ESP32 küzd a jellel a saját maga által generálta zajban...Szóval messze nem csak a linearitás a gond. Zajos és a sebessége is megérne 1 külön github részt, hogy mi a teendő, ha normális sebességet szeretnénk (erre is elég sok fórumbejegyzés van már). Talán mégsem véletlen a sok panasz.
[ Szerkesztve ]
-
ecaddsell
aktív tag
válasz
Teasüti
#10184
üzenetére
Az első az ESP-IDF-hez íródott, miközben én Arduino IDE-ben vagyok.
Nekem még soha nem okozot gondot ESP-IDF-et használni az Arduino IDE-ből...
Többek között a második kód esetén sem.
De mindegy, te tudod mire kell és mit vállalsz be ehhez.Én elég sokat vállaltam ebben a témában (talán túl sokat is) pl. VHDL kód írása és tesztelése (működni látszik) Xilinx CPLD-re, nyáktervezés (kétfajta progit is bevetettem) stb. Nagyon sokat tanultam belőle, annak ellenére, hogy lehet ez is a befejezetlen projectek sorát fogja gyarapítani.
-
ecaddsell
aktív tag
válasz
Teasüti
#10193
üzenetére
Lehet, hogy egyszerű, de pont azt a módszert követi ("megszakítást használni és programból számolni") amire korábban azt írtad, hogy lehetőleg ne.
Amit korábban linkeltél PCNT-s rotary encoder dekódolás szintén nem működik, ha nincs prellmentesítve a dekóder (ami túlárazottá teszi az egészet), ezt a kört már korábban lefutottam és itt leírtam.
Nekem úgy tűnik szisztematikusan megtalálod (előnyben részesíted) a rossz módszereket, csak azért mert az egyszerű.
Nem saját saját microchipet tervezek, hanem a gyártó által tervezett, utólag meghatározható logika összeköttetéseket határozom meg (ami tudtommal tényleg hasonló a digitális microchip-ek tervezéséhez).
Lelkes hobbisták így szokta retro gépeket/procikat összedobni (nem érdekel a téma csak érdekesség).
-
ecaddsell
aktív tag
válasz
Amarton
#10201
üzenetére
Bár nem is használtam, és nem is különösebben érdekel, de ha már ennyit írtatok róla gondoltam megnyitom az adatlapot és gyorsan átfutottam.
Bevezetőként annyit, hogy bár nem sokat és gyakran, de bőven 10+ éve vásárolok ebay-ről, és nem nagyon tapasztaltam, hogy rosszat küldenek (OK, alapból megbízható eladót választok, néhány cent nekem nem éri meg, hogy kb. 1 hónap vagy még több és refund után újabb kb. 1 hónapot várjak).A bekötésre a kulcsszó a 8.3.1.3 fejezetben van (ha a 10-oldalon lévő bekötési rajzról nem lenne eleve világos): high-side shunt.
Szóval a terhelés a föld és a - ág közé kerül a sönt ellenállás meg a - és a + közzé a + meg a pozitív betápra.Tovább nem mennék bele, de cserébe googliztam neked 1 maxim tutoriált (a találatok legelején) amiben minden benne van.
Szóval butaság össze-vissza kötözgetni.
Azt, hogy a SW mit, hogy csinál nem tudom, de ami még eszembe jutott, hogy minden mérésnél rögtön tisztázni kell mit mérünk és hogyan és nem árt 1 másik módszerrel is ellenőrizni (pl. multiméter vagy oszcilloszkóp az eszköz bemenetére). Itt pl. nekem totál nem világos, hogy a LED tiszta DC-ve van hajtva vagy PWM-el és ez utóbbi esetben egyáltalán ez az eszköz alkalmas-e a mérésre (szinte biztos nem, mivelhogy semmi ilyesmiről nincs szó az adatlapon, szintúgy effektív érték sincs megemlítve).
-
ecaddsell
aktív tag
válasz
Amarton
#10225
üzenetére
Pedig tényleg nagyon kicsi a valószínűsége, hogy hibás legyen, különösen nagy szériás cuccnál ahol minden automatizálva megy beleértve a tesztelést.
A chip-eket pl. a legtöbb esetben gyári szalagból kivágva kaptam.
Pl. DC-DC konverternél meg a panelizált (géppel) beültetett NYÁK-ból nem törték szét az egyes darabokat, hanem egyben küldték a min egységet amit árultak.
Persze nem mindig ez van, pl. csatlakozósoros panelt sose kapsz panelizáltan.Egyébként ilyen esetek elkerülésére (különösen, ha nem túl drága) min. duplán szoktam venni. Amellett, hogy lesz tartalék (és nem kell hónapot várni míg megjön a másik ha valami gond van), ilyenkor megnézem, hogy minden darab ugyanúgy működik és ha igen élek azzal a feltételezéssel, hogy valahol máshol van a gond.
Nem mondom, hogy sose fordulhat elő, hogy hiba van és ha valami akkor az ESD bárhol tönkre tudja vágni a cuccot.
Egyébként az ESD az egyik legalattomosabb hiba, mert ez az ami nem feltétlen teljesen teszi tönkre egyből a cuccot és ez ami nagyon rossz mert nehéz észre venni, mert pl. SPI még simán megy, de valahol már nem tudja a speckót a CMOS chip.
Pl egyszer ESP32 valamelyik pinjére véletlenül 5V jutott. Egyből tönkrement és annyira nagy áramot vett fel, hogy a stabi IC majdnem kiégett. Rögtön látszott kuka. Másik ESP32 egyik pinjénél meg azt vettem észre, hogy nem bírja a nagyobb frekvenciás jelet. Vsz. olyan ESD-t kapott amit már nem teljesen kezelt a védelem (valami minimális védelem van ezekben) és az a pin bizonytalanná vált. Legalább fél órám ment rá (de lehet jóval több), csere más pinre, csere más ESP32-re stb mire megtaláltam mi lehet a gondja.Szóval lehet a cuccod pont ott ment tönkre amikor bekötötted.
Aztán még van olyan storym is amikor a CMOS chip (ADF4351) EN pinje nem lett felhúzva, de csak 1 másképp tervezett panelnél vettem észre a hibát (bizonytalanná vált a lock), mert az elsőnél olyan volt az elrendezés, hogy annyi áram odakúszott, hogy elég volt neki (ugye CMOS bemenet több 10 MOhm tip.). Ha nem kapok egy másképp tervezett panelt, lehet sose veszem észre...
Röviden: El lehet hobbizni ezekkel az Arduino kompatibilis cuccokkal, ahol a hibák/veszteségek nem nagy ügy (pláne, ha rátolod az eladóra), de az ipari kategória nagyon más. Nem véletlen, hogy nagy-szériás gyártás ma már szinte csak Kínában fordul elő. Nem mellékesen szokás szidni a minőség-ellenőrzést. De azért nézzük meg, hogy pl. a jlcpcb-nek 20 cent/hobbi paneles árba (szállítás nélkül értendő) belefér automatizált optikai és elektromos ellenőrzés. Ezek után nem csoda, hogy ennek a szakmának se nálunk se nyugaton sem rózsásak a kilátásai. Hobbizni persze OK.
[ Szerkesztve ]
-
ecaddsell
aktív tag
válasz
Teasüti
#10238
üzenetére
Vsz. nem tévedek túl nagyot, ha a Robin Scheibler FFT tesztjének összes float igényét N*log2(N) + 2*N-el közelítem ami 4k FFT esetén kb. 57k float művelet 7ms alatt, azaz per float kb 120ns. Ebből a tényleges float mindenféle overhead nélkül jóval kevesebb (lehet fele se). Persze ez még mindig jópár órajel ciklus nem úgy mint a float DSPknél ahol 1 float 1 órajel, szóval aki nagyságrendi ugrást akar az megy DSP-re.
Röviden: abban a tesztben amit linkeltél vagy valamit nagyon elrontottak, vagy valami olyat néz ami az itt felvetett és tárgyalt FFT szempontjából teljesen irreleváns, szóval kár volt ide hozni.
-
ecaddsell
aktív tag
válasz
rsanya87
#10356
üzenetére
Melyik kristály (merthogy több van belőle; van az USB soros konverternek ill. a kontrollernek is) ill. melyik panel (szintén több verzió).
Egyébként miért kell cserélni? Biztos ez a megoldás, ha nem nagyon van felszerelésed hozzá?Egy forrólevegős páka viszonylag olcsón beszerezhető, töredéke egy normális hagyományos pákának. Viszont ha a kontroller kristályát cserélnéd azt zéró tapasztalattal én sem ajánlanám.
Mivel a komolyabb cuccok mind SMD-sek, ha ilyesmivel akarsz hobbizni, jobb ha erre készülsz. Normális padek esetén (sokat ezért használnak saját alkatrészt NYÁK tervezőkben) ill. normális méretű alkatrészeknél még hobbi szinten is előnyösebb az SMD (ipari szinten meg ahol stencillel viszik fel a pasztát ill. géppel pakolják fel az alkatrészeket komoly árelőnye van, azaz erre kell számítani).
-
ecaddsell
aktív tag
válasz
Atamano
#10523
üzenetére
Pont nemrég vettem én is ilyesmit, sajnos még nem jött meg, szóval konkrétan nem tudom megnézni, de ha ez az a verzió ahol az LCD panelre rátettek 1 PCF8574 vezérlő panelt akkor sima ügy mert te döntöd el milyen tápfeszt adsz neki (3.3V ha ilyen rendszerben használod), ui. adatlap szerint 2.5 és 6V között lehet neki adni.
Kockázat abban van, hogy ha a kontroller panel 5V-járol hajtod, mert ha véletlenül lejön a föld vezetéke ott biztosan vége a kontrollerednek (mert visszamegy az LCD panelen keresztül az 5V a kontroller IO pinjére és azt nagyon nem szereti).
Ha lehet ilyen kérdéshez dobj be képet is mert majdnem mindenből több verzió van és a kép sokat segíthet eldönteni neked mi van.
Szerk: Ha 3.3V-os a kontroller akkor jobb, ha a kijelzőnek nem 5V-os, hanem 3.3V-os tápfeszt adsz.
[ Szerkesztve ]
-
ecaddsell
aktív tag
válasz
Gergosz2
#10562
üzenetére
Nem tudom az ESP-ből, hogy lehetne klónt használni
Persze már ma is vannak területek, ahol kínai másol kínait...
Egyébként érzésre az ESP mintha nyugati cég lenne, van rendes doksi, van rendes fórum ahol ha értelmesen kérdez az ember gyakran válaszolnak is. Szokatlan.
Új hozzászólás Aktív témák
ekkold- Azonnali informatikai kérdések órája
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
- Audiokultúra - Hi-Fi-ről hifisen
- LEGO klub
- Megjelentek az első HMD okostelefonok, ezek a magyar áraik
- Helldivers 2 (PC, PS5)
- Politika
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Ukrajnai háború
- További aktív témák...
