- eSIM, a kártyamentes szabadság
- Fotók, videók mobillal
- Huawei Watch GT 5 Pro - egészség + stílus
- Milyen okostelefont vegyek?
- Apple Watch
- Bemutatkozott a Poco X7 és X7 Pro
- Samsung Galaxy A54 - türelemjáték
- Android alkalmazások - szoftver kibeszélő topik
- Samsung Galaxy A55 - új év, régi stratégia
- Samsung Galaxy A34 - plus size modell
-
Mobilarena
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
-
_q
addikt
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?
-
_q
addikt
Leesett a kódban a 9 ms valószínűleg elég, mivel 2 byte-ot olvas ki a szenzorból, külön történik a hőmérséklet és külön a páratartalom kiolvasása. Adatlap szerint 6.5 ms egy kiolvasás, ahogy linkelted, a 20 már lehet sok.
Viszont mivel freertos-ban írom a kódot, a
delay(9), közben lehet, hogy jön egy másik prioritású task ami elkezd futni. Ennek a task-nak lehet sokáig tart, mire lefut és ismét futásidőt kap a hőmérséklet kiolvasó task. Ez nem feltétlen mindig történik meg, de ha igen akkor az a ritka eset elő állhat ami nálam, hogy néhány óra/nap után történik meg az, hogy nem jó értéket küld a szenzor.Ez így mennyire lehet esélyes? Ha igen akkor hogy küszöbölhető ki?
-
_q
addikt
válasz
Tankblock
#9285
üzenetére
Nem tudom a hőmérséklet és páratartalom mérési ideje összeadódik-e, mert akkor 14 ms kell nagyjából 2 mérés között elteljen. Viszont én ezt a 9 ms-ot már korábban átírtam 20 ms-ra. a
Delayhelyett adelayMicrosecondsmiért jobb választás?Kínai paneles megoldást használok, van rajta 2 db 10k (smd 103) ellenállás és kb 10 cm-es kínai szerelt vezetékkel van összekötve, de a 3.3 tápfeszültség meg van a panelen.
Adatlapban van egy ilyen:
"After power-up, the sensor needs at most 15 ms, to be ready to start RH
and temperature measurement. " Ez alapján a 9 nem igazán elég, de a 20 amit használok már igen. Gondolom soknak nem sok, hogy elmenne közben alvó módba megint a szenzor. Viszont az egészben ami érdekes, hogy oké hogy 1-1 esetben rossz a kommunikáció, de utána miért nem áll vissza és küld jó eredményt a szenzor. Ha csak nem akad össze wifi kommunikációval a háttérben. -
_q
addikt
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.
-
_q
addikt
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. -
_q
addikt
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.
-
_q
addikt
Task kezeléssel kapcsolatos kérdésem lenne.
Ezen az oldalon van egy ilyen kijelentése:"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."
Ha ez tényleg igaz, akkor minden perifériával kapcsolatos kódot érdemes CPU0-ra tenni. Ha viszont én Wifi-vel kapcsolatos dolgot CPU0-ra teszek, I2C kommunikációt CPU1-re, és minden task-nak megadom a prioritást, akkor mi biztosítsa, hogy pl a wifi kommunikáció ne essen egybe egy I2C kommunikációval? Pl wifi core 0 prio 1, i2c core 2, prio 1. Itt a cpu1-es prioritásnak mi lesz az értelme wifi kezelés szempontból, ha ténylegesen úgy is cpu1 hajtja végre?
-
-
_q
addikt
Szerintem attól függ, hogy teljes ablak nyitás vagy bukóra nyitás a cél, emellett az is kérdés, hogy miként van megoldva. Ha valamilyen lineáris szán segítségével vagy ehhez hasonló "áttételezés" van akkor jó a DC, de egyébként DC motor nem tudná egyenletesen nyitni/zárni (PID nélkül). Léptető vagy servo motor az áttételezés miatt jobb választás lehet direkt nyitás/zárás esetén (vagy DC + PID).
Ez csak tipp, nem próbáltam, persze érdemes lehet kipróbálni DC motorral ha van kéznél az olcsósága miatt (léptető és servohoz képest). -
_q
addikt
válasz
ZTE_luky
#9172
üzenetére
Amit javasoltak kondi azt érdemes belerakni. Azon kívül ha 2 A elég neked, szintén a javasoltak szerint érdemes kicsit fölé lőni mondjuk 2.5 - 3 A-re és egy ilyen 5 V-os töltőt keresni. Ha a led és a nano is 5 V-ról megy, nem kell semmi dc dc konverter. Elegendő a hálózati adapter tápvezetékét ketté ágaztatni "Y vezetékre ahogy írtad", egyik megy a nanoba másik megy a ledekre. Az, hogy ezt az elágaztatást hogyan oldod meg rajtad áll (pl.: micro usb board, majd ezt valahogy tovább nano-hoz és a ledekhez. vagy ilyesmi, ebbe megy hálózati töltő, másik végére nano, a VCC lábat meg kivezeted a ledekhez)
-
_q
addikt
válasz
ZTE_luky
#9167
üzenetére
Töltőről azért érdemesebb, mert ha kiszámolod: [link] vagy a linkeld oldalon kitöltöd az adatokat, akkor láthatod, hogy fogyasztástól függően változik mennyit bírna egy aksi/powerbank. Azt írtad sokszor csak felvillan és akkor se az összes led, így lehet hogy napokig is tud működni, felhasználástól függ.
Ha regulátoron keresztül (USB micro vagy VIn) kapja a tápot az arduino, akkor ha nem stabil a táp akkor sincs nagy baj, mert a regulátor stabilan fogja tartani. Ha az 5 V-os bemenetre kötöd a tápot, ami nincs szabályozva, ott a mikrovezérlő mehet tönkre. Ha a táp teljesítménye kevés, akkor max nem fog a led megfelelően világítani, esetleg mikrovezérlő nem tud optimálisan működni, de tönkre nem fog menni tőle. A led akkor mehet tönkre, ha nagy áramot kap, amit nem tud már tolerálni.Tehát akkor nem probléma hogy arduinón fut a szalag árama is? tehát hogy csak usbről kap áramot az arduino, is minden azon fut át? mert ugye a rajz elcsal annyit hogy a szalag nem közvetlen az áramforráshoz van kötve hanem az arduinóról kapja az 5V-ról.
A rajz alapján powerbank felől jön a táp, ami leágazik a nano-hoz, de a táp ettől függetlenül nem a nano-tól jön, hanem a powerbank-tól.
Vagy ezt, hogyan érted?(#9170) vargalex
Megelőztél
ez nekem se egyértelmű. -
_q
addikt
Ja igazad lehet, mert az arduino honlapon a gyári panelből indulnak ki, viszont ebay, alliexpress és ás társain a kínai másolat van, ami az emberek többségének lehet, ott már el tudom képzelni, hogy nem tud annyit, mint az original.
Jó lenne tisztázni a pontos eszközök típusát, én abból indultam ki, ami a képen, illetve hozzá írt szövegből kiderült. De ahogy írtam a legbiztosabb a Vin vagy az USB bemenetről való táplálás, mert ott van regulátor, így az 5 V se okoz gondot. Vagy nem árt tudni a pontosabb paraméterét a panelnek. -
_q
addikt
válasz
ZTE_luky
#9158
üzenetére
Arduino honlap szerint, Vin 30-as bemenetre lehet kötni 6-20 V közötti áramforrást, ez a bemenet egy 5 V-os regulátorra megy, így stabilan üzemeltethető. Az 5 V-os 27-es bemeneten nincs regulátor, ezért elsősorban külső regulátoros áramkörről érdemes táplálni ezt a bemenetet, de lehet anélkül is 5 V-os tápot adni, viszont akkor közel stabil 5 V legyen. Nem tudom a powerbank amit használsz mennyire stabil, mekkora eséllyel mehet tönkre a board, szerintem jobb elővigyázatosnak lenni.
Egyébként szerintem a legegyszerűbb az lenne, ha a gyári mini usb csatlakozón keresztül kapná a tápot, mint ha számítógépről üzemeltetnéd.
Ha power bankról akarod üzemeltetni, ott gyorsan lecsökken a feszültség 5 V alá így nem túl sok ideig lenne használható ledes projekted. Érdemes lenne inkább nagyobb feszültségről üzemeltetni ha nem hálózatról menne, mondjuk 12 V. Ha mobiltöltőt használsz ott ez a gond nem jelentkezik. -
_q
addikt
válasz
Janos250
#9139
üzenetére
Magasabb szintű WEB kezelés mit jelent?
(#9141) Janos250
Én is ezen az úton indultam el, viszont ha nem akarom a weblapot folyamatosan frissíteni az adatok lekérdezésére, akkor már egy fokkal nehezebb, hogy frissüljön egy grafikon vagy egy változó értéke, de persze járható út mintakódok alapján. -
_q
addikt
Lehet hülyeség, de én amit láttam mintakódot, ott mindenhol setup()-ba volt az deep sleep küldés, én is úgy használom. Nem is nagyon van értelme loop-ba tenni, mert ha elmegy alvóba egyszer, mindig újra indul a setup(), szerintem a loop() bezavar, próbáld setup()-ba tenni az alvás indítást.
-
_q
addikt
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."
-
_q
addikt
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?
-
_q
addikt
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.)
-
_q
addikt
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. -
_q
addikt
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ó.) -
_q
addikt
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
). -
_q
addikt
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. -
_q
addikt
válasz
Teasüti
#9075
üzenetére
Igen valami ilyesmi, pontos szakszavakkal leírt megfogalmazást én se tudok.
(#9076) Teasüti
Igaz nem stream, hanem socket client esetén hasonlóan jártam, char-ba olvassák ki a fogadott adatot. Először én is a nehezebb úton indultam el, mire megtaláltam a readStringUntil('\n') opciót, ami string-ben olvas be. Érdemben sajnos nem tudok a stream-hez hozzá szólni. -
_q
addikt
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.
-
_q
addikt
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.
-
_q
addikt
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?
-
_q
addikt
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. -
_q
addikt
válasz
Janos250
#9062
üzenetére
0-ás magra raktam a wifi kliens fogadás taskot 0-ás prioritással. Semmi más nem fut rajta, legalább is általam nem, max a háttérben amiről korábban írtál 6-7 task a rendszer által futhat esetleg. A kód elkészültével a végén csak 5-10 percenként akarom hogy hőmérséklet adatot küldjön a kliens (jelenleg 2-10 másodpercekkel teszteltem), de elkerülve, hogy pont akkor történjen más művelet, mikor pont jönne a klienstől adat, minden mást a core 1-re tettem. Az hogy leterhelném a cpu-t nem gondolnám, a fogadáson kívül 1-2 konverziót csinálok csak, de azért bemásolom ide is:
void wificlientTask( void * parameter)
{
unsigned long CLIENT_TIMEOUT = 0;
int idxBatLevel = 0;
int idxTemp = 0;
int i = 0;
while(1)
{
WiFiClient client = wifiServer.available();
if (client) {
CLIENT_TIMEOUT = millis();
while (client.available() == 0) { //itt jon a hiba, timeout-al valtozo idokozonkent
if((millis() - CLIENT_TIMEOUT) > 10000) {
Serial.println(">>> Client Timeout !");
client.stop();
break;
}
}
if (client.available()) { // if there's bytes to read from the client,
String clientData = client.readStringUntil('W');
clientData = clientData + 'W';
Serial.println(clientData);
client.stop();
idxTemp = clientData.indexOf('Y'); //get the index of Y separator (25.47Y)
idxBatLevel = clientData.indexOf('W'); //get the index of W separator (3.12W)
clientTemp = clientData.substring(0, idxTemp); //25.47
clientBatLevel = clientData.substring(idxTemp+1, idxBatLevel); //3.12
Serial.print("temp: "); Serial.println(clientTemp);
Serial.print("bat: "); Serial.println(clientBatLevel);
delay(10);
}
else{
Serial.print("temp: "); Serial.println("-");
Serial.print("bat: "); Serial.println("-");
Serial.println("");
}
}
delay(10);
}
}A javasoltak alapján átraktam a változó deklarálást az elejére, hogy csak 1x történjen meg, ne minden ciklusban, illetve a client.read-et lecseréltem, hát ha az okoz gondot, de nem. (Egyébként érdekes mert én 11 karaktert küldök, még is 12-re kellett a tömböt létrehozzam a client.read-né még. client.print küldésnél a végére betesz valamilyen jelző bitet, \r, \n vagy valamit?)
"A wifi vétel elvileg pufferelt, és a 0-ás magon fut. "
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? Tegyük fel működik, hogy átteszem core 1-re a kiolvasást. Akkor a core 0-ra nem tehetek semmit? A core 1-en van ntp lekérdezés, hőmérséklet olvasás, kijelző és még a wifi kliens olvasás is ide kerülne, nem lesz ez sok a core 1-en? A 4 taskból a wifi lekérdezést ezért akartam core 0-ra tenni, hogy még is zökkenőmentesen menjen, mert a core 1 ami igaz nem időkritikus de már így is 3 taskot futtat. -
_q
addikt
válasz
Tankblock
#9060
üzenetére
Szia,
Jelenleg ezt próbálgatom, de ugyan az az eredmény, küldés fogadás között valami történik, mert a szerver nem kapja meg, időközönként timeoutot kapok a while ciklusnál. Valamiért nem csatlakozik a kliens, pedig a kliens serial monitoron nézve kiküldi az adatot, majd elmegy aludni.
WiFiClient client = wifiServer.available();
if (client) {
CLIENT_TIMEOUT = millis();
while (client.available() == 0) {
if((millis() - CLIENT_TIMEOUT) > 10000) {
Serial.println(">>> Client Timeout !");
client.stop();
break;
}
}
if (client.available()) { // if there's bytes to read from the client,
String clientData = client.readStringUntil('W');
clientData = clientData + 'W';
Serial.println(clientData);
client.stop();
... -
_q
addikt
válasz
Janos250
#9058
üzenetére
Köszi. A küldés monitorozást megcsináltam és ott minden rendben volt, valami a szerver oldalon van. Arra jutottam hogy a
while(client.available())
{
....
}okozza. Nem jól programoztam le a fogadott adat kiíratását. Így mikor küld a kliens, de a szerver nem tudja fogadni, akkor egy W bentmaradt és azt írja ki illetve üres sort, hogy nincs adat. Így már csak az maradt kérdés, vajon miért nem sikerült továbbítani a kliensnek az adatot. 10 db wifi hálózat érhető el , lehet bezavarnak egymásnak és teljesen normális az, hogy nem mindig sikerül a kliensnek wifi routeren kersztül a szervernek elküldeni az adatot?
-
_q
addikt
Köszi a tippet és (#9056) Janos250-nak is. Nem konkrétan ezzel a sorral volt a gond, de a read_raw-hoz manuálisan hozzá adom a 'W'-t pár sorral lejjebb és ott már nem kellene az i indexet tovább léptetni, amit én viszont megtettem, így ott valóban túllépte a tömb a max elemszámát. Most ez a része kb. 20 perces futás alatt nem dobott hibát, cserébe ugyan itt előjött más
Ez a hiba. A serial monitoron jön egy 0-s index, illetve egy üres sor, mint ha nem küldene semmi adatot a kliens, majd amikor szétbontom a hőmérsékletet és az aksi szintet, az aksi szint üres, a hőmérséklet egy W. Ezek alapján az látszik, hogy valószínűleg küld valamit a kliens, különben be se lépne a fogadás programrészbe a szerver, viszont csak egy W-t.
Lehet elveszik az adat küldés közben? Érdemes lenne szervertől visszaküldenem az adatot a kliensnek, megnézni egyezik-e ha igen akkor oké, ha nem akkor küldje ismét a kliens? Változó hogy kb. 10-20-30 küldésenként jön elő, a küldés 5 másodpercenként megy. -
_q
addikt
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. -
_q
addikt
válasz
Teasüti
#9040
üzenetére
Elnézést, ha nem egyértelműen fogalmaztam. Illetve a legvégén oda írtam direkt, hogy ha valami nem jó akkor egész nyugodtan javítsatok ki.
Igen nálad került szóba az I2C és mivel ott se voltam biztos benne, most se tudom az okát gondoltam megint szóba hozom és akkor kiötletelünk valamit. Most már akkor tudom legalább, hogy megoldható nagyobb távon is aminek örülök
-
_q
addikt
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.
-
_q
addikt
É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
-
_q
addikt
válasz
Teasüti
#9026
üzenetére
Én nem mértem rá szkóppal. Nagyon más okát pedig nem látom azon kívül, hogy a vezeték hossza számít. Egyébként kínai jumper wire köteget használtam, aminek a minősége megkérdőjelezhető akár, illetve próbapanelen toldottam meg a 10 cm -10 cm távolságot, mert egyben nem volt 20 cm-es vezetékem. Elképzelhető hogy ezek együtt okozták a gondot.
(#9025) aryes
Azt is próbáltam hogy az első 10 cm és az utána lévő 10 cm közé próbapanelen kötöttem még egy-egy felhúzó ellenállást. Ez se igazán javított, igaz az ellenállás értékét nem tudom, panelen volt 2 egyforma, talán 1k lehetett. -
_q
addikt
válasz
Teasüti
#9015
üzenetére
Miért lenne a mikrovezérlőre kötve az aksi feszültsége? A rajz alapján ha a GPIO alacsony akkor a Q1 nem kapcsol, GPIO GND-n lesz. Ha GPIO magas, Q1 kapcsol, Q2-t és 100k-t lehúzza GND-re.
Mivel a VGS -0.7-1.5 V és ha mérünk, akkor Q2 GND-n lesz azaz 0V-on, így kapcsolni fog, nem 3 V-ra kerül a Q2 Gate.
-
_q
addikt
Utánajártam, ez kellene:
BATT_EN-el vezérled. LOW nincs mérés HIGH méri a feszültséget. Ha kevesebb áramkörrel akarod akkor a Q1 és alsó 100k nem kell, ez esetben a Q2-100k között van a BATT_EN, ekkor fordított logika lesz. LOW esetben mér, HIGH esetben nem mér. Feszültség osztót pedig úgy érdemes megválasztani, hogy passzoljon az aksidhoz.
-
_q
addikt
válasz
Janos250
#9002
üzenetére
Köszi a linket. Elég hasznos és tök jó leírás.
(#9000) Teasüti
Már nem emlékszek sajnos a linkre, de volt egy feszültség monitorozós projekt, ott
a következőt használták: 2N7000. Itt 0.3-3V között kapcsolható a FET. Ez ha jól értem akkor egy GPIO ki-be kapcsolással vezérelhető, így nem kell a plusz tranzisztoros kapcsolás. Ha más FET van használva, aminél nem kapcsolható a FET direkt módon, ott lehet kell plusz tranzisztor. -
_q
addikt
É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.
-
_q
addikt
Wifi Client és Server kódokat próbálgatok. 8 byte küldése az alap mintákban meg van, de ha több adatot akarok küldeni, illetve tört számot akkor azt hogyan tudnám megoldani? Konkrétan egy hőmérséklet és egy feszültség szint lenne küldve a szerver felé és jó lenne egy minta küldésre és fogadásra is.
(#8990) AcCEsS
Én a következő képpen tenném (bal ábra): [link]
Az ellenállással pedig leosztanám mondjuk 2 V-ra az aksi feszültségét, majd a mérésnél a képletbe korrigálnám az eredményt. -
_q
addikt
válasz
vargalex
#8974
üzenetére
Rosszul fogalmaztam, igen a kívülről történő elérésre gondoltam, hogy még nem tudom kelleni fog-e. Ha thingspeak-re szeretnék valamit feltenni oda gondolom nem kell. Más mondjuk nem jut eszembe hogyan tudnám megoldani az adatok megjelenítését grafikonon.
(#8975) Teasüti
Igazad van hogy jó lenne olvasni, csak jelenleg nem sok fogalmam van arról, hogy mit is olvassak. Azt tudom mit szeretnék elérni és rá tudnék keresni virágnyelven, de az kevés ahhoz, valahogyan szakmaibban kellene keresgéljek. Viszont most már pár szakmai kifejezés szóba jött, ezek menték keresgélek. Csak megint előrébb járok fejben, mint gyakorlatban -
_q
addikt
válasz
vargalex
#8972
üzenetére
Nagyon köszönöm, keveredtek bennem a fogalmak.
Remélem a türelmed nem fogyasztottam el teljesen Első körben nem akarom kifelé az adatokat küldeni, ha majd mégis szeretném akkor a korábban szóba került módon meg tudom tenni (digit felhívom és megkérem intézkedjenek, vagy nyitok egy portot kifelé a routeren).
Erre majd még visszajövök kérdezni ha eljutok oda. -
_q
addikt
-
_q
addikt
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. -
_q
addikt
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. -
_q
addikt
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.
-
_q
addikt
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.
-
_q
addikt
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? -
_q
addikt
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.
-
_q
addikt
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. -
_q
addikt
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. -
_q
addikt
válasz
Teasüti
#8920
üzenetére
Jó lesz az
én mondjuk a DOIT development board alapján csinálom, ott van egy 100 nF-os kondi a wroom32 mellett, amúgy tényleg csak max a gomb és hozzá ellenállás, kondi kell. Ez meg kiváltható esetleg tüskével, amit GND-re húzol programozásnál. Valószínű én maradok a gomb megoldása mellett az első panelnél.Még egyelőre adatlapozok, nem gondolkoztam még beültetésen. Illetve nem is figyeltem a hűtőpadot.
Nem tudom ezeknél a kínai paneleknél vajon be van forrasztva? -
_q
addikt
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 -
_q
addikt
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 -
_q
addikt
válasz
Teasüti
#8898
üzenetére
Foglalkozunk szimulációkkal, illetve motoron (főleg 3 hengeres) csináltunk csomó vibrációs mérést. Mi esetünkben a nyák mérete kb 5x5 cm mindenféle automotive előírásokkal. Meglepő milyen vibrációkra képes a nyák, sőt mindenféle megtámasztásokkal is próbálkoztunk. Rezonál, hajlik amit csak lehet. Persze ha csak a nyákot nézzük jobb az eredmény szemben ha a nyákot berakjuk egy házba. Na ott a ház tud csak igazán szép eredményeket mutatni (nálunk üvegszálas házban van a nyák), nagyon sokat hozzá ad a vibrációhoz. Sokkal rosszabb az eredmény mint ház nélkül. Legjobb eredmény akkor van, ha konkrétan rá lenne ragasztva a nyák motor vázra, de a gyakorlatban ez nem annyira kivitelezhető dolog a külső behatások miatt se. Mivel nálad nincs ekkora jelentősége, így valószínű minden rendben lesz. Ha még se, akkor érdemes visszatérni a vibrációra ismét.
Analóg (mutatós) óra lenne. Valami ilyen: [link]
Annyi módosítással, hogy dátumot és hőmérsékletet mutatna a kijelzőn, lenne egy kinti egység, így kinti-benti hőmérséklet látszódna. Ezt pedig valahogy feldolgoznám, hogy látszódjon minimum 1 évre visszamenőleg a hőmérséklet, esetleg valamilyen telefonos hozzáférést az adatokhoz lenne még.
ESP-01 kisebb mérete miatt lenne jobb szerinted? -
_q
addikt
válasz
Teasüti
#8896
üzenetére
Szuper a panel
Igazad van, hogy kész modulokból egyszerűbb meg nem feltétlen éri meg teljesen újból felépíteni egy dev modul szerűt. Én azért szeretném külön, mert tanulok is így talán belőle, érdekel is a dolog, plusz nagyon kicsibe kellene megvalósítani az egészet. Egy analóg órát szeretnék fából, amin van egy kijelző 3.5"-os. Itt hátra felé nem nagyon tud kilógni semmi, ha nem szeretném, hogy túlzottan elálljon a faltól az egész. A hátlapot lehetne kimarni nagyobb felületen. Első körben megpróbálom így ha nem megy akkor marad a moduláris megoldás. Na meg lehet 2. projektnek már nem akarok én se szívni Így elsőre még van kedvem. Ja meg én a programozó részt nem is tenném a panelre, szintén helyet megtakarítva. azt egy USB-s modullal oldanám meg.Ha jól látom gyorsulás érzékelő van középen. Nem tudom ennek a jelét mire szeretnéd használni, de gondolom ez is a motorodon lesz. A motoron a vibráció elég nagy, a gyorsulás érzékelő nagyon érzékeny ezekre a vibrációkra. Ha nagyon pontos számításokat szeretnél valamihez, akkor az egyoldali felfogatás nem biztos hogy a legjobb megoldás. Maga a fő nyák is középen rezonálni fog (legalább 4 felfogató pont jó lenne, de még akkor se lehet elkerülni a vibrációt), plusz a gyorsulás érzékelő még egy másik nyákon van rajta.
-
_q
addikt
-
_q
addikt
válasz
Janos250
#8827
üzenetére
Köszi a részletes kifejtést.
Azt nem tudod esetleg, hogy a 2 mag egyben 240 MHz-e, tehát külön 120-120 MHz-en fog menni?
Én is olvastam, hogy 32 kHz-es kristályt 2 GPIO feláldozásával hozzá lehet kötni az ESP32-höz. Viszont fórumon azt írták, hogy kicsit bugos, illetve annyira jó minta kód erre sincs. Úgy érzem el kell engednem ezt a részt
Egyébként amit meg szeretnék valósítani, annak egyik részét az óra kiíratása képezné. Mivel nekem nem kell semmilyen dátum, csak egyedül az óra, perc, másodperc kiíratás, ezért nem szeretnék külső RTC modult használni. ESP32 időzítővel generálok másodpercenként egy megszakítást és ebből számolom a percet, órát. Na és itt jön a kérdés ami miatt keresgéltem honnan veszi a CPU az órajelet és az mennyire lehet pontos (erre még mindig nem találtam sajnos választ a neten, órajel pontosságról nincs információd?
), mert a timer a CPU órajelet osztja le és generál megszakítást. Eddigi 1 napos teszt alapján másodperc alapon úgy látom, hogy pontos és nem késik. Persze 1 nap az kevés, ha mikrosec vagy kisebb késés van akkor ahhoz jóval több nap/hónap kell hogy kiderüljön.
Bizonyos részeket egyszerűbb volt STM32-vel megvalósítani, de igazad van ott is kell azért sokszor adatlapozni. Jó lenne ha fejlesztenék a kevésbé használt részeket is ESP32-nél. Vagy ha másként nem, akkor STM-el kell megvalósítani, az általánosabb dolgoknál mehet ESP32. -
_q
addikt
Nekem ESP32-nél volt hogy nem használtam 2-3 hetet. Most ismét elővettem és vagy eltűnt a drivere az USB-TTL chipnek vagy nem tudom mi történt, de újra kellett telepíteni. Igaz nálam nem volt ilyen hibaüzenet, de egy próbát megérhet az FTDI chip driver újratelepítése, ha van újabb verzió akkor azzal.
-
_q
addikt
válasz
Janos250
#8820
üzenetére
Adatlap szerint: "7-stage pipeline to support the clock frequency of up to 240 MHz (160 MHz for ESP32-S0WD and ESP32-D2WD)" Nem tudom ESP32S az melyikhez tartozik, mert így lehet 160 MHz is, illetve egyenként 160 vagy 240, esetleg a kettő együtt adja ki. Utóbbira gondolok amiből jön a következő kérdés.
Ha nem RTOS-t használok, akkor nem lehet tudni melyik cpu-t használja a program futtatására? Lehet csak egyik, de lehet akár mind a kettő is? Ezt jó lenne tudni, mert nem mindegy egy számításigényes program esetén.
DMA-val nem nagyon találtam mintákat sajnos, kíváncsiságból pedig jó lenne.Ezek közül jelenleg csak az órajel a kérdéses, illetve az, hogy azt honnan veszi. A többi csak érdekelne, mert ki tudja mikor jöhetne jól. Viszont kezd körvonalazódni, hogy a gyakori feladatokra van megírva az arduino IDE, egyébre mint a DMA vagy órajel változtatás már nehézkesebb egy STM32-höz képest. Mivel nem rég szóba került, hogy egy 2 éves hardver esetén még mindig nincs meg minden támogatottság szoftver oldalról, vagy teljesen vagy részben pl bluetotoh mesh, de most az órajel és a DMA is nekem úgy tűnik hasonló cipőmen jár, kicsit sajnálom, mert egyébként jó eszköz az ESP32.
(#8819) Tankblock
Köszi, ez így szimpatikus. Ha eljutok eddig a projektemben, akkor rá fogok nézni jobban és lehet akkor lesz majd még kérdésem. -
_q
addikt
Nézegetem az órajeleket, timer-t. Kíváncsi voltam, hogy mit használ alapból a timer-hez. Adatlap szerint a cpu órajelét használja. Azt hogy a CPU mit használ elvileg be lehet állítani de arduino alatt nem találtam meg, hogyan lehet változtatni, hogy mit használjon a CPU. Ahogy néztem van egy 40 Mhz-es kristály a shield alatt. Tehát lehet belső 8 MHz, külső 40 MHz és ha külsőleg csatlakoztatni 32 kHz-es kristály.
Azt, hogy ezeket hogyan lehet beállítani, melyiket használja, ne menjen mondjuk 160 MHz-el, hanem csak 80 MHz-el a cpu arudino alatt hogyan lehet beállítani? Közben pedig még egy kérdés jutott eszembe. Ha nem rtos-ban programozok, akkor magától választja ki melyik mag dolgozza fel a kódot vagy csak egyiket használja? A 160 MHz ki van használva valahogyan?
Még egy dolog, a DMA-t támogatja az ESP, de arduinora szintén nem találtam kódot. Erre sincs példa?
Így hirtelen sok a kérdés, remélem sikerül mindre választ kapni. Egyre inkább előjön, hogy lehet még se mindenre a legjobb arduino-ban a programozás és korlátokba ütközök?
-
-
_q
addikt
válasz
Janos250
#8797
üzenetére
Ez lehet az?
Tehát esetemben:
uint8_t ServerIPlocal[4] {192,168,1,140} ; //Node static IP kinek mi
uint8_t gatewayIPlocal[4] {100,73,11,43} ; // ami neked
uint8_t subnetIPlocal[4] {255,255,255,255} ;Van egy olyan sor a router manual-ban, amivel be tudok böngészőből is lépni a router beállításaiba. Esetleg a gatewayIPlocal címe az lehet? Ez: 192.168.2.1
-
-
_q
addikt
válasz
Tankblock
#8763
üzenetére
Ha jól értem akkor a feszültség osztót úgy lenne jó beállítani, hogy mondjuk max 3V-ot lehessen mérni rajta, majd ezt egy képlettel belőni, hogy ha 3 V-ot mér az valójában 3,6V vagy éppen 5 V attól függ mivel akarjuk használni. Így a mikrovezérlő ADC portján max 3 V lesz a mérhető, és marad 0.6 V buffer túlfeszültség ellen?
Ha már itt tartunk miből jöhet túlfeszültség?
-
_q
addikt
válasz
Tankblock
#8740
üzenetére
Miért kell feszültségosztó, miért nem lehet direktben rákötni, mérni a konverzió értékét, majd abból visszaszámolni a feszültséget?
Közben olvastam (#8747) aryes válaszát is. Tehát ha 3.3V-os lipo-t használunk nem kell feszültség osztó, csak mondjuk egy 5V -os esetében.
ez nekem se egyértelmű.
. Akkor ez is kilőve 
).![;]](http://cdn.rios.hu/dl/s/v1.gif)
Eclipse alatt regiszter szinten programozod?
. 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.
Új hozzászólás Aktív témák
Hirdetés
ekkold
- Csere-Beszámítás! Asrock Challanger B580 12GB GDDR6 Videokártya! Bemutató Darab!
- Csere-Beszámítás! Sapphire Pure RX 7700XT 12GB GDDR6 Videokártya! Bemutató Darab!
- Csere-Beszámítás! Sapphire Nitro+ RX 7800 XT 16GB GDDR6 Videokártya! Bemutató Darab!
- Csere-Beszámítás! Asus Prime RTX 5060Ti 16GB GDDR7 Videokártya! Bemutató darab!
- Csere-Beszámítás! Asus Tuf RTX 5070Ti 16GB GDDR7 Videokártya! Bemutató darab!
- ÁRGARANCIA!Épített KomPhone Ryzen 5 5600X 16/32/64GB RAM RX 7600 8GB GAMER PC termékbeszámítással
- Azonnali készpénzes Microsoft XBOX Series S és Series X felvásárlás személyesen/csomagküldéssel
- Xiaomi Redmi Note 13 256GB, Kártyafüggetlen, 1 Év Garanciával
- Bomba ár! Lenovo ThinkPad P50 - i7-HQ I 16GB I 256SSD I Nvidia I 15,6" FHD I Cam I W10 I Gari!
- BESZÁMÍTÁS! ASUS ROG Ally Z1 Extreme 512GB SSD játékkonzol garanciával hibátlan működéssel
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged