Hirdetés
- Lassacskán fenyőfát állítanak a hardverek
- Tudjuk, de nem tesszük: a magyarok többsége nem törődik adatai védelmével
- Mesébe illő csodakábelt tervezett a GeForce-ok leégése ellen a Segotep?
- Irodát kért, de gyárat kapott Elon Musk a Samsungtól
- Nyílt forráskódú lett a legegyszerűbben használható AI tartalomgeneráló
- Milyen billentyűzetet vegyek?
- Hazavághatja a MicroSD memóriakártyák piacát a Biwin-féle Mini SSD
- HiFi műszaki szemmel - sztereó hangrendszerek
- Nagyon gyorsan búcsút mondhatunk az olcsó notebookoknak
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Milyen monitort vegyek?
- Kormányok / autós szimulátorok topikja
- Lassacskán fenyőfát állítanak a hardverek
- TCL LCD és LED TV-k
- Gaming notebook topik
-
PROHARDVER!
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
-
válasz
Janos250
#9299
üzenetére
Köszi, sajnos ez se oldotta meg. Neten github és még pár oldalon elég sokan foglalkoznak a témával. Van aki vett 5 db ESP32 doit panelt, 3 működik boot gomb nélkül, 2-nél muszáj nyomni program letöltés közben a boot gombot. Sajnos megoldást nem találtam ami működne.
(#9290) xboy89
Eddig nem omlott még össze az i2c,úgy hogy Core 1-re pakoltam a összes (4 db) taskot, core 0-á nem futtatok semmit. Még tesztelem azért pár napig.
Amit tapasztaltam és várható volt, hogy a webserver-t nem mindig lehet elérni. Ez a következőből adódhat:
1) Fut a hőmérséklet kiolvasás ami 150 db elemű tömbbe pakolja az adatot, ha megtelik akkor 1-el mindig eltolja a tömb indexét és ezt for ciklusban oldottam meg. Ez lehet annyi idő, hogy ha pont akkor akarom megnyitni a weblapot, akkor nem tud még futni az a task.
2) A webserver-t String-es megoldással rakom össze. Ez azt jelenti, hogy 150 db elemét a tömbnek for ciklussal rakom bele a webserver kódba, ráadásul 2 ilyen for ciklus is van ami hőmérséklet és aksi mért értékeit pakolja a szerverhez. Itt a for ciklusban a 20 adat belepakolása után kap egy 15 ms delayt (különben watchdog problémázna), majd folytatja. Viszont a 15 ms alatt másik task kap futási időt, pl.: hőmérséklet olvasás/adat pakolós task, ami lehet 15 ms alatt nem végez, a webserver nem tudja folytatni a weblap összerakását -> nem tölt be a honlap.Ha jó időpontba nyitom meg a weblapot, akkor betölt. Erre van valakinek ötlete? Lehet többek között ezért is raspberry-t használnak ilyen esetekben? Jó lenne az esp32-vel megoldani.
-
AcCEsS
senior tag
Lassan egy hete megy 3db AA tölthető akkuról (HT7333 LDO-n keresztül) egy ESP12 lapom. BH1750 szenzor van rálógatva, és a lux meg a vcc értékeket gyűjtögetem percenként. Ma a szokásos 3.442V - 3.446V közötti értékek megvadultak, és kiugró, 3.414V - 3.47x értékek kerültek a log-ba. Utánanéztem a lehetséges okoknak, és 470 vagy 1000 mikrós kondit javasolnak a GND és a VCC láb közé az ilyen csúcsok kisimítására. Ezt felfogtam, meg fogom csinálni/próbálni.
Más. Mivel az ESP.getVcc() millivoltban adja vissza a mért értéket, ezerrel osztom, és az így kapott Volt értéket használom. Eddig ok. Viszont több helyen is találtam ilyen képletet:
So to get the 'correct' voltage in V you need to divided be 1024. Like:
float vccVolt = ((float)ESP.getVcc())/1024;Mi a búbánatért kellene 1024-el osztani? Ez valami baromság, vagy tényleg így van?
-
válasz
Teasüti
#9289
üzenetére
Köszi. Újrahúztam az egész esp könyvtárat, core 1-re tettem mind a 4 taskot, variáltam pár delay-t, most futtatom a tesztet és várok amíg ismét előjön (remélem nem). Ha látok valami problémát akkor ránézek a kommunikációra.
Addig egy másik téma. 2 db ESP32-m van amit eddig tudtam minden gond nélkül programozni. Az egyiket továbbra is tudom, de a másikat csak akkor, ha lenyomom a boot gombot. Lehetne driver gond, de akkor a másik panellel hogy hogy megy. Lehet hibás az eszköz, ha eddig minden gond nélkül működött? Próbáltam újratelepíteni a CP2101 driver-t, de továbbra se lehet kódot rátölteni csak a boot gomb lenyomásával, másik ugyan úgy megy mint eddig.
Ti tapasztaltatok már hasonlót?
-
Teasüti
nagyúr
válasz
Janos250
#9283
üzenetére
Pedig nekem Uno-n is volt gondom a Wire könyvtárral, gyakorlatilag ugyanazt produkálta, mint itt ebben az esetben: egy idő után egyszerűen leállt a busz működése. Csak a reset segített rajta.
3rd party I2C könyvtárral zökkenőmentesen működött ugyanaz a kód.
Ez úgy két éve volt, azóta úgy vettem észre javítottak a Wire-n.
Egy ESP implementációnál meg ki tudja mit rontottak el és hol.Ezért kéne ránézni a buszra, amikor ezt produkálja.
Ha csak a nagy csend van akkor tudjuk, hogy kód hiba. -
válasz
Janos250
#9283
üzenetére
Lehet, hogy tényleg jó a wire könyvtár, mert az, hogy véletlenszerűen történik az összeakadása a programnak az fura. Ha rossz lenne, akkor nem szabadna 1000-2000 lekérdezésig jó lennie, majd ha rossz, akkor egy esp reset után ismét jól mér. Most biztos ami biztos alapon átraktam mindent core1-re és újrahúztam az egész esp könyvtárat.
-
Janos250
őstag
Én nem gondolnám, hogy a wire könyvtár ne lenne jó. Amit én tapasztaltam, amikor az UNO-n ment a prg, de ESP32-n nem, akkor a következő volt a hiba:
A szenzorra (vagy másra) parancs írás után kell némi idő, mire az képes válaszolni.
A lassú UNO esetén ez nem volt probléma, de a gyors ESP32-nél az írás után, és az olvasás elé kellett várakozást betenni. Persze az is lehet, hogy ez csak véletlen volt, és én észleltem várakozási idő problémaként. -
válasz
Teasüti
#9280
üzenetére
A busz vizsgálattal annyi a baj, hogy sajnos nem mindig jön elő. Folyamatosan kellene nézni pár óráig-1 napig, hogy meglegyen mi történik a hiba beálltánál.
Teljesen máshogy képzeltem el a 2 magot, kicsit túlozva úgy mint 2 külön kontroller. A leírásod alapján ha ez nem is okoz gondot, de nem jó megközelítése a programom felépítésének és elképzelhető, hogy tényleg nem szükséges 2 magot használni. Nekem onnan jött az elképzelés, hogy ha egyszerre akarok webservert futtatni, mellette mérni hőmérsékletet, akkor azt ne egymás után tegyem, hanem párhuzamosan. De jobban belegondolva lehet, hogy tényleg nem indokolt. Azt szerettem volna elkerülni, hogy ha lehet ne "akadjon össze" az espnow mondjuk hőmérséklet lekérdezéssel/NTP lekéréssel.
Mivel később a hőmérséklet olvasás 5-10 percenként történne, ezért elegendő, ha cora 0-ra rakom, ahogy írtad az nem gyakran fut le úgy se, ami meg gyakoribb átteszem core 1-re.
Emellett amit te és (#9281) Tankblock is említ, meg kellene néznem esetleg más könyvtárral is a hőmérséklet kezelést.
(#9281) Tankblock
Úgy érted hogy alapból az esp32 wire könyvtár nincs jól implementálva? Ha viszont nem azt használom, akkor ha jól sejtem te ESP-IDF I2C használatát javaslod. Jó lenne egyszerűen megoldani magasabb szinten, arduino alatt. -
válasz
Teasüti
#9272
üzenetére
Elnézést ha nem fogalmaztam egyértelműen. Leírom konkrétabban.
Van egy hőmérséklet mérés, kijelzőre adat kiíratás, wifi-n NTP lekérés, webserver futtatás. Ez lenne a master és van hozzá egy slave eszköz amivel az előző felsorolás bővül, espnow kommunikáció. Ezeket gondoltam két magon futtatni úgy, hogy ami wifi-vel kapcsolatos az megy az 0-ás magon: NTP lekérés, webserver (espnow meg callback-el megy, így azt csak feltételezem, hogy szintén 0-ás magon megy, a fórumon is volt szó róla, illetve amit linkeltem oldal is arra hivatkozik, hogy wifi-s dolgok 0-ás magon futnak). A kijelző és I2C hőmérséklet olvasás megy az 1-es magon. Eredetileg legalább is ezt terveztem. Sajnos azonban azt tapasztaltam, hogy bizonyos idő elteltével (volt hogy fél nap és volt hogy 2 napos futás után jött elő) az odáig jó érték helyett a hőmérőtől már nem a megfelelő adat jön, hanem 125 °C, amit olyankor küld, ha nincs bekötve a hőmérő. Egészen a resetig ezt küldi folyamatosan. Reset után ismét a jó érték látható.
Hivatkozva a linkelt oldalon írtakra:
"The two cores are named Protocol CPU (PRO_CPU) and Application CPU (APP_CPU). That basically means the PRO_CPU processor handles the WiFi, Bluetooth and other internal peripherals like SPI, I2C, ADC etc. The APP_CPU is left out for the application code."Innen jött a feltételezés, nem amiatt "akad" össze az I2C olvasás, mert valójában függetlenül attól, hogy melyik magon futtatom az I2C-t, az a 0-ás magon fog lefutni, de ott meg nincs neki prioritás adva, legalább is általam nem, mivel ugye én az 1-es magon gondoltam futtatni, ott adtam az I2C task-nak prioritást. Lehet, hogy a valójában lefuttatott I2C és Wifi és tényleg a 0-ás magon fut, és összeakad, ezért jön hibás érték a kiolvasásnál? Igaz itt felmerül a kérdés, hogy ha 1-1 feltételezett összeakadás történik, akkor utána miért nem jön a következő reset-ig jó érték? Azt nehéz elképzelni, hogy folyamatosan összeakadna a 2 kommunikáció.
Ha az általad javasolt szerint, mindent áttennék core 1-re, mivel ugye minden ciklikus, akkor a core 0á-n semmi se lenne. Vagy esetleg csináljam azt, hogy core 1-en futtassak egy task-ot, ami ütemezi a core 0-án a taskokat, amiket 1x meghívok, majd törlöm? Így is ciklikus lesz, de task szempontból 1x fut csak le.
Még egy dolog jöhet szóba, amit nem tudom mennyire helyesen adok meg. Globális változóként adom át a 2 mag között a hőmérséklet változó értékét. Ezt úgy teszem, mint ha nem task-okat futtatnék, setup() előtt hozok létre egy pl.: float temp változót.
-
-
tvamos
nagyúr
válasz
JAGER 10
#9254
üzenetére
Az oke, de en a mechanikaval a leheto legkevesebbet akarnek szivni, ha nem ez a barkacsolas temaja. A kapunyito meg pont erre van, megveszed, es mukodik. Erzekelot kell valahogy ratenni, de azert az sokkal egyszerubb, mint mindent megcsinalni.
Akkor eleg a tobbi idolgon gondolkozni. Azt hiszem, onnan mar reszletkerdes, hogy Arduino, ESP, vagy esetleg Raspberry PI.
Azt kene osszeszedni elobb, hogy milyen erzekeloket akarsz, hany darabot, es hogy mennyit akarsz barkacsolni, es mi az, amit megveszel inkabb. -
JAGER 10
tag
Igen, gondoltam már én is kapunyitó szettre.
Nem tudom pontosan milyen IP védettségűek a kapunyitó szettek, de úgy gondolom bírniuk kellene azokat a körülményeket, amelyek fóliasátor alatt vannak, ha a szabadban is bírják.
Pár hete szereltem fel egy kapunyitó szettet, amit lehet külső kontaktusokkal is vezérelni.A feladat azért összetettebb, mint nyitni/zárni, mert szeretném a páratartalmat, szélerősséget is mérni, valamint locsolást is időzíteni, esetleg árnyékolást biztosítani, ezért gondoltam Arduino, vagy valamilyen mikrokontroller típusú vezérlésre.
A vezérlés kialakítására lehetséges olyan koncepció is, hogy lenne egy master modul és több slave modul. Ezek WiFi-n kapcsolódva kommunikálnának egymással. Ehhez ESP8266, vagy inkább ESP32 szükséges tudtommal.
Mennyire bonyolult a kommunikáció létrehozása? Volt valaki, aki valósított meg hasonlót? -
#9237
BTminishop
aktív tag
BTminishop
aktív tag
üdv,
Rendeltem egy wifi modult (ESP8266) lesz egy nagyobb Arduinos projektem, amihez kelleni fog egy interfész. Először úgy indultam neki, hogy Java-ban írok hozzá egy grafikus interfészt de aztán inkább a web felé húzott a fejem, így hát webes interfész fog születni és ehhez választottam a wifi modult. A cél annyi, hogy majd az Arduinos hardver szeretne küldeni elég gyakran adatot a webes alkalmazásomnak és azt majd értelmezni fogja sajnos még nem sikerült jobban utána járnom de gondolom POST metódussal ez megoldható és megfelelő eszközt rendeltem ?!
-
Teasüti
nagyúr
Vannak rá open source firmware-ek, amiket webserver-en keresztül lehet konfigolni és beszélnek MQTT-ül is.
És mivel egy kutya közönséges ESP8266-ról beszélünk, ezért semmi nem akadályoz meg benne, h írj rá akár saját FW-t is, akár Arduino alapon.
Ezeket a kapcsolókat elég könnyű hack-elni, a gyártó kicsit se nehezítette meg a dolgunkat. Az a jack kimenet rajta gyakorlatilag az I2C portra kapcsolódik, szóval gyakorlatilag bármit rá tudsz kötni különösebb barkácsolás nélkül, ami I2C buszon kommunikál. Illetve ugye működik sima GPIO-ként is. És a 230V-os relé meg alap adottság, ami nem tudom fejből melyik lábra csatlakozik. A táppal nem kell törődni, integrált az egész. Csak bekötöd a 230-ba és örülsz.
-
Az ESP32-nek nem kellene mindig ugyanannyi idő alatt végrehajtani ugyanazt a kódot, ha nincs megszakítás?
-
Janos250
őstag
Én az ESP8266WebServer-t szoktam javasolni, szerintem ez a legegyszerűbb, legkényelmesebb. Már megy ESP32-n is. Nem kell az alapokkal foglalkozni, csak betesszük egy stringbe a html kódot, és átadjuk a szervernek. A klienstől érkező dolgokat is kényelmesen tudjuk lekezelni.
-
nope
tag
válasz
Janos250
#9137
üzenetére
Igen, csak nálam egy fiókban lesz az összes elektronika - gyakorlatilag egyetlen nyákon. Nem akartam még egy lehetséges gyenge láncszemet beépíteni a rendszerbe, szóval ha valamit be tudok kábelezni, akkor nem rádiózok.
A wifinek is lesz szerepe, egyrészt OTA frissítés (8266-on működik, ESP32-n még nem tudtam kipróbálni), NTP lekérdezés (DST megoldást is kell keresnem), majd később egy websocket is tervben van.
-
Janos250
őstag
Nálam a szenzorokat kezelő ESP-k WiFi-n kommunikálnak egymással. Nem javaslat, csak tényleírás.
Meg van olyanom is, ahol a neten lógó ESP32 szerver az összes bejelentkezett állomásnak elküldi bármelyikről érkezett adatokat, hogy az válogassa ki, mi kell neki.
Ezzel egyben a galvanikus leválasztás problémáját is megoldottam, mert pl. a K típusú termoelemeket olvasó panelok kezelését végző ESP táp megoldására hiába kaptam itt korábban egy csomó, jónak tűnő ötletet, egy se vált be, kénytelen vagyok akkuról táplálni. Még szerencse, hogy félévig csak hetente egyszer kell bekapcsolni, aztán egy félévig meg egyáltalán nem. -
nope
tag
Sziasztok!
Először is köszönöm a fórumnak az aktivitását, évek alatt rengeteget tanultam belőle.Végigolvastam több mint 9ezer hozzászólást, amiről nem volt itt szó, az gyakorlatilag nem is létezik
Viszont ennek ellenére tanácsot szeretnék kérni. Egy nagyobb projekt előtt állok. Kicsit túlgondoltam a dolgot, de így szép az élet
Szóval egy akváriumvezérlés lenne, a lényeg hogy a feladatokat szétosztottam, tehát minden részfeladatnak külön mikrokontrollere lesz (világításvezérlés, szenzorok) . ESP8266-osok lesznek, valamint egy ESP32-es vezérelné a többit (+ GUI is arról menne).A kommunikációt I2C-re bíztam volna, itt szépen le van írva minden okosság: [link]
Tehát tudnék adatot lekérdezni, a slave oldalon megszakítással megy a válasz, minden, amire szükségem lehet, megvan.
Csakhogy: mindegyik ESP-n integrált I2C-s OLED kijelző van, fix címmel (0x3c), így ha felfűzöm ezeket egy I2C buszra, akkor az összes kijelzőn látni fogom az összes kontroller összes kiírását... ESP32-őn ez nem gond, ott két busz van (twowire függvény lesz erre jó elvileg: egyiken megy a saját kijelző, a másikon meg a kommunikáció), de a 8266-osnál ez nem pálya.Úton van egy CJMCU-9548 board is, ez egy 8 csatornás I2C multiplexer, ezzel el tudom szeparálni a 8266-osokat egymástól, és az ESP32-esről tudom kiválasztani, hogy épp melyikkel akarok kommunikálni. De így a kicsik egymással nem tudnak, illetve a broadcast lehetősége is elveszik.
Vagy esetleg tudtok erre valami megoldást? Létezik más kommunikáció (visszajelzéssel, válaszadási lehetőséggel), hogy ne kelljen az alapokról megírni az egészet? Vagy egy második I2C busz szoftveresen esetleg?
-
Tankblock
aktív tag
ESP.deepSleep(300*1000000);Nálam csak ennyi van a ESP Wemos D1 miniben....
hagyhatod a loopban is.
projectemben saccra 10k ellanállat van a GPIO16 és a reset pin között.
mielőt elküldöd aludni egy delayt tehetsz bele.
Keress másik bootlodaert, (vagy ami az arduino ajánl és )töltsd rá azt.meg azt nézd meg h melyik ESP8266 csomagot használod, Emlékeim szerint a sima 2.4.0 bugos volt.
-
AcCEsS
senior tag
-
AcCEsS
senior tag
Van még egy ugyanilyen cuccom, ha lesz időm felforrasztom rá a lábakat és ki fogom próbálni azzal is.
Viszont az első ESP12 projektem révbe ért.
A múltkor linkelt fehér színű lapra forrasztottam rá, az aljára felment a HT7333 (köszönöm a korábban publikált mintát vargalex!) és jelentem működik! 
Egyelőre csak egy breadboard-on van, de megy szépen a deep sleep - wake, meg minden amit eddig ki tudtam próbálni. Mondjuk a végleges összekötéseket (kábelek, ellenállások, csatlakozók stb.) nem tudom hogyan lehet kivitelezni breadboard nélkül... Ti hogyan csináljátok?Most fedeztem fel, hogy létezik ESP-12S is, ami teljesen kompatibilis az E/F szériával, csak a wifin javítottak sokat: "Further improved antenna design, better signal performance". Az ára a szokásos... rendeltem is belőle...
-
AcCEsS
senior tag
válasz
Janos250
#9123
üzenetére
Linuxos vagyok, simán a terminált, vagy az Arduino IDE soros monitorát használom. Terminálban a "screen /dev/ttyUSB0 115200" paranccsal sasolom meg a kiírásokat. A csatlakozás közvetlenül történik a számítógéphez egy jó minőségű USB kábellel. Csak az RST és a D0 van összekötve. Ilyen a nodeMCU.
Mellékelek egy képet egy 3 menetből álló folyamatról 115200-ra állítva a terminált.
1. Csatlakozik a Wifi-hez, 10mp deep sleep, majd ébredéskor krixkrax és fagyás. Az egyik (kék) led folyamatosan világít.
(Utána nyomtam egy reset-et (LED kialudt), elindult, és azt írja, hogy az ok "Deep-Sleep Wake". Ez érdekes...)
2. Itt nem sikerült csatlakoznia a Wifi-hez (direkt leárnyékoltam meg a jelerősség is szar) és 15mp próbálkozás után ESP.restart();
3. Ugyanaz mint az 1.
Ugyanez a helyzet "screen /dev/ttyUSB0 74880"-al is, csak minden olvashatatlan krixkrax. Próbáltam külső tápot és másik kábelt is használni, szerintem a végkimenet ugyanez lehetett, mert egyszer sem tudtam pingelni és pár mp múlva a kék LED folyamatosan világított.
-
AcCEsS
senior tag
Szerintem azért írta, mert a kódban ugyan 115200 van beállítva, de annak futtatásáig már nem jut el a board. Viszont: "The default baud rate of ESP8266 is 74880" és emiatt a loader üzenetei a kód elindításáig 74880-el mennek. Gondolom ezért látszik minden boot első pár karaktere vagy sora bináris szemétnek.
-
AcCEsS
senior tag
Írtátok a NodeMCU/Wemos D1 mini páros túl nagy fogyasztású deep-sleep-ben, és erre sokkal jobb választás egy ESP12-E/F. Szeretnék én is egy alacsony fogyasztású egységet építeni. Működhet az alábbi módon?
ESP-12 + adatper board alul egy HT7333 LDO a lapra forrasztva (a középső 0ohmos ellenállást eltávolítva). Amíg tesztelem meg egy ilyen USB-DIP átalakítóról és USB-s tápról tudnám ellátni a lapot az LDO-n keresztül? És egy ds18b20 szenzort is elbírna? Mert ilyen cuccaim vannak itthon. Vagy kellhet még egyéb alkatrész?
-
Tankblock
aktív tag
Krixkrax azért jelenhet meg mert a bootloader más baudraten kommunikál....
ESP32 single core ---> remélem nem hozza vissza a ESP8266 os furcsa megoldásokat...
Wifi kezelése itt 1 magra van bízva..... Not again.....Bluetooth meg már 5.0 jár a szabvány..... ez meg 4.2 szóval ha követni szeretném akkor Nordik chipjei maradnának.
-
Egy sima LED villogtatós, soros porti kommunikációs kód esetében is ugyan ezt produkálja? Ki kellene zárni a deepsleep okozta probléma lehetőségét. Illetve, hogy tényleg deepsleep-ben van-e vagy csak egyik módban a 2 közül:
"The low-power architecture operates in three modes: active mode, sleep mode and Deepsleep mode. ESP8266EX consumes about 20 μA of power in Deep-sleep mode (with RTC clock still running) and less than 1.0 mA (DTIM=3) or less than 0.6 mA (DTIM=10) to stay connected to the access point."
-
-
AcCEsS
senior tag
válasz
Tankblock
#9110
üzenetére
Ébredés után csak krixkrax jelenik meg a soros terminálban semmi más, plusz a led folyamatosan világít. Lehet, hogy magával a board-al van valami gond, mert a tegnapi kísérletezés során csinált egyéb furcsaságokat is.
Más. Megjelent egy új ESP32 ami single core. Érdekes...
-
Tankblock
aktív tag
Hello,
Mit reportol a fagyáskor?
Nekem sosem volt ilyen boardom, az ezen lévő komponensekkel szerintem nem lehet alacsony fogyasztást elérni. ESP12-E használok, ha ESP8266 ról van szó.Honnan kapja a Vcc-t? Ha az USB kábelről akkor az legyen jó minőségű pl valami jófajta mobil töltőkábele.
Nekem általában ezzel volt problémám. -
Sziasztok!
Tudtok ajánlani kijelzőt? Ahogy olvastam érdemes SPI kijelzőt keresni, ha nem akarok kicseszni magammal. Olyan lenne jó, amihez van minta kód, bekötési segédlet. Jó lenne 3.5" méretben és nem horror áron. Ezen paraméter alapján egyet találtam: Raspberry Pi-hez ajánlott verzió, ami támogatott esp32 által, ehhez minta itt. Esetleg 2.8" méretben ILI9341 IC-vel, minta itt.
Az érintő kijelző nem kell jelenleg, elegendő lenne egy olyan kijelző aminek a felbontási, képminősége a lehetőségekhez mérten szép. Esetleg ezen kívül lenne valakinek ajánlása, tapasztalata kijelzővel vagy maradjak a linkeltek közül valamelyiknél?
-
válasz
Teasüti
#9097
üzenetére
Igen beszéltük, hogy ugyan azon a csatornán kell legyen mindent. Előtte minden a kettesen volt, router + mind a kettő ESP, de az nem jó. Tehát ugyan azon a csatornára csatlakozás kevés, kimondottan az 1-es csatornán megy csak.
Igen pipa, úgy néz ki, de azért még tesztelem, hogy mennyire stabil és tényleg megy-e. Ezt leszámítva már csak kijelzőre kell küldeni az információt, illetve PCB-t tervezni hozzá. Köszönöm a segítséget mindenkinek
(Plusz opció: lehetne olyat, hogy a mért adatokat thingspeekre küldeni vagy más módon monitorozni, még meglátom.)
-
Teasüti
nagyúr
A megoldás az volt, hogy nem elég a két ESP-t 1-es csatornára tenni, hanem még a routert is 1-es csatornára kellett állítani. Más kombinációval sajnos nem működött.
Igen, azt hittem ezt már megbeszéltük korábban. ESPNow adhoc hálózatának és a WLAN-nak is egyazon csatornán kell lennie!
Így akkor ez most jó? Működik? Kipipálva ez a rész?Kíváncsi lennék egy BLE vs ESP-Now összehasonlításra, melyik lehet az energiatakarékosabb vajon.
-
válasz
Janos250
#9095
üzenetére
Sajnálom, ha nem voltam követhető
Lényeg, hogy működik ESPnow + wifin keresztül routerre csatlakozás, onnan adat lekérés. A megoldás az volt, hogy nem elég a két ESP-t 1-es csatornára tenni, hanem még a routert is 1-es csatornára kellett állítani. Más kombinációval sajnos nem működött.
Jó a webserver-kliens is, ha nem kellene fix IP címmel dolgozni, ahol már UDP is szóba jön, legalább is NTP adat lekérésnél kell UDP is. Onnantól, hogy fix IP cím van és UDP függvényeknél is megjelenik az
IPAddressosztály, onnantól nem működik sajnos az NTP. Legalább is nekem nem sikerült megoldani. -
Janos250
őstag
Én már rég elvesztettem a fonalat, csak egyetlen megjegyzésem lenne:
Saját tapasztalat alapján az ESP32 8 (nyolc) clientet tud párhuzamosan kezelni.
Mondom ezt anélkül, hogy valaha is lementem volna a socket programozás szintjére. Én maradtam a WiFiServer, WiFiClient szintjén, oldják meg ők a socketek kezelését. -
válasz
Teasüti
#9093
üzenetére
Jaa értelek már, akkor 3 db ESP32 kellene
viszont ez így már jónak kellene legyen, csak nagy helyet foglalna el a panelen.Akkor ezért nem nagyon találok Wifi+Bluetooth példákat, mert nem nagyon megy együtt a kettő
. Akkor ez is kilőve pedig szép és jó lenne ,ha menne együtt. Kezdem érezni az ESP korlátokat, pedig olyan jól hangzik, hogy mennyi mindent tud, viszont nagyon sok esetben ott van egy képzeletbeli vagy valóságos apró betűs rész, hogy "kivétel ebben és ebben az esetben nem tudja".ESNow esetén egyik eszköz STA másik AP módban van. Az STA esetemben a külső ESP lenne, ami alszik és 15 percenként felébred, adatot küld AP, benti ESP-nek majd visszaalszik. A router mint AP eszköz, arra csak az STA eszköz tudna csatlakozni, de ő meg egyszerre két helyre nem képes vagy a "szerverre" vagy a routerre csatlakozik. Legalábbis kommentek alapján, illetve próbálkozásaim alatt erre jutottam, hogy ez lehet az oka. Egy példát találtam, ahol MQTT szervernek küld adatot egy ESPnow eszköz. Lehet, hogy csak Channel 1-en működik ? A routerem 2-es csatornán kommunikál. Megnézem majd mi van, ha átteszem azt is 1-re. Igaz tesztelni NTP klienssel tudom csak, amúgy is az lenne a lényeges nekem.
Ahogy nézem akármilyen vezeték nélküli eszközt választanék, nem úszom meg olcsón, akár RF, BT vagy egy 3. ESP32 is legyen az. Lehet jobban járnék az RTC modullal.
(Vicces mert az elején úgy indultam el, hogy valami összetettebb feladatot szeretnék, ne végezzek vele 2 hét alatt. Erre jött ez a hőmérő-óra projekt, gondolván nincs más jó lesz ez, nem baj ha hamar végzek vele. Erre....a legegyszerűbb dolgok tartanak legtovább Persze nem haszontalan amiket próbáltam, azokat is jobban ismerem legalább most már, de nem számítottam rá, hogy ennyi fejtörést okoz 2 ESP32 közötti kommunikáció.) -
Teasüti
nagyúr
Úgy értettem, hogy egy ESP32 duóval megoldani a gateway-t. Szenzor alatt meg a vezetéknélküli másik ESP-t értettem. Vagy használhatsz egy külső BT modult a gateway-en, pofon egyszerű programozni sima UART-vel kommunikál. A belső wifi-t meg netre ráállítani. Így nincs RAM limit se, mivel sima UART használat van csak, nem kell betölteni a BT könyvtárat. Igaz ez már nem BLE, hanem classic BT.
(Ha meg BLE modult használsz, annak meg lesz saját könyvtára amit megint csak be kell tölteni és vagy befér a ram-ba, vagy nem.)
Passz. BLE+Wifi ram korlátba ütközik, ez nem működik még natívan sem jelenleg.
ESPNow+Wifi viszont érdekes, annak elvileg mennie kéne. -
válasz
Teasüti
#9085
üzenetére
Mindenképpen 2 db ESP32-t akarok használni. Egyik kinti hőmérséklet mérésre, másik benti mérésre + kijelzésre. Sajnos a vezetékes kommunikáció ezért nem lehetséges. Ha nem akarnék NTP időadat alapján dátumot, akkor nem lenne gond egyik megoldással se amit eddig próbáltam (socket szerver, ESPnow), de nem szeretnék RTC modult pluszban, ha megoldható az NTP adat lekérése is. Így jelenleg a bluetooth maradt amit javasoltál, megpróbálom így. (RF modul vagy külső BT modul lehetne még opció, de ott is plusz elektronika kellene,. Ha már az ESP tudja a bluetooth wifi kombót, jó lenne ki is használni
). -
Teasüti
nagyúr
válasz
Tankblock
#9080
üzenetére
Nem figyeltem erre, viszont úgy veszem észre lassan a beágyazott rendszereknél is kezdődik, hogy egyre olcsóbbá válik az erőforrás, ami a programozás rovására megy. Pl egy Uno esetén a 32KB Rom-ot és 2KB Ram-ot alaposan be kellett osztani, viszont egy ESP32-nél azért a 4MB flash-nél és az 512KB Ram-nál annyira mindegy szerintem, hogy használunk-e String-eket, vagy sem.
-
Teasüti javaslata alapján utána néztem az ESPNow-nak. Sajnos nem tud egyszerre két eszköz kommunikálni + még netre is csatlakozni. Külön 2 eszköz kommunkációja ment. AP+STA mód kellene, de azt írták, hogy az ESP32-be egy rádió adó van, tehát ugyan azon a frekvencián tudja szórni az AP és STA jelet is. Ezért is SoftAP a neve annak amire képes. AP+STA mód estén, ha van egy router akkor STA módba lesz konfigurálva és úgy megy, ha nincs akkor pedig AP módban. Esetleg menet közben lehetne AP és STA között váltogatni, de azt nem próbáltam.
Megpróbálkozok még a bluetooth wifi kombóval hát ha megy. -
Janos250
őstag
"Akik minimum 2 db ESP32-t használnak és ezek egymással kommunikálnak (hogyan teszik, Bluetooth, ESPNow, más?), plusz netre is akartak csatlakozni esetleg, ők milyen lehetőséget tudtak használni? "
Mint már többször írtam, nekem neten lóg egy szerver, ahova be lehet jelentkezni az egyik porton, és egy másik porton megy a http lekérdezés, hogy kiféle, miféle van épp bejelentkezve. Ez nem javaslat, csak infó.
-
válasz
Tankblock
#9072
üzenetére
Arduino alatt is lehet használni az idf függvényeket, miért jobb szerinted ha arduino teljesen ki van hagyva? Az IDE sajnos nem a legszélesebb körben használható program. Azt sajnálom én is hogy egy STM32-es Kiel-hez vagy AVR studiohoz képest "butább" program. Sok hasznos funkciót elbírna még, de valószínű annyira hobbistáknak van kitalálva, hogy egy komolyan fejlesztőkörnyezet adta lehetőséget aki hobbi szinten programozik, ők nem hiányolják. Igaz én is hobbi szinten vagyok még is hiányolok sok funkciót
(#9068) Teasüti
Nézegettem a bluetooth + wifi használatot. Erre is azt írják githubos kommentek, hogy sajnos nem nagyon megy együtt, mert elfogy a RAM.
Valamit ki kell találjak, mert jelenleg a socket szerver még se lesz jó. NTP szerveren keresztül akartam dátumot lekérni, ami UDP-n keresztül kommunikál. Ha a socket szervernek statikus IP-t adok, akkor arra jutottam, hogy bezavarhat az UDP-nek, mert nem frissül az idő adat. Ha nem statikus IP-t használok akkor jó, viszont a socket kliens ki tudja mikor gondol egyet és nem tud csatlakozni. Jelenleg fix IP-t adok a szervernek, a kliensbe beírom erre csatlakozzon és megy is. Ha kihagyom ezt a fix IP dolgot, félek bármikor előjön egy csatlakozási probléma, amikor nem tudja a kliens hova csatlakozzon. Nem gondoltam, hogy ennyi problémás lesz.Akik minimum 2 db ESP32-t használnak és ezek egymással kommunikálnak (hogyan teszik, Bluetooth, ESPNow, más?), plusz netre is akartak csatlakozni esetleg, ők milyen lehetőséget tudtak használni? Nem gondolnám, hogy én vagyok az első aki ilyet szeretne csinálni.
-
Tankblock
aktív tag
Hello,
nem örültem meg, még,
esp-idf használom és néha megyek a development pathra néha meg a latest release pathra. Van róla rendes guide meg How to.... Nem oly ördöngős. Gitről meg lehet vadászni eléggé jó könyvtárakat is hozzá.
De igen volt rá példa h nem volt driver és hát nem maradt más hátra csak a technical reference....
Amúgy annyira nem kínai, sztem még az aurduino core is belerakható. Van kódkiegészítés, C++ hoz függvényekhez support. Refraktorálahtod a kódot. Megmuattaja hány helyen használod. Próbál írási időben segíteni.... (csak nem nekem :-P)
Az arduino ide-nek itt még van hova fejlődnie. -
válasz
Teasüti
#9068
üzenetére
Itt írnak róla. Van ahol azt írják ugyan azon a csatornán kell legyen ESPnow és a wifi csatlakozás, de a kommentek nagy része arról számol be, hogy nem megy együtt a kettő. Én nem próbálkoztam, így saját tapasztalatom nincs. Lehet egy próbát megérne. A bluetooth-t nem tudtam mennyire működőképes jelenleg önmagában, illetve wifivel együtt. Tehát ezt a kettőt meg lehetne próbálni még, azért a socket server-client irányba mentem, mert ehhez egyből volt minta kód mindenféle negatív komment nélkül és biztosra akartam menni.
(#9069) Tankblock
Bizony arduino core, illetve idf függvényekkel néha kiegészítve![;]](//cdn.rios.hu/dl/s/v1.gif)
Eclipse alatt regiszter szinten programozod?Köszi a tapasztalatot,úgy látom érdemes áttennem másik csatornára a routert, de akkor be kell látni, hogy sok wifi között előfordulhat veszteség.
-
Teasüti
nagyúr
válasz
Tankblock
#9069
üzenetére
Szerintem itt te vagy az egyetlen, aki natívan programozza az ESP-t.
Annó én is csak azért akartam megpróbálni, mert akkoriban az Arduino Core-ban még nem volt benne, ami nekem kellett. Viszont én már megakadtam a programozó környezet beállításánál. Arduino IDE után egy Eclipse nekem kínai. Hobbi szinten nem is tartok rá igényt. Persze gondolom más lenne a helyzet, ha lenne IT végzettségem. -
Tankblock
aktív tag
válasz
Teasüti
#9068
üzenetére
ugye nem az arduino esp32 core-t használjátok?
Én azt csak feltettem hogy éegyen, de 1 példánál többnél nem töltöttem vele időt. Inkább eclipse alatt küzdök.
nekem ment minden a 0 magra , akkor sem volt problémám....
Van egy elméletem, hogy az arduino implementációban van valami kehe.....A kapcsolat sosem lesz tökéletes ezzel együtt kell élni, és kezelni kell. Azt a design során kell eldönteni, hogy az adat fontos-e annyira h újrküldjük vagy sem. Ha igen akkor azt tárolni kell, amíg ki nem ment.
A BlueFi implementáció még nem tudom milyen formában van. Én a MESH networköt várom mint a messiást és a MQTT brokert, ha 1 implementációba bekerül és kapunk még 1 gateway nodot is akkor mindenre gombot vartunk......
Addig marad a BLuetooth mesh akinek nagyon kell NRF chippekkel.....
az említett hálózati túltelítettség végett nálam a router is a gyenge láncszemek közé tartozik, hajlamos eldobni az összes Wifi kapcsolatot és reportálni h minden jó. A wirelessben meg 0 becsatlakozott elem van.......
-
Teasüti
nagyúr
ESPNow miért nem jó? Úgy olvastam, ha ugyanazon a csatornán megy, mint a normál wifi, akkor tud párhuzamosan mindkettőn kommunikálni.
Amúgy BLE-re nem gondoltál még? Sztem adja magát, gyakorlatilag erre van kitalálva, hogy szenzor adatokat küldözgessünk vele elemes kis fogyasztású eszközöknél. Mondjuk azt nem tudom, hogy a BT és a Wifi együtt működik-e. Wifi-s projektem még nem volt.Amúgy Core 0-s hibákat nálam a nagyobb delay() oldotta meg, de újabban inkább csak olyan műveleteket indítok azon a magon, ami egy meghívásra csak egyszer fut le. Minden ciklikus folyamat az 1-es magon van.
-
válasz
Tankblock
#9066
üzenetére
Van esetleg javaslatod, ami stabilabb kapcsolatot tud vagy ez nem a websocet miatt van? 2 eszköz lenne, a szerver lekér NTP adatot netről, mér, kijelez. A másik eszköz a kliens, aki csak mér és küldi a szervernek az adatot. ESPNow sajnos nem jó a szükséges netről adat letöltés (később lehet adat feltöltés) miatt. Vagy törődjek bele, hogy ez nem lesz olyan stabil, mint egy SPI vagy I2C kommunikáció és inkább jobban járok, ha lekezelem az említett kommunikációs problémát egy adat újraküldéssel mondjuk?
-
-
válasz
Janos250
#9064
üzenetére
Megpróbálom majd a delay-t magasabbra tenni. Nem AP módban hozom létre a szervert, hanem fix ip és router beállításokat használva (socket server kiegészítve fix IP-vel), így szerintem a linkelt függvényt nem tudom használni. Ha jól sejtem, akkor wifi socket szerver-kliens esetben a routeren tudom átállítani a csatornát, mivel jelen esetben az az AP.
"Nálam az egyik projekt egy erősen "zajos" wifi környezetben gyakran hibázik, de kisebb forgalmú helyeken hibátlan. "
A zajos környezet jelentheti azt, hogy kb. 9-10 elérhető wifi hálózat van körülöttem? Megnézem majd hogyan alakulnak a wifi csatornák, lehet az ESP pont egy sokak által használt csatornán kommunikál és ebből adódik időközönként a kommunikációs probléma. -
Janos250
őstag
"Ezt úgy érted, hogy mindegy hogy én a bemásolt task-ot core 0 vagy core 1-re teszem, a wifi fogadása mindenképpen a core 0-án, a háttérben történik? Tehát ha én egy client.read vagy client.readStringUntil meghívást csinálok, akkor már nem a klienstől fog olvasni, hanem egy már háttérben beolvasott bufferből szedi ki az adatot? "
Igen, én így tudom.
"a core 0-ra nem tehetek semmit?"
Én szoktam, ez csak egy ötlet volt, hátha..
Vagy szintén csak ötlet, a delay(10) megnagyobbítása mondjuk 100-ra. Tudod, kísérletes tudományKözben itt töprengek.
Ha jól emlékszem, az ESP az 1-es csatornán forgalmaz. Esetleg más csatornán? Úgy rémlik, valahol azt is meg lehet adni, de nem emlékszem pontosan, hol.
Nálam az egyik projekt egy erősen "zajos" wifi környezetben gyakran hibázik, de kisebb forgalmú helyeken hibátlan. Tudod, csak ötletek, kellő kritikával fogadd!Közben megtaláltam:
bool softAP(const char* ssid, const char* passphrase = NULL, int channel = 1, int ssid_hidden = 0, int max_connection = 4); -
Sziasztok!
Úgy alakult, hogy kellene freertos kódot használjak. Van 4 task, ebből 1 db fut core 0-n a többi core 1-en. Jelenleg a 0-ra tettem egy wifi-s részt, ami figyeli a klienstől jön-e adat, ha igen akkor fogadja. Tettem bele delay-t is, de sajnos mindig előjön valami, ami miatt restartol az ESP32. A hiba ez lenne:
A kód ahol előjön a hiba:
void wificlientTask( void * parameter)
{
while(1)
{
String clientData;
char raw_data[11];
int i = 0;
int idxBatLevel = 0;
int idxTemp = 0;
WiFiClient client = wifiServer.available();
if (client) {
unsigned long CLIENT_TIMEOUT = millis();
while (client.available() == 0) {
if((millis() - CLIENT_TIMEOUT) > 10000) {
Serial.println(">>> Client Timeout !");
client.stop();
return;
}
delay(10);
}
while (client.available()) { // if there's bytes to read from the client,
char c = client.read();
if(c != 'W')
{
raw_data[i++] = c;
}
Serial.print(c);
delay(10);
}
}
}Lenne ötletetek, hogy mit kellene csináljak? Valami a
while (client.available()résznél lehet, valamiért mint ha beakadna. -
tvamos
nagyúr
-
-
Teasüti
nagyúr
A jegyzőkönyv kedvéért: ESP8266 és az ESP32 is 5V toleráns a GPIO lábakon.
A mikrovezérlő mondjuk ha 8266-ot használsz és bírja az 5V-ot, akkor úgy leosztani hogy az AD konverterre max 5 V kerüljön de inkább kevesebb.
Erre írtam, hogy bírni bírja, de az AD konverter 3,3V felett nem mér. GPIO használatban nincs különbség a 8266 és 32 között.I2C kapcsán meg mérés nélkül nem lehet rá mondani semmi értelmeset. Amiben biztosak lehetünk, hogy abban a beállításban nem működik. Nekem úgy tűnt tényszerűen kezelted, ezért ugrottam rá.
Korábban is azt hiszem az én esetemben került szóba a dolog, azóta kellően utánajártam a dolognak. Főleg ha már 2 méteres buszt tervezek rajta 6 slave-vel.
-
válasz
Teasüti
#9038
üzenetére
Nem ismerem az ESP8266-ot. Itt azt írták többen, hogy 5 V-ot tolerál, ebből indultam ki. De megjegyeztem, az ESP32-nél hogy ott 3.3 V a max. Én ESP32-t használok, oda írtam példának, hogy én 2 V-ra állítanám be az ellenállásosztót. Vagy én írtam kétértelműen vagy neked volt az, de a lényeg, hogy én csak viszonyszámokat írtam, hogy a max tolerálható feszültséghez képest hogyan válassza meg az ellenállásosztó értékét.
Máskor az ESP8266-ot inkább kihagyom példa esetén, nehogy hasonló félreértés legyen.I2C: alapból 10k felhúzó ellenállások voltak, a plusz random ellenállás csak egy próba volt, mert nem értettem miért nem jó a mérés és gondoltam felhúzó ellenállás pluszban segíthetne. A konklúzió szó helyett úgy mondanám, hogy leírtam egy tapasztalatot, ahogy azt már te is többször tetted. Mivel korábban szóba került az I2C és annak hatótávja ezért most egy friss tapasztalat alapján gondoltam megosztom, hogy akárhogy is van én hatótáv korlátba ütköztem. Nem mértem semmit, így igaz hogy a probléma okát nem tudom biztosra. Örülök, ha neked 10 méter se okozott gondot.
-
Teasüti
nagyúr
Már ne haragudj, de honnan veszed ezeket a blődségeket?
ESP32 és ESP8266 portjai 5V toleránsak, ez igaz. De ez nem azt jelenti, hogy üzemszerűen rá kell küldeni az 5V-ot egy 3,3V-os logikára. Az meg hogy éppen egy ADC-re kötnél be 4V-ot, az meg külön vicces: ugye az tiszta, hogy 3,3V-ig tud csak mérni az ADC?I2C-hez visszatérve: I2C amúgy nem igazán plug&play protokoll, a buszt minden esetben méretezni kell egyrészt vezetékezés szempontjából, másrészt a buszon lógó eszközök szerint.
Az, hogy próbapanelen random összedugdosol vmit random felhúzókkal, random vezetékekkel az vagy működni fog, vagy nem. Az meg hogy mérés nélkül egyből konklúziót vonsz és olyan kijelentéseket teszel, hogy 10 cm felett nem működőképes az I2C, az még jóindulattal is megmosolyogtató.Mellékesen nekem sikerült értelmezhető jelet kicsikarnom egy SI1145-ös szenzorból 10 méter vezetéken keresztül.
A SCL-re kellett berakjak külső felhúzót, ami kb 3k-s eredővel rendelkezik. SDA-ra nem is kellett külső felhúzó, illetve inkább csak rontott a jelen, mint javított volna.
Ami viszont fura, hogy 1k-s felhúzóval meg se mukkant a busz.Ha vki hozzáértő megnézi az alábbi képet, akkor a sárga jelnél mi az a két lépcsős emelkedés? Ha erősebb felhúzót rakok rá, akkor magasabb feszültségre fut ki a feltölés. Aztán vmiért meredeken ugrik fel a tetejére. Ezt a hirtelen ugrást nem értem. Lehetséges vmi áthallás a két csatorna közt? Mintha az SCL húzná magával az SDA-t, úgy tűnik.
-
Én ebayről vagy aliexpress-ről rendelném. Esetleg lehet keresni hasonló paraméterekkel alternatívát. ID, VGS, VGS(th), rDS(on) ezeket figyelve.
A feszültség osztót úgy értettem, hogy ha mondjuk laptop aksikat használsz akkor lehet lesz 6 V-od is akár. A mikrovezérlő mondjuk ha 8266-ot használsz és bírja az 5V-ot, akkor úgy leosztani hogy az AD konverterre max 5 V kerüljön de inkább kevesebb. Ha ESP32-t akkor meg max 3 V körül. Ellenállásosztó képlettel kiszámolható, hogy Ube = 6 V esetén, pl. Uki = 4 V, hogy véletlen se érjük el a GPIO-ra kapcsolható max feszültséget, marad R1 és R2, R1-et tetszőlegesen megválasztva mondjuk 10k, akkor R2 kiszámolható a belinkelt képlet átrendezésével.Az, hogy a max GPIO-ra kapcsolható feszültséghez képest mennyit választasz nem számít szerintem most, mivel nem uV az amit mérni szeretnél (persze 0.5 V-ot nem biztos érdemes). Lényeg hogy a végén a feszültség számításakor vedd majd figyelembe. Tehát ha számolod a feszültséget alapból úgy kellene, hogy (6V-os aksi esetén) 6*mért érék/4095 (12 bites AD-nél). Viszont az AD nem fog 6 V-ot mérni mert az ESP tegyük fel 5 V toleráns, le lesz osztva feszültség osztóval. Ezért az előbbi számításban a 6 V helyett 4 V-al kell számolni (vagy amit szeretnél), mivel ez lett beállítva az osztón, majd arányosítani a 6 V-hoz, azaz 6/4 V -os viszonyszámmal vissza kell szorozni, így a mért értéket a 6 V-hoz képest kapod meg, tehát 4*6/4*mért érték/4095. Ez viszont ugyan azt adja vissza, mint ha 6 V-nak vennénk az AD által max mérhető feszültséget így ezt külön nem kell leprogramozni. Max könnyebb megérteni vagy jobban összezavar
Ha valakinek van kedve végigkövetni a logikát és nem jól írtam javítson ki
-
válasz
Teasüti
#9015
üzenetére
& Janos250:
Mivel esp8266-ot fog vezérelni, aminek a kimenetei 5V toleránsak, a védődióda helyett beépített snapback áramkör pedig csak 6V-nál nyit ki, ezért jó eséllyel meglesz a gate-en az aktuális akkufeszültség, tehát tökéletesen fog zárni.
Vagy tévedek, és esp32 lesz a páciens? Mert akkor nem mondtam semmit...
-
Hát akkor elég rosszul értelmezted.
Az a két ellenállás nem feszültségosztó, ráadásul nincs rajta az ábrán az analóg bemenet bekötési pontja. Ha a [Load] helyére gondoltad a bemenet bekötését, akkor az szépen rákapcsolná a teljes akkufeszültséget a bemenetre, amiből szépen kijönne a füst. Bár az esp8266 i/o lábai 5v toleránsak, ha jól tudom az adc-re ez nem vonatkozik. -
Én úgy értelmeztem, hogy az ábrán látható 2 ellenállás adja magát a feszültség osztót nem kell plusz ellenállás. A FET feszültségre nem gondoltam, de akkor csak annyi hogy a max 2 V helyett mondjuk 2.6 V lesz amit arányosítani kell az aksi max feszültségéhez (ha 0.6 V esik a FET-en). De cáfoljatok meg ha nem így van.
Viszont mivel asszem 2.8 V lehet a minimum feszültség amin még biztonsággal működik az ESP32, így az aksit nincs értelme teljesen lemeríteni. Lényeg hogy meg kell nézni mekkora feszültség esik a FET-en, azt pedig hozzáadni az ADC mért feszültségéből, így meg van a tényleges aksi feszültség. Vdd ahogy írod az aksi.Deepsleep módban 10 uA a fogyasztása az ESP32-nek, egy AMS1117 3v3 LDO 5-10mA körül van terhelés nélkül.
-
válasz
vargalex
#8993
üzenetére
Azért írta xboy89 a fettel vezérelt feszültségmérést, mert így csak a mérés ideje alatt fogyasztanak az ellenállások.
Mondjuk ha jól számolok, 3,6V névleges akkufeszültség mellett 2db 10k ellenálláson 0,2mA folyik el, kapcsolgatás nélkül. Az esp deep sleep alatt mennyit fogyaszt? És a boost-buck konverter? -
AcCEsS
senior tag
válasz
Janos250
#8987
üzenetére
Nem jutottam előbbre, de többen írnak hasonló problémáról. Tuti a BH1750 lib lehet a ludas, mert ha a nem működő cuccra feltöltök egy ESPEasy firmware-t, rögtön életre kel a BH1750, azonnal érkeznek a lux értékek. De ha visszarakom a BH1750 example fordítását, nem éled fel a szenzor.
Az összes lehetőséget végigjátszottam... -
-
Attix70
aktív tag
Szeretnék majd csinálni egy villanyos bicikli monitorozó egységet ami Bluetooth-on kommunikál egy androidos eszközzel és ezzel kapcsolatosan az lenne a kérdésem, hogy ESP32-vel lenne ez a legegyszerűbb (vagy nano+HC-05) ?
Áram, gázkarállás, feszültség, sebesség lenne monitorozva. -
válasz
Janos250
#8968
üzenetére
Na ez az amit el akarok kerülni, hogy a router egyéb paramétereit is meg kelljen adni. Sajnos korábban se sikerült rájönnöm arra, hogy mi a gateway és subnet szám. Ha a router beállításaiban megnézem, ott ezt látom.
Ha viszont ESP-vel lekérem, a következővel:Serial.print("IP: "); Serial.println(WiFi.localIP());
Serial.print("Subnet: "); Serial.println(WiFi.subnetMask());
Serial.print("Gateway: "); Serial.println(WiFi.gatewayIP());akkor meg 192.168.2.1-et kapok IP-nek, amivel a router beállításait is elérem, illetve 255.255.255.0 subnet címet.
Ha összehasonlítjuk az ESP-vel lekért és a router beállításai alatt látható címeket, látható hogy különbözik. Na most melyik a jó és miért látok teljesen mást?(#8967) vargalex
Köszi, megpróbálok keresni ilyen beállítást a routeren. -
válasz
Tankblock
#8962
üzenetére
Jól tippelted, mert ismeretlen eszköznek látja a 2. csatlakoztatott ESP32-es modult. Megpróbálom felrakni a drivert újra.
A MAC címes megoldás hogyan működne. Ha meg van a MAC cím, akkor az mindig fix, mert hardverhez van rendelve, tehát sose változik, így ezt kell megadnom a kliens eszköznek? Azaz MAC cím alapján csatlakozna a kliens a szerverhez hasonlóan mint ha IP-t adnék meg?
(#8964) Janos250
Köszi(#8965) tvamos
Nem szeretném mindig újra megadni a kliensnek, hogy melyik IP-re csatlakozzon. Az lenen a jó, ha bekapcsolom akkor az ismert cím alapján a szervert egyből felismerje mindenféle plusz felhasználói beavatkozás nélkül. -
Teasüti
nagyúr
Megérkezett ez a Sim808-as modulom, azzal játszogatok most.
Azt kell mondjam nagyon király kis cucc ez!
Egy UART kell hozzá, meg egy-egy gpio port a be-/kikapcsoláshoz, valamint az alvó üzemmódhoz (ezeket fel/le kell húzni és tartani egy kis ideig, kvázi gombnyomást szimulálva).
Powerkey gombbal kézzel is lehet kapcsolni. De ha fixen földre húzzuk ezt a lábat (vagy áthidaljuk a gombot), akkor automatikusan boot-ol amint tápot kap és parancsra le is lehet kapcsolni. Megspórolva egy portot. Akkus üzemhez ez szerintem nem ajánlott, hisz Vbat-ról húzza fel ezt nem tudom mekkora ellenállással. De akkus üzemnél e nélkül is boot-ol magától, ha az akkufesz elég magas. CV/CC töltőáramkör integrálva a modulba.
BT3.0-át tud a modul, külső antenna kell hozzá.
És mindent AT parancsokkal lehet elérni, a BT SPP profilnál van transzparens kapcsolati mód is, amikor nem kellenek az AT parancsok, hanem egyszerűen fogad és küld UART portra mindent, mint egy sima HC-06 modul.
Előnye az ESP32-vel szemben, hogy beállítható pin kód a csatlakozáshoz és ugye sima UART, vagyis nem kell betölteni 800 KB-nyi library-t programozáskor. Valamint az erősebb antenna.
GPS-t rém egyszerű használni, igazából van rá kb kettő AT parancs ami sűrűn kell (bekapcs, pozíció lekérdez), NMEA mondatokkal próbáltam, de többféle protokoll szerint tud kommunikálni. Tökéletesen működik, még az USB portról is az ESP32 mellett (elvileg 2A-es táp kéne neki). GSM részét nem próbáltam még, kéne vennem egy feltöltős kártyát bele.
Valamint kéne szerválnom hozzá egy mikrofont és egy hangszórót.AT parancsfeldolgozásra tudtok vmi könnyű módszert? Sima text parsing jut csak eszembe.
Jah és Janos250 köszi a hardware serial tippet, valóban odatehető a port arra a lábra, amelyikre tetszik.
-
válasz
Tankblock
#8959
üzenetére
Lehet majd erre is sort kerítek, szerencsére jelenleg nem kell még ennyire elmélyednem.
Sikerült socket szerverrel megcsinálni, hogy routeren keresztül küld egymásnak a két ESP32 egy egyszerű "hello word" stringet.
Az a gond, hogy egyszerre ha bedugom a 2 ESP32-es dev board-ot akkor hiába külön USB porton van, még se ismeri be két külön COM portnak. Régebben TI mikrovezérlőknél nem volt ilyen gondom ott ment 2 panel is külön USB portról. ESP32 dev board (DOIT board ha minden igaz) esetén nem lehet megoldani? Elég rossz így egyesével mindig lehúzni cserélni cilust játszanom.Még egy kérdés, hogy ESP32-nek fix IP címet lehet adni úgy is, hogy a router gateway, subnet dolgait nem keverem bele, ne kérje? Amit találtam kódot, ott a router paraméterekkel együtt állította be a szerver ESP32 fix IP címét. Másik megoldás, hogy megnéztem serial monitoron az IP címét a szervernek, és manuálisan ezt megadtam a kliensnek. Azt nem tudom viszont, hogy idővel ez az IP vajon változhat-e, azt sejtem igen, attól függően a router milyen IP-t oszt ki.
-
gyulank
addikt
Szeretnék (főleg) NET nélkül, Wi-Fi-n át weblapon keresztül jelszó beírása után ki-be kapcsolni 1 relét.
Esetleg másodpercben megadható beállítható négyszögjellel. Esetleg időzíteni automatikus visszakapcsolását.
Van hozzá: Arduino Nano V3; Arduino Pro Mini; ESP-07; NRF24L01
Konkrétan 1 mozgásérzékelő által kapcsolt riasztó autókürtöt akarok kikapcsolni, mielőtt engem dudálna, úgy, hogy akárki ne tudja állítgatni. Melyikkel lehet megcsinálni, és hogy? -
Janos250
őstag
MQTT szerver része - tudtommal - nincs megfelelően kidolgozva ESP-re, csak linux alá, pl. Pi-re.
Küldés:
Én a következőt csinálom:
Van egy ESP32 szerver, amire neten (akár helyi WiFi-ről, akár az ország másik feléből) lehet küldeni adatokat, és minden bejelentkezett kliensnek továbbküldi, azok meg értelmezik, hogy kell-e ez nekik. Nem azt mondom, hogy ez Neked jó, ez csak egy példa, amit én használok. A bejelentkezettek küldhetnek is, és elküldésre kerül a bárki által megosztott adat (Pl. másik ESP32-ről, windows alól putty-al, stb) -
válasz
Tankblock
#8946
üzenetére
MQTT értelemzésnek többzör nekifutottam már, de kicsit bonyolult volt nekem. Esetleg egy jó leírást tudsz javasolni hozzá?
Alternatív megoldásnak esp32 socket server ami még jó. Ettől független annyi helyen olvasni MQTT-ről hogy érdekelne az a verzió is, hogy mi ez, mire jó, miért érdemes használni stb.
-
válasz
vargalex
#8944
üzenetére
Elhiszem én is, de nem látom hogy tényleg jól írtam-e meg a kódot addig, amíg aksiról nem megy hosszabb ideig.
Másik kérdés mindenki felé.
ESPnow tényleg nem megy WIFI-re csatlakozással együtt? Adott 2 db ESP, egyik mér, küld adatot a másiknak, aki netről fogad/küld adatot. Ha nem ESPnow, akkor mivel lenne érdemes a két eszköz közötti küldést megoldani, hogy WIFI-re is tudjon az egyik csatlakozni? -
Teasüti
nagyúr
De, ugyanaz a kiosztás. Csak nyilván olyan panelt nem használhatsz külső modulhoz, amin már rajta van egy.
Az UART busz hülyét kap, ha két modult kötsz rá.
(#8934) Janos250
A linkelt programozón nincs rajta az a két tranyó, ami kell az invertált logikához. Így az auto letöltés bukta.
Valamint ránézésre a 3,3 voltot valszeg feszültségosztóval állítja elő egyéb hijján, ami meg hááát...
Azok a 0603-as ellenállások nem úgy néznek ki, amire szívesen rákötnék akár csak 100 mA-t.
Az 1/10W-os korlátjukba legfeljebb 68 mA fér bele 1,7V-os drop-nál, ezzel meg nem biztos, hogy meg lehet hajtani egy ESP32-t. (Nem jártam utána.)
Szóval az UART kommunikáción kívül konkrétan semmire nem jó.
A devkit panelje meg semmivel nem kerül többe, vagy talán még olcsóbb is mint egy tisztességes FTDI programozó. És szerintem bekötni is ugyanannyi, mint egy FTDI programozót: usb az egyik végén, dupoint a másik végén.
-
válasz
Teasüti
#8922
üzenetére
ESP32 WROOM32 adatlap 14. oldal 7-es fejezet, oldal közepe:
"Note:
Soldering Pad 39 to the Ground of the base board is not necessary for a satisfactory thermal performance. If users do want to solder it, they need to ensure that the correct quantity of soldering paste is applied"Solder pad alatt szerintem arra gondol, amiről mi is beszéltünk. Ha megnézed az adatlap 14. oldalán a schematic-ot, akkor látszik hogy jobb oldalon a GND3 fölött van a P_GND. Ha ezt összehasonlítod a PCB-vel, akkor látszik, hogy a P_GND nincs a GND3 fölött. Tehát ezek szerint a P_GND, ami a 39-es láb, illetve a megjegyzés az adatlapban engedményt ad arra, hogy nem muszáj beforrasztani, habár a schematic úgy mutatja még is. Tehát a felhasználótól függ be akarja-e forrasztani. Én szerintem hagyni fogom.
-
válasz
Teasüti
#8926
üzenetére
Tényleg már látom. A reset gomb mindig jól jöhet mondjuk a panelen szerintem, ha nem akarsz aksit/elemet vagy hálózati resetet.
Ezen a devkit panelen ahogy nézem ki van hagyva a forrasztási helye az ESP32 wroom modulnak. Ha nem akarod ráforrasztani akkor nem látom még hogyan lehetne programozni.
(#8927) DopeBob
ESP32 Gateway. Ezen van ethernet. -
Teasüti
nagyúr
Nem tudom ez a programozó mennyivel jobb mint egy FTDI
Ha megfigyeled az ESP32 programozót, akkor azon rajta van az auto letöltéshez szükséges két tranyó is, ami lehúzza az EN és IO0 lábakat. Gyakorlatilag a Devkit áramköre egy az egyben CH340g-vel. Így mint írtam volt megspórolható még a két gomb is a NYÁK-ról.
Ezzel konkrétan nem kell semmi kiegészítő a modul mellé az EN felhúzó ellenállásán kívül. Kivezeted 6 tüskére a Vcc, GND, RX, TX, EN, OI0 lábakat, rá erre a programozóra és uccu neki!
Mondjuk a CP2102-es programozó szimpatikusabb lenne, ilyen van a devkit-en is, de az mellé kell egy auto-program áramkör még pluszban vagy a NYÁK-ra, vagy vhova (vagy hát különben nyomogatod a gombokat).
Talán az volna a legideálisabb, ha gyorsan összeraknék magamnak egy ilyen programozót a fenti mintájára CP2102-vel.szerk: hmm ami azt illeti nem is kell saját, találtam hozzá "eredeti" devkit programozót!
(#8925) tvamos
Nem lehet, hogy a fura program nyelv miatt?
Állítólag nem rég jött hozzá ki egy C fordító.
8 független mag azért elgondolkodtató.
De tényleg nincs elterjedve egyáltalán. Teljesen véletlenül találtam rá. -
válasz
Teasüti
#8922
üzenetére
Ja igazad van a gombokhoz ajánlott a 100nF, kicsit belekeveredtem már
. Nem tudom ez a programozó mennyivel jobb mint egy FTDI vagy CP2102-es USB-TTL konverter. Én az utóbbival tervezem használni. Ha jól tudom 8266-nál is soros vonalon lehet programozni. Így oda ez is szintén használható. RESET gombot érdemes használni, akkor már csak max a boot gomb-ellenállás-kondi 3-as a plusz alkatrész.
Sőt egy FTDI vagy CP2102 esetén csak RX, TX, VCC és GND kell. Bár ahogy nézem amit linkeltél is ugyan az lenne, csak kicsit drágább eszköz.
Egyébként arra a hűtőfelületre nem tudom tényleg mennyire lehet szükség. Persze ha melegszik akkor jó dolog, de egyébként nem vagyok biztos benne, hogy azt tovább muszáj forrasztani még, már mint az hűti alapból az ESP32-es IC-t. Az hogy ezt még egy további panel részhez forrasztod olyannak tűnik nekem, mint ha egy CPU-n lévő hűtőbordára még egy másik hűtőbordát tennénk, esetleg ventilátort. Az alap hűtőbordával is jó a többi már csak plusz lenne ami ha kivitelezhető jó, de nem biztos hogy kell is használni. -
Teasüti
nagyúr
válasz
Tankblock
#8914
üzenetére
Nem, ez megdöglött. Piros Led folyamatosan villog rajta, kivéve USB-re kötve.
Se 3V3-ról, se 5V-ról nem megy. Az UART0 nem válaszol se boot-oláskor a Serial monitoron, se a program feltöltésnél nem kapcsolódik (EN és IO0 vagyis a Reset és Boot gombok lenyomva előtte). Jah és melegszik az ESP modul maga is USB-ről. Ez kuka.Amúgy nem értem miért, a DevkitC tervrajzán rajta van a védődióda a Vbus-on ( D3 1N5819), így elvileg nem kellett volna tönkremennie. Hacsak a kínai nem spórolta le róla. Nem igazán tudom visszakövetni a vezetősávokat a panelen. NYÁK tervet meg nem találok róla.
-
válasz
Teasüti
#8904
üzenetére
Igen, így van ez egy sokkal egyszerűbb megoldás amit én szeretnék. Órát nem akartam újra feltalálni még akkor se ha érdekes feladat lenne
. Mindenképpen kellene egy fali óra, ezért gondoltam, hogy vigyünk bele valami pluszt amitől kicsit egyedibb lesz. Igen ez inkább egy időjárás állomás lesz ESP oldalról, csak a körítés másabb.
Egyelőre még nagyon az elején vagyok az egésznek. Hobbinak és érdekességnek jó ilyennel foglalkozni ezért kezdtem ezt. Kicsit bele kevertem a külső hálózatról történő belső hálózat elérését. Tényleg jóval egyszerűbb kiküldeni szerverre. Ezt a részét még átgondolom, ha oda érek. Most minden funkciót beletenné legszívesebben, de annak meg nem sok értelme van -
válasz
Teasüti
#8900
üzenetére
Sajnos nem sok rálátásom van a követelményekre, előírásokra amit elvártak, elektronika rész nem hozzám tartozik, én a mérés - kiértékeléssel foglalkoztam. Gyorsulás érzékelővel álló helyzetben tiltás körül 50-80 g körülieket mértünk Z irányban, de X és Y-ban is voltak azért nagy kimozdulások. A mértékére nem emlékszek mekkora volt, csak hogy van csavarodása a NYÁK-nak. Nem mondom hogy mm-es, de pont elég volt ami az elég érzékeny gyorsulás szenzort egy olyan frekvencián rázta, ahol érzékeny az érzékeny volt és ez a mérés miatt nem volt szerencsés. de csavarodása volt a panelnek ez biztos. Az se volt mindegy hogy a gyorsulás érzékelő hol helyezkedik el a panelen, milyen ragasztóval van beragasztva a NYÁK, mert nem csavarozva volt. Tehát minden apróság amit nem is gondolnánk számít. Egyébként ez céges projekt, szóval túl sok mindent nem is tudok mondani hivatalosan, lehet ez is több mint amit szabadna
ESP32 nem sokkal nagyobb mint egy ESP-01. ESP32-vel van tapasztalatom, illetve abból van is modul/development board, ezért ebben az irányban indultam el. Ez az egész projekt a tiédhez képest jóval egyszerűbb, maga az analóg óra részét nem is akartam túlbonyolítani, így ott egyszerűbb a helyzet. Lehet kapni kész mechanikát: [link]. Lesz egy fa lap abba bele lesz marva a mechanikának és a kijelzőnek + elektronikának a helye. ESP32 órában és egy kinti egységben, mind a kettő méri a hőmérsékletet, páratartalmat, Real time clock modul kiírja a dátumot. A két ESP32 kommunikál egymással, az órában lévő pedig még pluszban küldi egy honlapra az adatokat, ahol látszódna grafikonon az adat. Múltkor szóba került a kívülről való belső hálózat elérése, na most emiatt még nem tudom hogy belső hálózaton legyen az egész vagy külsőn. Esetleg thingspeak-re menjen az adat. De valami ilyen lenne az elképzelés.
Az se hülyeség amit írtál, léptetőmotor óra szerkezet, de oda akkor kellene áttétel a kismutató-nagymutató miatt, nem tudom a pontos mechanikai megvalósítás mennyire lenne komplikált, így ezt a részét inkább a profi "kínai mechanikára" bíznám
Egyelőre csak egy breadboard-on van, de megy szépen a deep sleep - wake, meg minden amit eddig ki tudtam próbálni. Mondjuk a végleges összekötéseket (kábelek, ellenállások, csatlakozók stb.) nem tudom hogyan lehet kivitelezni breadboard nélkül... Ti hogyan csináljátok?
. Akkor ez is kilőve ![;]](http://cdn.rios.hu/dl/s/v1.gif)
Eclipse alatt regiszter szinten programozod?
Új hozzászólás Aktív témák
ekkold
- Eladó alaplap + processzor + memória + hűtő
- Blackmagic Pocket Cinema Camera 4K + objektívek
- R5 5600X/32GB DDR4/6700 XT 12GB/1TB M2 P4+2TB M2 P3 SSD/Ss GX 750W/G213/Razer DA3+pad/FHD 170Hz 24"
- Xiaomi Redmi 13C 8/256 mint az új, garanciával eladó
- 14000 expo - Sony A6100 megkímélt állapotban, gyári dobozában és összes tartozékával OLVASS LEÍRÁST!
- KÉSZLETKISÖPRÉSI ULTRA GIGA AKCIÓ! CTO 0perces SKY MacBook Air 15" M4 10C/10G 16GB 1000GB 1 év gar
- GYÖNYÖRŰ iPhone 14 128GB Midnight -1 ÉV GARANCIA - Kártyafüggetlen, MS3971, 94% Akkumulátor
- Lenovo Tab M10 HD 64GB, Kártyafüggetlen, 1 Év Garanciával
- GYÖNYÖRŰ iPhone 12 mini 64GB Purple -1 ÉV GARANCIA - Kártyafüggetlen, MS3851
- Önerő nélkül is elvihető! Részletfizetés. 27 % Áfás számlával Dell Alienware QD-OLED gamer monitor
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: ATW Internet Kft.
Város: Budapest