- Milyen okostelefont vegyek?
- Mobil flották
- Milyen GPS-t vegyek?
- Samsung Galaxy A55 - új év, régi stratégia
- Redmi Watch 5 - formás, de egyszerű
- Samsung Galaxy Watch4 és Watch4 Classic - próbawearzió
- Második bétánál jár a One UI 8
- Megvan, milyen chipet használ a Pura 80 Ultra
- Garmin Instinct – küldetés teljesítve
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
-
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
#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
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
). -
-
Janos250
őstag
válasz
Teasüti
#9076
üzenetére
"Ti tudtátok, hogy a Stream osztályban ilyen függvények vannak, hogy readStringUntil(), parseInt(), stb?"
A HardwareSerial.cpp-ben ez van:
HardwareSerial Serial(0);
Vagyis a HardwareSerial típusú Serial objektum tőlünk függetlenül "automatikusan" létrehozásra kerül.A HardwareSerial.h-ban viszont ez van:
class HardwareSerial: public Stream
Vagyis a HardwareSerial osztály örökli a Stream osztály public és protected tagfüggvényeit, adattagjait.A Stream.h-ban viszont ez van:
class Stream: public Print
Vagyis a Stream osztály meg örököl a Print osztálytól, így közvetve a HardwareSerial is örökol a Print osztályból. Ezért lehet pl. Serial.print() és még egy csomó.A readStringUntil az a Stream osztályból öröklődik, szintén egy csomó egyébbel együtt.
Célszerű végigbogarászni a
HardwareSerial.h
Stream.h
Print.h
fájlokat, kincseket lehet bennük találni.Ezért értelmesek pl. az alábbiak:
Serial.available();
Serial.read();
Serial.peek();
Serial.flush();
Serial.setTimeout(1000);
Serial.find("vege");
Serial.find(10);
Serial.find("vege",10);
char c ;
Serial.find(c);
char charBuffer[20];
Serial.readBytesUntil(c,charBuffer,10);
uint8_t uint8_tBuffer[20];
Serial.readBytesUntil(c,uint8_tBuffer,10);
String str1;
str1 = Serial.readString();
str1 = Serial.readStringUntil(c); -
Tankblock
aktív tag
válasz
Teasüti
#9079
üzenetére
nem a
stream(stream)programkód azt jelenti hogy amikor inicializálod akkor a bejövő cím értékét bemásolja a class stream nevű változójába.
[Member initialization in constructors]
Sztem a stream object nincs definálva, hol lehet megnézni a könyvtárat?
-
Tankblock
aktív tag
-
_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
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.
-
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.......
-
_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
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. -
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...
-
_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.
-
Janos250
őstag
válasz
Teasüti
#8983
üzenetére
Elég sokban. Mindkettőnek megvan a maga területe. Az analizátor csak digitális jelek értelmezésére képes, de arra igen jól. Van benne néhány protocol, ezért aszerint is ki lehet íratni a jobb oldali képernyő részleten.
Régebben egyszer a címezhető leddel kapcsolatban tettem fel egy képernyő képet, de most nem találom, de a Saleae videója elég jól mutatja. Viszont vigyázni kell, hogy melyik verziójú szoftvert teszed fel, mert a legújabb végleges verziók nem mennek a klónnal. Az eredetivel persze igen.A szkóphoz hasonlóan kell használni, bekötni. Itt is csak belehallgatsz. Szintén elég nagy a bemeneti impedancia, pontosan nem tudom mennyi, de nekem eddig nem okozott gondot.
" Open-drain, open-collector?" Azok kimenetek.
-
Tankblock
aktív tag
válasz
Teasüti
#8937
üzenetére
Nem kell nyomni semmit.
Ezen csinálom a IR Remote projectemet egy ideje (már ha lenne rá időm...)
Igaz nem pogo pin de jó. Kivenni betenni nagyon okés, 100-as batchet nem ezzel csinálnám....
10-20 még ok, fejleszteni tökéletes.
Most nézem h a képhez képest az enyémen van még 1 6 lábas SMD ic. Nem tudom leolvasni, lehet h dual package MOSFET és akkor itt van a kutya elásva. pedig a linket a rendelésemből vettem ki.
-
Janos250
őstag
válasz
Teasüti
#8922
üzenetére
"Ha generic FTDI csatolót használok, ahhoz meg kellenek a gombok is."
Elvileg nem, mert azon is ott van a DTR és RTS láb.
A "ck" programozási mód éppen azért olyan népszerű, mert kiküldi a DTR és RTS lábakon a boot módba állításhoz szükséges jeleket. Ha beköti az ember. Ha nem, akkor kézzel kell boot módba állítani kapcsolóval. Tehát, ha a converteren van DTR, RTS, akkor bekötve nem kell gomb, ha nincs rajta, vagy nem kötöd be, akkor kell gomb. Mellesleg én kézzel szoktam boot módba állítani. -
_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. -
válasz
Teasüti
#8922
üzenetére
"Én már próbáltam pákával alulról beforrasztani hűtőpadot, nekem nem működött a dolog."
Neki se sikerült, a végén írja, hogy megsütötte a cpu-t." Én mondjuk tuti ezzel kezdtem volna a többi láb előtt, ha sikerül akkor erősen megtartja a chip-et, ha meg nem sikerül akkor könnyen le lehet szedni."
Teljesen igaz, nem is értem miért nem így csinálta. Elég lett volna csak addig melegíteni, amíg látja, hogy megtartja a kötés, így nem sült volna oda a cucc. -
_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? -
-
válasz
Teasüti
#8912
üzenetére
9 tengelyest használok, de a dmp nem használja az iránytű adatait a számoláshoz. Próbáltam már az említett lib 6axis és 9axis .h fájljával is, és ugyanúgy kúszik az elején. A 9axis talán előbb megáll és később pontosabb is, de teszteltem mágnessel és egyáltalán nincs hatással a dmp-re.
Csak gondoltam hátha mára fejlődött a tudomány, kb. egy éve játszottam vele utoljára. -
válasz
Teasüti
#8910
üzenetére
Ez jó, én is ezzel csinálom a légegér projektemet.
Egy baja van csak: inicializálás után vagy másfél perc kell neki, hogy abbahagyja a pörgést (yaw/z tengely körül) és beálljon egy fix irányba, addig igazából használhatatlan. Ezzel vannak tapasztalataid? X/Y tengely mentén elég stabil az elejétől kezdve, de ott igazából az acc. szenzor adatait használja.
Ha ezt egy motoron fogod használni, az azt jelenti, hogy gyújtás után másfél percig elég véletlenszerű adatokat fogsz kapni.
Ehhez hozzájön, hogy kis hőmérséklet változásokra is vadul elkezd kúszni a Z tengely, ami motoron a motor hője/napsütés hatására is előfordulhat. -
_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.
-
Janos250
őstag
válasz
Teasüti
#8890
üzenetére
"a flash memóriának fixen le vannak fogva azok a portok, amin pl az UART2 is van."
Az UART2 (más elnevezéssel UART1, ha 0-val kezdjük, ahogy a manual is teszi) mehet a default lábakra,
de Te is megadhatod, hogy hova menjen. Tehát az UART portok (is) azon a lábakon vannak, amelyiken akarod.
Ezt szoftverből tudod megadni, de a fkash memória külön IC, tehát az definiált, hogy a modulon belül melyik lábhoz van kötve.
A perifériák irányítgatásáról (GPIO matrix) is van egy félben lévő leírásom, majd ha kész lesz, felteszem a netre az egyéb ESP32-es szösszeneteim sorába."ki honnan veszi az ESP32-ket?"
Én is mindenkinek azt javasolom, hogy az ESP-WROOM32 alapút vegye!Apropó, nyák! Úgy alakult, hogy nekem is kell sajátot csinálnom. Te egyszer leírtad, hogy hol csináltatod, de nem találom. Küldenél egy linket újra,
Kösz. -
Janos250
őstag
válasz
Teasüti
#8865
üzenetére
Erre gondoltál?
/* ESP32 3 UARTs */
// HardwareSerial Serial(0); ez nem kell, mert a HardwareSerial,cpp fájlban benne van,
// automatikusan pédányosítódik
HardwareSerial Serial1(1);
HardwareSerial Serial2(2);
// Choose two free pins
#define SERIAL1_RXPIN 12
#define SERIAL1_TXPIN 13
void setup() {
Serial.begin(115200);
Serial1.begin(9600, SERIAL_8N1, SERIAL1_RXPIN, SERIAL1_TXPIN);
Serial2.begin(4800); // pin 16=RX, pin 17=TX
}A begin-ben lehet lábat megadni.
-
Janos250
őstag
válasz
Teasüti
#8862
üzenetére
Elővettem egyet (doit , ESP32 devkit V1, mert ez van kéznél)
Van rajta egy sárga 107J tantál kondenzátor (https://www.ebay.com/itm/10PCS-6-3V-100UF-B-case-107J-10-SMD-Tantalum-Capacitors-3-5mm-2-8mm/391354380476?hash=item5b1e89f0bc:g:y5QAAOSw5dNWhitt)
Mellette két kisebb kondi felirat nélkül
Az USB csati kozelében látok egy kondit, egy fekete nemtudommit, egy csomó ellemállót, 2 db. J3Y tranyót, és két ledet.
A tokozott hibridben (ESP-WROOM-32) a kapcs. rajz alapján van több mint egy tucat kondi. -
-
Tankblock
aktív tag
válasz
Teasüti
#8775
üzenetére
A MESH egy hálózati topológia. A HW -nek elvileg képesnek kellene lennie rá. Az ESP32 egyértelműen a Wifire és a Bluetooth 4LE épített. Ezek számomra a használati értékét növelik. Simán el tudnám képelni, hogy a meglévő SonoFF Touch ba panelt cserélek ESP32 re és átugrok BLE-MESH networkre, vagy a mostanival Wifi MESH re. Még filózok rajta, mert a 8255 is képes Wifi-Mesh re. A Gateway modul a problémás ami összeköti a MESH hálózatot a saját Networkkel/felhővel/serverrel....
Arra még nem láttam - számomra - jó megoldást.
-
Janos250
őstag
válasz
Teasüti
#8736
üzenetére
"legkevésbé se ideális megoldás peer-to-peer használatra, az túl kényelmetlen és kompromisszumos a vezérlő eszközön, valamint bonyolultabb is a BT-nél"
Igen, WiFi-n küldeni P2P egy karaktert, bizony nagyon bonyolult:client.write(C);
Én a WiFi-t használom, de persze a BT is ugyanolyan jó, ha nem kell net. -
gyapo11
őstag
válasz
Teasüti
#8736
üzenetére
A gyakorlatban milyen a BT? Rendszeresen használok BT fejhallgatót androidos telóval. Bekapcsolom a fejhallgatót, vételkész. Bekapcsolom a telón a BT-t, és van vagy 4-6 másdoperc, mire megszólal a csippanás, hogy a párosítás megtörtént. Ezt egy ajtónál állva esőben pl. nem annyira jó móka, sokkal jobban tetszene az autók távirányítójához hasonló azonnali vezérlés. Gondolom a wifi se ilyen.
-
Tankblock
aktív tag
válasz
Teasüti
#8718
üzenetére
Hello,
Mivel c++ igen, ez az iostream rá van rakva arra a serial kimenetre amellyel programozod is.
Elméletileg nincs akadálya hogy a másik 2 UART hoz is lehessen iostreamet definiállni.A kérdés mindig az hogy mennyire fog a kód olvashatóság rovására menni.
Azt kihagytam hogy ne használjátok az
endlhelyette a jó öreg\nMagyarázat az hogy a endl definíciója tartalmaz mindig egy flush parancsot is és nem minden esetben szerencsés ez.
A valami típusa meg convertálhatónak kell lennie stringgé.
-
Janos250
őstag
válasz
Teasüti
#8647
üzenetére
Attól függ, mit értünk protokoll hiba alatt.
Az elején kiküld a gép az ESP felé néhány bájtot, ebből állapítja meg az ESP a baudrate-et. Úgy látszik, hogy amikor komplett csomagot küld, akkor nem minden bájt elejétől kezdi a szinkront, hanem "számolja", és ha hosszú a csomag, akkor kvarc nélküli lapokon elcsúszhat.
Az megoldás, ha ez ember az esptool.py-ban lecsökkenti az adatcsomag hosszát. Akkor viszont a bin fájlt kell exportálni, és az esptool.py-al kell feltölteni. Le lehetne fordítani esptoll.exe-re - elvileg. Nekem nem sikerült működőképes verziót varázsolni.
Kipróbáltam alacsonyabb baudrate-el, de úgy meg az elején kiakadt. -
Janos250
őstag
válasz
Teasüti
#8633
üzenetére
Általános tapasztalatom:
Ha a program nem úgy működik kiíratással, vagy más függvények meghívása után, akkor a tömb indexe fut ki a tartományból, amit ugye a program nem ellenőriz. Pedig már a programozási anyanyelvemen (Algol60) is ellenőrizte a program az indexet. Úgy tudom, valami kapcsolóval ki lehet kényszeríteni az index ellenőrzést ennél a fordítónál is, de ehhez nem értek, de talán valaki igen.Az adott problémánál, ha a j minusz 1 lesz, akkor az ugyebár az uint8_t miatt a 255. elemet jelenti. Ha az létezik, mert akkorára van deklarálva, akkor abba ír, ha nem, akkor meg az más által használt terület, de ő bambán oda ír.
-
-
-
válasz
Teasüti
#8622
üzenetére
Próbáld a soros kommunikációt más bitrátára állítani! Olvastam, hogy bizonyos bitrátáknál a processzor órajelétől függően pár %-os eltérés lehet a beállított értékhez képest, és már jártam is így Bluetooth modullal, hibás karaktereket küldött bizonyos bitrátánál, hiába volt a gépen ugyanaz beállítva. Hátha téged is ez viccel meg.
-
vargalex
félisten
válasz
Teasüti
#8613
üzenetére
Látom, meglett a megoldás. Az ok pedig szerintem az, hogy C-ben változó (így ugye a buff tömböd esetében is) deklaráláskor nincs inicializálás. Egyszerűen egy memória területre fog mutatni, amiben valamilyen érték lesz. Érdemes kézzel inicializálni akár az általad használt módon, akár a
bzero(buff, sizeof(buff));hívással.
Szerk: Látom, ezt már megbeszéltétek. Én azt gondolom, hogy bootkor inicializálja a memória területeket (vagy ugye teljes áramtalanításkor elveszti úgyis a tartalmát), amiből serial print-kor fog még felhasználni (majd felszabatítani úja inicializálás nélkül), míg debug nélkül nem. Azaz debug esetén más lesz ugyan azon a RAM területen, mint nélküle.
-
válasz
Teasüti
#8613
üzenetére
A buf és a buff is helyi változó, a dinamikus változó területen jön létre, elképzelhető, hogy minden függvényhíváskor új ram területre kerül. Se létrehozáskor, se törléskor nincs nullázva a terület, tehát valószínűleg az előzőleg oda beírt adatok maradékát olvasod vissza.
-
_q
addikt
válasz
Teasüti
#8612
üzenetére
Köszi kipróbálom.
(#8613) Teasüti
Ehhez annyi megjegyzésem lenne, hogy én úgy tudom nem nagyon szokták az if-et úgy használni, ahogy te, tehát hogy nincs ott hogy _debug == 1. Ezt képes a fordító esetleg rosszul fordítani. Van a scram vagy hasonló programozási elv/módszertan ami direkt ki is zárja. Nem mondom hogy mindig gondot okoz, de tud furcsaságokat generálni bizonyos feltételek mellett. -
Janos250
őstag
válasz
Teasüti
#8597
üzenetére
Én arduino alatt az arduino környezetet értettem.
Volt az interneten valóban, aki egy arduino lapon keresztül programozta, de erre nem igazán tudtam rájönni, hogyan? Mit hova kötsz, milyen programot teszel az arduino lapra, a lefordított kész fájlt rakod fel, vagy hogyan csinálod? -
Janos250
őstag
válasz
Teasüti
#8592
üzenetére
A Sonoff újabb eszközeiben a memóriának nem csupán a mérete más, hanem az elérés típusa is.
A régebbi Sonoff cuccokban az elérést DIO-ra kellett állítani, de az ÚJABB, UGYANOLYAN TÍPUSNEVŰ Sonoffokban DOUT-ra. Ha így állítja be az emberfia, akkor megy az ESP8266 kijelöléssel is.
Ettől függetlenül egyes típusokkal vannak gondjaim, de ez majd egy külön kérdés lesz mindjárt. -
-
_q
addikt
válasz
Teasüti
#8576
üzenetére
A motorról olvastam, a konyhapult világításról nem sok minden van, pl miért kell ATX táp, ami elég nagy. Amúgy a videó nem elérhető, legalább is nekem azt írja ki amikor rámegyek a linkre. Egyébként miért jó a színhőmérsékletet változtatni a konyhapultnál, fehér és sárga között lehet módosítani?
-
_q
addikt
válasz
Teasüti
#8572
üzenetére
Én azt hittem, hogy ez valami teljesen új dolog, ezek szerint annyira nem
Végül úgy oldottad meg, hogy az atmega-ból kivezetted egy vezetékkel a touch interfész portot és a végére forrasztottál egy réz felületet, azt pedig rátetted az alumínium házra amiben a ledek voltak?
-
_q
addikt
válasz
Teasüti
#8567
üzenetére
Igen de amikor túl vagy a tesztelésen és meg szeretnéd építeni az adott projektet, oda nem vezetékeket raksz gondolom. Ezért kérdeztem, hogy mondjuk ami helyettesít 2 nyomógombot, de csak magát a kapacitív felületet biztosítja van-e, mert jó hogy támogatja az ESP32, de amiket találtam azoknál mind van plusz elektronika ami kezeli az érzékelést, viszont ESP-nél már benne van a mikrovezérlőben, így csak egy felület kellene hozzá.
-
_q
addikt
válasz
Teasüti
#8563
üzenetére
Igen növelve 100 ms-nál javult minimálisan, de még lehet növelem, szerencsére nem kell gyors reakció.
A korábban (#8547) Atti777 által linkelt megoldás esetén ESP32-vel hogyan lehetne kivitelizn. Arra gondolok, hogy ESP32 alapból támogatja a kapacitív bemenetet, így a linkelt panel elhagyható, de milyen felületet lehet hozzá használni egy PCB-n? Egy sima kapacitív felülettel ellátott PCB kell hozzá?
viszont ez így már jónak kellene legyen, csak nagy helyet foglalna el a panelen.
. Akkor ez is kilőve 
).
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Eclipse alatt regiszter szinten programozod?
Nem tudom milyen lehetőségeim vannak..
Új hozzászólás Aktív témák
Hirdetés
ekkold
- ÚJ PS5 Slim - FW 8.40 - Lemezolvasó - Lua Loader - Lua játék - Lapse
- új, bontatlan, iPhone 16E gyárilag kártya-független, apple világgaranciával
- Üzletből, garanciával, Macbook Pro Retina 16" 2019, Gray i9 64GB RAM 1TB SSD Radeon Pro 5500M
- Üzletből, garanciával, Macbook Pro Retina 16" 2019, Gray i9 64GB RAM 2TB SSD Radeon Pro 5600M 8GB
- MacBook Pro 14" M1 MAX - 32GB / 1TB (2021) - 1 év garancia
- Eredeti DELL 240W töltők (LA240PM160)
- BESZÁMÍTÁS! 2TB Kingston KC3000 NVMe SSD meghajtó garanciával hibátlan működéssel
- DELL PowerEdge R730xd 26SFF rack szerver - 2xE5-2680v3 (24c/48t, 2.5/3.3GHz), 64GB RAM, 10G, H730p
- BESZÁMÍTÁS! SAPPHIRE VEGA 64 8GB HBM2 videokártya garanciával hibátlan működéssel
- Asus ROG G20AJ - Intel Core i7-4790, GTX 980
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest