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ó
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen monitort vegyek?
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Lassacskán fenyőfát állítanak a hardverek
- Apple asztali gépek
- Milyen egeret válasszak?
- Mesébe illő csodakábelt tervezett a GeForce-ok leégése ellen a Segotep?
- Amlogic S905, S912 processzoros készülékek
- Projektor topic
- Fujifilm X
-
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
#7392
üzenetére
Régebben nem volt szerintem akkora gond még. Mikor kezdtem az MSP430-as Texas Instruments mikrovezérlőkkel, akkor egyszerűbb volt a portok BIT szinten történő beállítása, legalább is az ESP32-es kóddal összehasonlítva. Persze ott nem is volt lehetőség minden portot mindenféle módban használni.
Ahogy rugalmasabbá válik a programozás (portkezelést mint példa), mellette meg úgy bonyolodik is. Viszont Arduino kerek segítenek megtalálni az egyensúlyt. Egymást kiegészítve jönnek fel párhuzamosan. MSP430 mikor elkezdett terjedni, még nem csak BIT szinten lehetett programozni, ma meg már Arduino keretek között is lehet. Fejlődik ez a terület is, ami nekünk csak jó.
-
Janos250
őstag
válasz
Teasüti
#7383
üzenetére
"Példánál maradva:"
Ha ugyanabból a
hardware\espressif\esp32\cores\esp32\esp32-hal-gpio.c
fájlból a pinMode-ot idézed, még szembetűnőbb a dolog. A 77. sortól a 165-ig tart!
Na, ezekért választom én is az Arduinot. Persze azért fél szemmel lesem azt is, hogy freeRTOS-ben mi van mögötte, illetve, hogy a freeRTOS mögött mi van regiszter szinten. -
Tankblock
aktív tag
válasz
Teasüti
#7383
üzenetére
Hello,
Akkor én felvállalom hogy több mint 1 van ebben az értelemben.
Arduino defacto programozási nyelv --> azaz szépen eltünteti a felhasználó elöl hogy mit is használ, aztán meg ha véletlenül 2 könyvtár ugyanazt az erőforrást használja akkor jön a probléma.
Ugyanaz mint amikor a WS2812 könyvtár RMT használja, meg mondjuk lehetne még használni IR adó vevőnek ugyanezt az erőforrást mert 8 csatornája van ha jól emlékszem,
Én ezért fogtam bele az ESP-IDF be és igen nincs minden dokumentálva, és néha nagyot lehet mellényúlni.
A másik oldalról, meg a fejlesztők ESP-IDF c++ kompatibilis és eclipse alatt lehet c++ is programozni. Akár Arduinos könyvtárat is behúzni / átírni....Vagy csak kevés időmben is mazoista vagyok...

Nem szólnám le ezt sem. Ez mellett szeretem az Arduino-t. Szeretem, hogy kész dolgokat kell csak összerakni és fut. Ezzel spórolhatok időt és az összes ESP8266 home automation erre épül.
Mindegyiknek megvan a szépsége.
-
válasz
Janos250
#7389
üzenetére
Én STM32-t keil-be programoztam függvénykönyvtárak segítségével. Regiszter vagy alacsonyabb assembly programozás sose vonzott, nem is terveztem használni, tehát ez ennek dokumentált hiányossága nem zavaró számomra.
Így ha jól értem az ESP32 + Arduino kombó nekem való, ráadásul a bluetooth (BLE vagy minden féle bluetooth nem tudom) kommunikációs hiányosságokat eltekintve mindent meg lehet Arduino környezetben valósítani. Meglátom, ha megjön a valóságban mi lesz.Köszi a részletes leírást.

-
Janos250
őstag
Teasüti jól összefoglalta a dolog lényegét, pár dolgot tennék hozzá:
Az Arduino ugyebár egy de facto "programozási szabvány". Azt mondja ki, hogy ha portolják egy kontrollerre, akkor bizonyos függvényeket, osztályokat kötelező az adott kontroller "nyelvén" megcsinálni, ami utána az "Arduino része" lesz. Ez nagyon nagy könnyebbség. Az STM32-re is portolták az Arduinot, elég jó is.
Az ESP32 kissé más, mint a többi:
Először is adott két mag. Azonkívül az általam ismert kontrollereknél a perifériák regisztereit memória címen símán elértem. Többnyire adott volt, hogy melyik periféria melyik lábhoz tartozik. Na, ez az ESP32-nél nem ennyire egyszerű. Bevezettek egy mátrixot, ezen keresztül lehet elérni a perifériákat. Ez nagyfokú rugalmasságot biztosít, mert bármelyik periféria bármelyik lábhoz kapcsolható, de egyben bonyolultságot is, mert meg kell mondanod,hogy mi mihez kapcsolódjon. Aztán, hogy még bonyolítsuk a dolgot, a perifériák alapállapotban "alszanak", pl. órajelet se kapnak.
Így még a hozzá tartozó regisztereket se tudod se írni, se olvasni. Először kell nekik órajelet adni, és resetelni, utána írhatók, olvashatók a regiszterei. Az órajel adás és a resetelés elvileg egyszerű: elérhető regiszterekben az adott perifériához tartozó bitet kell beállítani órajelhez, illetve törölni a resethez.
Igen ám, csakhogy az ESP azt nem mondja meg, hogy melyik perifériához melyik bit tartozik. Sebaj, kinézzük az illesztő programokból, gondolja Móricka. Viszont az illesztő programok lefordított assembly programok, aminek a forráskódját az ESP nem hozta nyilvánosságra eddig. Tehát a processzor közeli programozás még egy ideig macerás lesz. Az Arduino rendszerben viszont minden elég jól ki van dolgozva.
Tehát:
Az ESP megcsinálta az alapvető kezelést biztosító assembly nyelvű rutinokat.
Erre épülve készült el rá a freeRTOS. Ezt használja az IDF is. A freeRTOS-ra épülve portolták az Arduinora.
A freeRTOS függvényeit - általában - Arduino rendszerben is lehet használni, hiszen az Arduino "szabvány" függvényei is ebben íródtak.
Összefoglava:
Arduinoban programozása kényelmes, nagyon gyors, rengeteg a periféria, a két mag más programozási technikákat is lehetővé tesz, de ha processzor közeli módon akarod használni, az azért még jelenleg szívás. -
ngabor2
nagyúr
Én is kacsingatok az ESP32 felé. Viszont ebből egyáltalán nem, ESP12-ből is elvétve lehet találni olyat, amire külső antennát lehet csatlakoztatni. Ez zárt fém háznál viszont igen hasznos tud lenni.
Rá lehet valahogy mégis tenni, vagy könnyebb elrontani mint jól megcsinálni?
-
Teasüti
nagyúr
Nagy overhead a ram és rom méreteket illetően, bár van hely bőven így ez nem akkora probléma.
Emiatt ugye a számítási teljesítmény egy része is elúszik. Bár így is 100x gyorsabb egy UNO-nál, szóval mindegy is.
Egyfajta virtualizációhoz lehetne hasonlítani.Mondjuk nem hiszem, hogy nálam összetettebb felhasználása volna itt még vkinek (73 KB-os forráskód +könyvtárak, amiből a BLE megeszi a rom a közel 70%-át) és jómagam sem futottam még bele se teljesítmény se tárterület problémába. Mondjuk még szeretném majd kipróbálni az OTA programfeltöltést. Arra számítok, hogy az még egy jelentősebb szeletet elvesz a tárból.
A wifi azt hiszem teljes támogatottságot élvez, a BLE már működőképes, de még "béta" állapotú és így nem fejleszt rá egyetlen 3rd party sem. Ez azt jelenti, hogy a valós alkalmazásokban sok mindent magadnak kell megoldani.
A perifériák közül eddig én egyedül csak az RMT-t használtam, így a többiről nem tudok nyilatkozni.
Az Arduino függvények úgy tudom működnek mind, illetve nem tudok példát hozni az ellenkezőjére.
Nekem az UNO-ra írt programom egy az egyben lefordult ESP32-re is (az Atmel-re írt könyvtárak nélkül természetesen), így ez teljes értékűnek tekinthető szerintem.Nálam is tervben volt az IDF megismerése és az alacsonyabb C nyelv tanulgatása, de így hogy megy amit akartam Arduino-ban is, így nekem nem is fontos.
Meg a mai világban már nem divat a nehezebb úton menni és szopatni magad a hardver specifikus utasításkészlettel és telefonkönyv módszerrel regisztereket programozni, amikor némi overhead árán, de pár absztrakciós réteggel feljebb is meg lehet oldani a problémát könnyen és gyorsan, specializált tudás nélkül.
Persze nem is lesz olyan hatékony a kód, de ki nem szarja le, érted... Ez nem a Crysis, hogy ultra grafikán kisajtoljak minden fps-t a vasból.
Senkit nem érdekel mit csinál a digitalRead(), amíg megvan az eredmény.
Példánál maradva:extern int IRAM_ATTR __digitalRead(uint8_t pin)
{
if(pin < 32) {
return (GPIO.in >> pin) & 0x1;
} else if(pin < 40) {
return (GPIO.in1.val >> (pin - 32)) & 0x1;
}
return 0;
}Na most e szerint az sem mindegy melyik lábat olvasom. Programozzon így az, akinek két anyja van!

Én inkább beírom, hogy digitalRead() és együtt élek az overhead-del. -
válasz
Janos250
#7354
üzenetére
Olvasgattam kicsit. Azt íták, hogy az ESP IDF környezetben lehet a leginkább kihasználni az ESP32-t. Arduinot fejlesztgetik, ezzel is használható, de elsődlegesen nem ez az ajánlott.
Én Arduino IDE környezetben szeretném a programozást megoldani. Kérdésem az, hogy mit tapasztaltatok, milyen funkció nem az igazi, mi nincs implementálni ami miatt nem használható ki az ESP32?
-
vargalex
félisten
válasz
vargalex
#7023
üzenetére
Jelentem, 1 hete szépen megy 2 példány az ESP8266+DS18B20 RTC-s megoldásból. Végül azt választottam, hogy minden 10. mérésnél kicsivel hamarabb ébresztem a cuccot deep sleep-ből, szinkronizálok NTP-n, ha kell, akkor várok és post-olok. Természetesen RTC-be az NTP időt (unix timestamp) is leteszem, hogy tudjak mihez viszonyítani a következő post-kor. Az ESP-vel mérem a feszültséget is (getVcc függvénnyel), amit 10 percenként tárolok, de ugye ez a HT7333 által már csökkentett feszültséget méri. Ez nyilván nem változott az indulás óta. Azért rámértem multiméterrel is, most 4,15 V a cella feszültsége. Sajnos induláskor nem mértem, hogy megvolt-e a 4,2V, így sokat még nem jelent. Illetve mindkét példány bontott (Lii-500 szerint kb. 2000 mAh-s példányok) notebook akkuból származik. Kíváncsi vagyok, hogy meddig fog üzemelni (figyelem a mért feszültséget, 2,8-2,9V körül majd cserélem). Ha érdekel valakit, szívesen megosztom a kódot, illetve bekötést, valamint képet is csinálhatok, bár még a kinézet szépsége nem volt cél.
-
válasz
Tankblock
#7369
üzenetére
Köszi. Végül egy külső tápcsatis nélkülit rendeltem. Ha esetleg kell akkor magam beforrasztok egy csatit pluszba.
Addig is míg megjön. Tudtok ajánlani oldalt, amit érdemes olvasgatni ESP 32S-el kapcsolatban? Kezdve az arduino környezet beüzemelésével, ahol adatlapot találok a development board-ról, esetleg hasznos kiinduló minta példákat tartalmazó oldalt?
-
Teasüti
nagyúr
válasz
CHIPman
#7362
üzenetére
Semminek, hisz adat nélkül nem kapcsol be. Viszont ha adsz az adatbusznak egy kis interferenciát (vagy töltést az ujjaddal), akkor lehet felvillan néhány led.
Ezekhez kell egy adatfolyam, ami pixelenként 24 bitből áll (ugye három színkomponens 8 biten), és egy bit a szalag protokollja szerint egy magas és egy alacsony logikai jelszint adott időzítéssel. Szóval ezt te nem fogod úgy vezérelni, mint egy analóg szalagot, vagy egy ledet.
Ezekhez alapesetben egy könyvtárat szokás használni, amit a mikrovezérlődhöz választasz. Mint pl az Adafruit féle Neopixel, ami azt hiszem működik ESP-vel is.
Ezekben találsz példákat az animációkra.
Szóval itt animációt programozunk, jobban mondva egyenként ki kell számolni a pixelek színeit és berakni egy uint8_t tömbbe, majd ezt küldi ki a szalagra a könyvtár megfelelő függvénye. -
Teasüti
nagyúr
válasz
CHIPman
#7352
üzenetére
Hogyne lenne róla leírás, ne viccelj!
WS2812b a leánykori neve, több száz oldal foglalkozik a témával. Hozzádobod, h ESP és garantálom lesz rá találat.
Annyit fűznék hozzá, hogy ha komolyabb projekten dolgozol, ahol a szalag meghajtásán kívül mást is kéne csinálni, akkor tudni kell, hogy jelenleg az ESP32-n kívül minden más szoftveresen kezeli a szalagot és az adatküldés blokkolja a programot. Tehát nem lehetnek megszakítások és így arra a rövidke időre megszűnik a beérkező adatok fogadása.
-
Üdv.
Már régóta van egy címezhető RGB led stripem, viszont 3 bemenetű, "+", "data" és "-". Értelemszerűen 5V-os. Nem találtam még olyan leírást, ami ehhez lenne írva, mindenhol a 4 bemenetűt látom.
ESP eszközeim vannak, minimálisan konyítok hozzá, de eddig még nem sikerül működésre bírnom a ledeket. (Nem címezhető stripet mosfettel már vezéreltem gond nélkül ESP-ről, csak ez nem megy.) Dolgozott már valaki ilyennel? -
válasz
Janos250
#7348
üzenetére
Köszi a részletes leírást. Ezek szerint minimális eltérés van, pl.: Wemos tesz rá egy külsö táp csatlakozót is mint ami a lentebb képen látható és 1 reset gombot (ami szemmel látható különbség elsőre). WROOM esetén nincs külső táp csatlakozó, de van egy plusz gomb, gondolom programozható. Szignifikáns külnbség nem nagyon van közöttük. Illeve ide jöhetnek még az OLED kijelzős verziók, ahol már kicsivel nagyobb lábkiosztás vagy egyéb eltérések is felléphetnek.
Arduino-t akartam először a programozási könnyebbség miatt, de mivel ESP32 teljesítményben illetve modulokban is jobb, olcsóbban, így gyorsan tovább is léptem az arduino-n. Köszi a linkeket, valószínűleg ezek közül választok.Tankblock
Neked is köszi az észrevétel. Ha jól értem akkor a képen jelölt külső aksi/táp csatlakozóra érted, hogy fel van cserélve a VCC-GND kivezetés? -
Janos250
őstag
válasz
Janos250
#7348
üzenetére
Még annyit, hogy itt látható, mi van ez ESP-WROOM-32 hibrid chipben:
https://github.com/boseji/ESP-Store/blob/d80a4bafb5d0d2b9f78954681f995429110383d6/Ref-Designs/ESP-WROOM-32/SCH/sch.pdf
De ha magadnak akarsz gyártani
, a gerber adatok is megvannak:
https://github.com/boseji/ESP-Store/commit/d80a4bafb5d0d2b9f78954681f995429110383d6 -
Janos250
őstag
Én most nem tudok olcsót, általában min 1500 Ft körül vannak.
A verziók gyakorlatilag megegyeznek. Az ESP32 ugyebár az alap chip. Amikor ez megjelent, akkor pár gyártó gyorsan el is kezdett vele lapot gyártani. Mivel nagyon vártam az ESP32-t, én is rendeltem gyorsan tavaly ősszel 9000 Ft-ért egy ilyen panelt, ami azóta is a fiókban hever. Akkor még nem volt megfelelő támogatás hozzá.
Igen gyorsan megjelent az ESP32S, ami egy hibrid tokozás fém tokban, tartalmazza az ESP32 chipet, flash memóriát, és még pár alkatrészt. Aztán gyakorlatilag ugyanezt elkezdte gyártani az Espressif is, ESP-WROOM-32 néven. Ma már ez gyakorlatilag egyeduralkodóvá vált, ezt érdemes venni. Amit ESP32S megjelöléssel hirdetnek, ma már azok is általában ezt tartalmazzák.
Pl.: https://www.ebay.com/itm/ESP32-ESP32S-CH340G-Development-2-4GHz-Dual-Mode-WiFi-Bluetooth-Module-Antenna/282633370924?epid=866775664&hash=item41ce42fd2c:g
eMAAOSwv-ZZ9YZE
Én pl. ezeket használom, mert szeptember elején ezeket lehetett 1200 Ft körüli áron megvenni. Nem volt vele gondom:
https://www.ebay.com/itm/ESP-32S-ESP-32-Development-Board-2-4GHz-Dual-Mode-WiFi-Bluetooth-Antenna-Module/302252239864?hash=item465fa32bf8:g
3kAAOSwTM5Yx~38
A különböző gyártók által gyártott lapok között nem különösebben lényeges az eltérés. A lábaknak a panelra írt elnevezése különböző, de azt általában tartalmazza az Arduino IDE, ha a megfelelő panelt választjuk ki.
A hardware\espressif\esp32\boards.txt fájlban láthatjuk, mennyi féle laphoz van meg a saját támogatás, de az ESP32S-et választva se szokott gond lenni. A lábak elnevezése, stb. a hardware\espressif\esp32\variants könyvtárban található verzióként.
USB mindenképpen legyen rajta. Az USB chipek közül ki melyiket szereti, az ízlés kérdése. Megfelelő driverrel mind jól működik tapasztalatom szerint. -
Kérdést kiegészítve, melyik kivitelt érdemes venni, mert ahogy néztem van egy csomó verzió, van ami usb-uart kommunikácóban és ki tudja miben tér még el. Értem a verziók alatt pl.: NodeMCU, WROOM32. ESP-32S meg a társai.
-
Sziasztok!
Van most valahol best buy ESP32?
-
Tankblock
aktív tag
válasz
Teasüti
#7312
üzenetére
Hello,
Ha jól emlékszem, akkor külön task ID fog kapni és fog párhuzamosan futni n-szer is.
Amit leírtál az tervezést igényel.
SW megoldásként : a megszakításban kellene viszgálni, hogy mikor volt utoljára meghívva az interupt és ha az idő megfelelően nagy csak akkor végigfuttatni a megszakítás logikáját.
Vagy
Perlmentesíteni HW esen,
Delay miért kell? nem lehet másképpen megoldani? pl Queue v xEventGroup (ez nem tudom, h implementálva van-e ESP32 FreeRTOS ra.) Vagy Taskot suspendedbe tenni és felkelteni amikor kell....
-
Janos250
őstag
Na, akkor lássuk konkrétan, hátha mást is érdekel:
Láttam, hogy Teasüti egy kész könyvtárat használt a WS2812 led szalag vezérlésére. Innen jött az ötlet, hogy - játékból - kipróbáljam, hogy az elég bonyolult kész program helyett a "kézzel" való vezérlést használjam.
Ennek a szalagnak a vezérlése úgy történik, hogy a szalag minden egyes ledjéhez kiküldjük a saját színét, 24 biten. A kiküldés bitenként megy: pl. a 400 nanos hoszú impulzus jelenti a "0" értékű bitet, a 800 nanos az "1"-et.
Ha beállítok egy lábon magas sztintet, akkor ha ez 0 értékű bit, akkor 400 nano múlva kell levinnem alacsony szintre, ha 1 a bit értéke, akkor 800 nano múlva. Ezt kell ismételni a szalag minden egyes ledjére sorban egymás után, ahogy a szalagon vannak. Egy led színe 24 bit, tehát egy 100 ledből álló szalagra 2400 db. - az egyes led kívánt színei szerint - különböző hosszúságú impulzust kell kiküldeni.
Viszont, ha egy 400 nanos impulzus középén jön egy megszakítás, akkor mire "visszatér" a task, az már akár 800 nanos is lehet, tehát hibásan másik bitként értelmezi a led.
Na, ez talán a legtipikusabb példája az ESP32 "RTM" funkciójának. Az egyes impulzusok adatait feltöltöm egy megadott memória területre, és ráeresztem a hardvert, ami teljesen önállóan kiküldi ezeket az impulzusokat, igen nagy pontossággal, mert 15 biten írom le az impulzus hosszát. A 16. bit jelzi, hogy a megadott ideig L vagy H szinten kell lenni az adott lábnak.
Ezt nevezi az ESP32 RTM-nek. Eredetileg az infrás távvezérlők szimulálására ajánlják, mert lehet úgy programozni, hogy egy magasabb vivőfrekvenciát moduláljon az adott hosszal.
Tehát - mint írtam - nem egy élő projekt problémájáról van szó, hanem kíváncsiságról. -
Teasüti
nagyúr
Üdv!
ESP32 és az RTOS task indítás érdekelne, ha van ezzel tapasztalat.
A kérdésem pedig, hogy milyen módon kezeli a kernel az éppen futó folyamatok újbóli meghívását?
xTaskCreate() függvény hívása, miközben már fut belőle egy példány.
Ilyenkor megszakítja az első példányt, el se indítja a második példányt, vagy párhuzamosan fut a kettő (vagy több)?
Egy ISR alapú meghíváson filózok, amit egy gombra kötött CHANGE állapotváltozás figyel. És itt jön a képbe a prell jelensége. (Illetve vmi vibráció, vmi zavar amivel szembesülök járó motornál a féklámpa kapcsoló felől, de eddig lusta voltam megnézni szkóppal.) És mivel delay()-ek vannak a folyamatban, ezért könnyen előfordulhat, hogy újból meghívásra kerül a folyamat annak végezte előtt.szerk: az RTOS kérdés az érdekes most, nem a jel szűrése.

Köszönöm!
-
dzz
aktív tag
válasz
Janos250
#7301
üzenetére
Én linuxon élek már a 90-es évek közepe óta, szeretek mindent parancssorból intézni. Pl. az openwrt-nek megfelelő shell képességei vannak, valami ilyesmire gondoltam ESP32-n, tehát nem a PC oldalról hanem az eszközön magán. Mondjuk kicsi a memória minden ilyesmire, de csak feldobtam a kérdést, még nem jártam rendesen körbe az ESP képességeit csak meglepett, hogy mennyivel több a korábbi Arduino-s kütyüimnél

-
Janos250
őstag
-
dzz
aktív tag
Nos a héten megérkezett az ESP32. Most játszadozom vele és ismerkedünk (Hello World megvolt
most épp duktape van rajta) Viszont az egyszerűbb modulokhoz képest lényegesen többet tud, ez az arduino nem az az arduino amit eddig használtam (mármint eddig ennyire komplex nem volt a kezemben). A ledek ki/be kapcsolása és ilyesmi volt eddig terítéken. Valaki botlott már olyanba, hogy egy unix szerű sh/bash-t használhassunk? Agyament ötleteim támadtak és egy ilyesmi tetszene ha lenne készen. Nem kutakodtam utána nagyon, leginkább az érdekelne, hogy valaki futott-e bele ilyenbe. -
Janos250
őstag
válasz
Teasüti
#7249
üzenetére
az esp32-hal-gpio.h-ban találod:
//GPIO FUNCTIONS
#define INPUT 0x01
#define OUTPUT 0x02
#define PULLUP 0x04
#define INPUT_PULLUP 0x05
#define PULLDOWN 0x08
#define INPUT_PULLDOWN 0x09
#define OPEN_DRAIN 0x10
#define OUTPUT_OPEN_DRAIN 0x12
#define SPECIAL 0xF0
#define FUNCTION_1 0x00
#define FUNCTION_2 0x20
#define FUNCTION_3 0x40
#define FUNCTION_4 0x60
#define FUNCTION_5 0x80
#define FUNCTION_6 0xA0
#define ANALOG 0xC0Látszik, hogy melyik bit mit jelent.
Ezt hogy lehetett volna úgy bevinni, hogy ne csússzanak el?
-
Teasüti
nagyúr
válasz
Spuri2000
#7252
üzenetére
Nem bonyolult, csak ránéztem és elszörnyedtem. Egy igazi kódhuszár erre köp egyet és tovább lapoz.

Tényleg hasznos az a "programkód" szövegformázás, így behúzza a sorokat a struktúrának megfelelően a fórum motor. Én pl már ott ráncoltam a szemöldököm, hogy három kapcsos zárójel egymás után.
Ami azonnal átlátható megfelelő formázással, de így meg át kell nyálazni, hogy melyik hova tartozik, ki kivel van.(#7250) dzz
Hát ha a karórámból indulok ki, ami BLE-vel kapcsolódik, akkor nem sok.
Két falon keresztül már megszakad a jel (mondjuk kimegyek a fürdőbe egyazon emeleten és hisztizik az óra, hogy megszakadt a kapcsolat). Néha a saját testemmel le tudom árnyékolni, mikor pl összefonom a karjaim. De hát ugye okkal az a neve, hogy Bluetooth Low Power.
A klasszik BT ugyan erősebb, de az nincs implementálva még az ESP-IDF-ben se, nem hogy Arduino vonalon.
Én azt mondanám jó, ha megvan a 10-20 méter szabad rálátás esetén.
Viselhető eszközökhöz és kis hatósugarú mesh hálózatokhoz van kitalálva, nem arra, hogy kirakjunk egy állomást a semmi közepére. Persze ha kimész a helyszínre kiolvasni az adatokat, ahhoz amúgy megfelelő, mert viszont jó választás az akkumulátoros üzemhez. Sőt, akkus üzemhez én eleve nem is gondolkodnék másban. Állítólag megfelelő alkalmazásban a BLE kevesebbet fogyaszt, mint az elem önkisüléséből eredő merülés. A wifi-nek nem lesz hosszú üzemideje e szempontból. -
Teasüti
nagyúr
Terepen szerintem a BLE lesz a nyerő, hacsak nem akarsz a mobilnettel b@szakodni.
Ugye vagy a telón csinálsz egy hotspot-ot amihez az ESP tud kapcsolódni (és akkor a hotspot adatait gondolom FW-be kéne rakni, aztán másik setup-pal nem lesz működőképes), vagy az ESP-n wifi AP-t (ha lehet ilyet egyáltalán, Janos250 biztos tud rá mondani vmit), amihez a teló csatlakozik és lőttek a mobilnetnek a telón. -
dzz
aktív tag
válasz
Janos250
#7244
üzenetére
Ez logikus és nem kifejezetten saját megírt appra gondoltam, hanem a lényeg, hogy terepen adott lesz egy smartphone meg a „kütyü”
Tegnap megrendeltem egy LiPo pigback-es, kijelző nélküli ESP32-t, a jövő héten megérkezik. Kifejezetten tetszik, hogy első körben rajta van minden ami kezdésnek kell, a kimeneteken egyenlőre szimulálom LED-el a perifériákat. A többi majd apránként... -
Janos250
őstag
Mivel ESP-WROOM-32 van benne, nagy gond nem lehet. Ez az ESP32-nek a "gyári tokozott" verziója, tehát ez az alap. A display még egy kis hab a tortán, szerintem nagy gond nem lehet vele. Mondom én, aki még soha nem használtam a display-es verziót.
Eltérés abban lehet, hogy milyen lábszámok vannak a panelra szitázva, egyébként ugyanaz. -
dzz
aktív tag
Sziasztok!
Új világ nekem az ESP32 (az arduino is, bár már egy ideje játszadozom vele), kellene egy kis megerősítés (vagy épp az ellenkezője
)A kérdésem, hogy ezek az eszközök mennyire használhatóak?
1
2
3Az érdekelne, hogy van ezeknek valami olyan jellegű eltérése, ami jelentősen eltérne az alap ESP-DEV programozásától.
Thx
-
Sikerült!

Ezt az esp32-es kis lapot lehet egyáltalán használni a shield v5-tel?
Másik kérdésem is van: Arduino uno-t lehet egyszerre használni a shield v5-tel meg a l293d sihelddel, vagy ezt benéztem és ha a motorvezérlő van rajta akkor már nincs lehetőség ultrahang szenzort meg vonalkövető infra szenzort plusz bluetoothot használni?
Ez a terv az unoval egyáltalán kivitelezhető? meghajtó motor+kormánynak motor, ultrahang szenzor(ok), vonalkövető szenzor, világítás a járműre (4 helyzetjelző+indexek+tolató lámpa stb), bluetooth távirányítás. Tehát ha nem távvezérelt, akkor mondjuk kövesse a padlóra ragasztott vonalat, de ha van alami akadály akkor annak ne menjen neki. -
válasz
Teasüti
#7216
üzenetére
Köszönöm. Tegnap odáig jutottam, hogy letöröltem már mindent, a git-et, arduinót, pythont.Visszatettem telepítettem újra az Arduinót, meg amit linkeltél, illetve letöltöttem azt a zip-et amit a git szedne le. Látszik is az eszközök között az esp32, de nem képes rá feltenni a lefordított programot: exec: "C:\\Users\\viktor\\Documents\\Arduino\\hardware\\espressif\\esp32/tools/esptool.exe": file does not exist Hiba a(z) DOIT ESP32 DEVKIT V1 alaplapra fordításra. A get.exe nem csinál semmit, pedig admin joggal indítom. Már azt a zip fájlt is letöltöttem amit elvileg a get.exe töltene le, de abban nincs esptool.exe.
A lényeg akkor annyi lenne, hogy a C:/Users/[YOUR_USER_NAME]/Documents/Arduino/hardware/espressif/esp32 könyvtár megvan, itt le kéne futnia a get exe-nek, ami látszólag nem csinál semmit... Bár tegnap előtt mintha már lefutott volna egyszer 50 perc után, de akkor a program files mappa arduino könyvtárában volt az egész hóbelevanc. Az erőforrás kezelő szerint 35kb/s-mal tölt valamit, egyszer remélhetőleg kész lesz. Legalább valami tájlkoztató üzenetet kiírhatna, hogy dolgozik vagy hány %-nál tart...
A wemos d1 r2-vel is ennyi szívás lesz? -
Elnézést, hogy 3 lett, de van köztük majdnem 24 óra... Végigmentem tegap este a tutorialon, de még mindig nem látszik az esp32-es lap. Ott van a hardware mappában hozzá minden, amit itt írnak, de nem jelenik meg a válsztjató eszközök között. Még egy újratelepítést megpróbálok.
-
válasz
Victoryus
#7213
üzenetére
Közben találtam egy tutorialt Azt nem gondoltam, hogy ilyen lassú lesz a letöltés, a git gui ~30 perc volt, meg az esp32-elf-win32-1.22.0-73-ge28a011-5.2.0.zip is több, mint 40 perce jön. 90 megás az egész... (100megabites nettel, szóval náluk van a szűk keresztmetszet)
-
Megérkezett az esp32-es mini vezérlőm. Ezt hogy lehet működésre bírni az arduinós programból? A led villogtató programot akarom rátölteni, de hibát ír: avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x20 Hiba történt a vázlat feltöltése közben
Alaplap infó ismeretlen alaplapot ír, portok közül felsimerte, hogy az ötösön kommunikál.
Windows 10 eszközkezelőben a portoknál Silicon labs cp210x usb to uart bridge-ként ott van. -
Janos250
őstag
válasz
Teasüti
#7208
üzenetére
"történt már veletek, hogy a watchdog reboot-ol, mert nincs etetve a Core 0-n?"
Igen :-(
Én megkerültem a problémát: A loopból hívom meg a taskot újra és újra, és amikor a task elvégezte a dolgát, kilép [vTaskDelete(NULL)].
Még nem igazán sikerült tisztán látnom kutya ügyében. Mindjárt az első, hogy ők hányan vannak: minden Core-nak, vagy minden tasknak van egy-egy? Aztán, hogy hogyan lehet törölni?
"Én eddig azt hittem az RTOS fel is tudja függeszteni az adott folyamatot, hogy cpu időt adjon a többi folyamatnak."
Én is azt hittem, de ez se igazán így van. Továbbá én korábban azt hittem, hogy a core1-en nincs megszaggatás, ott mehetnek a realtime dolgok. Na, ez se így van: ott is van interrupt.
Ezt írják:
"Also make sure you disable interrupt watchdog on CPU1 when not using RTOS" "(Also disable the tick interrupt app watchdog, as Ivan said, otherwise it'll complain.)" "A OS-Environment on CPU0,
and pure "undisturbed" power on CPU1."
Na, de ezt hogyan csinálom Arduino alatt? A szokásos Arduinos módszer még - úgy tűnik - nincs implementálva :-(
A PCNT_ENTER_CRITICAL használatában is vannak homályos dolgok. És még számos egyéb is."Amúgy nem gáz, hogy ezeket itt tárgyaljuk ki? Engem nem zavar, de nem tudom azoknak zavaró-e, akik a vanilla Arduino-n dolgoznak."
Miért nem? Szerintem azért, mert előbb-utóbb mások is áttérnek korszerűbb procikra az Arduino alatt, és így látják, mire térjenek át: ESP8266, ESP32, STM, stb.
Pl. ha én nem olvastam volna ezt a topicot, nem érdekelt volna a WS2812 led szalag. Azért kezdtem el kiváncsiskodni, mert itt olvastam. Vagy pl. Te se biztos, hogy ESP32-t használnál, ha nem olvastad volna ezt a topicot. Nekünk már volt belőle hasznunk. Reméljük másnak is.
Egyébként a topicnak van egy gazdája, ha nem akarja, hogy ilyesmiről itt szó essen, majd szól, hogy húzzunk el külön el topicba. Én így gondolom. -
Teasüti
nagyúr
Janos250 és aki ESP-zik:
történt már veletek, hogy a watchdog reboot-ol, mert nincs etetve a Core 0-n?
Task watchdog got triggered. The following tasks did not feed the watchdog in time...
És akkor mutatja mely folyamatok futottak éppen.
Végtelen ciklusban megy egy, ami 100%-ra hajtja valószínűleg az első magot.
Beraktam egy delay(100)-at és most működik.Hogy kellene optimalizálni ezt a folyamatot?
Én eddig azt hittem az RTOS fel is tudja függeszteni az adott folyamatot, hogy cpu időt adjon a többi folyamatnak. Így nem voltam rest bedobálni több folyamatot is ide-oda, bár igaz mindegyik másikban van egy kicsi delay(), még ha mikroszekundumokban mérhető is.
Vagy etetni kéne a watchdog-ot?
Amúgy nem gáz, hogy ezeket itt tárgyaljuk ki? Engem nem zavar, de nem tudom azoknak zavaró-e, akik a vanilla Arduino-n dolgoznak.

-
Teasüti
nagyúr
Basic? Viccelsz? C++ és Java jobban megy (a nullához képest jobb
), akkor már neki állhatnék a natív Android-nak is.
Még nem tudom mi fog kisülni ebből a pfod-ból (várom a postást, hogy hozza már a második ESP32-met, mert az első már be van építve és én le nem mászok a garázsba ilyen hidegben laptoppal a hónom alatt), de tetszik ez a megközelítés, hogy mikroböngészőbe küldünk pár bájtos oldalakat. Persze BLE-n keresztül, Janos250 bevett.módszere túl könnyű lenne.
-
szuszinho
őstag
válasz
Janos250
#7201
üzenetére
Nem akarom megtanulni az AT parancsokat, csak az AT paranccsal ellenőrizni, hogy visszakapom-e az OK-t, mert akkor minden jó.
Most odáig jutottam el, hogy felmegy a fw az ESP-re, de az AT parancsra nem kapok választ, így nem tudom, jó-e? Tovább nem haladtam a projekttel. -
Janos250
őstag
válasz
szuszinho
#7199
üzenetére
Hú, akkor nem tudom :-(
Én amikor pár éve ráálltam az ESP-re, akkor már volt a 12E, ill. a NodeMCU klónjai, én azokkal kezdtem. Azokban van elég memória, hogy feltöltsük rá az Arduino rendszert. Megtanulhatod az ESP-n az AT parancsok használatát, de előbb-utóbb úgyis átállsz valami nagyobbra, és akkor már semmi hasznát nem veszed az AT parancsok ismeretének.
Én ezt
vagy ezt
Ezt még nem használtam, de nekem tetszik
Ezen meg van plusz GND, VCC, és I/O port csatlakozás, amiből mindig kevés van.Vagy ha egy kicsit több pénzt szánsz rá, akkor ez már alapvető minőségi ugrás
-
Dalee
aktív tag
Próbálok egy fűtés projektet összehozni NodeMcu ESP8266 ESP-12E alapon.
A kapcsolás elég egyszerű:
- ESP8266
- DS18B20 hőmérő (onewire kommunikáció)
- relé modul
- állapotjelző LED-ek.
- szabvány USB telefon töltő tápnak.Az alábbi szoftveres komponenseket telepítettem:
- Web szerver (a vezérlés adatok megváltoztatása, hőmérséklet figyelés) ESP Web lapos működéséhez ezt a tutort használtam.)
- E-mail küldés. A hőmérsékletet e-mail-en is küldöm meghatározott időközönként
- Time szerver elérés (log-hoz)
- SPIFFS file rendszerben mért értékek loggolása
- FTP szerver (log adatok letöltése)
- fűtőszál vezérlése relén keresztülAlapban megy is minden, de pár óra elteltével (vagy ha dolgozok az otthoni hálózaton hamarabb) a ESP leszakad a hálózatról és vagy visszakapcsolódik vagy nem, vagy magával rántja fűtés vezérlést vagy nem.
Elég sok WIFI van a környéken, ezért a laptop is gyakran leszakad, szóval elég szar a WIFI, viszont a ESP-nek elvileg újból kellene csatlakozni, illetve nem szabadna megállítani a loop folyamatokat ha jól olvastam.
Gondoltam használom a watchdog timert, de arról azt találtam, hogy a WIFI, WEB könyvtárak kezelik (resetelik), ezért az sem jó megoldás.A flash-re logoltam a loop ciklusban 4 másodpercenként a HEAP-et, hátha elfogy a RAM, de azon sem látszik semmi RAM fogyás, stabilan 20 kb szabad hely van.
Próbálkoztam a WIFI manager könytár autoconnect funkciójával, azzal is meghal a rendszer egy idő után ugyanúgy.
Most 30 percenként resetelem a ESP-t. Így ment egyfolytában 3 napot, de szombat délután egy 30 perces resetet követően, elfelejtette az eddigi router csatlakozási adatokat és szabványos 192.168.4.1-es címen lévő WIFI beállító lapot adta fel a loop-ig el sem jutott.
Nektek is ilyen bizonytalan a működése a WIFI-nek. Van ötlet, hogy mi lehet a hiba vagy, hogy találjam meg mi okozhatja?
Segítségeteket előre is köszönöm.
-
Janos250
őstag
válasz
szuszinho
#7195
üzenetére
Az ESP8266 önmagában többet tud, mit az UNO.
Mióta portolták az Arduinot az ESP-re, azóta nem célszerű az AT parancsokat küldözgetni, hanem az UNO-n futó programot szőröstül/bőröstül átrakjuk az ESP-re, és azon futtatjuk. Az UNO-t meg eltesszük emlékbe.
Az AT parancsokkal a WiFit vezérelnénk, de az ESP-n a WiFi kezelésére kész osztályok vannak, amik SOKKAL kényelmesebbek.
Lehet, hogy valami régi irodalom alapján próbálod, amikor még így kellett?
Az UNO előnye az ESP8266-hoz képest, hogy több I/O portja van.
Ha kell a sok I/O port, akkor meg az ESP32 a célszerű. egy-két ezer Ft körül van ebay-en, attól függ, mikor és hol. Most 11.11-én ismét kb. 1300 Ft volt.
Az ESP8266-os lapból is van egy csomó, Neked melyik van? -
Teasüti
nagyúr
válasz
Janos250
#7192
üzenetére
Neeem, bár nem vagyok biztos melyik problémára célzol.

Amivel most küzdök, az egy BLE alkalmazás telefonra.
Mivel nem szeretnék megtanulni Android alkalmazást fejleszteni - nyilvánvaló okokból -, ezért a Play-en keresgélek vmi használható után. A Blynk egy egész ügyes kis alkalmazás lehetne, de nincs kész BLE támogatás egyetlen Espressif MCU-hoz se, hát még az ESP32-höz.
Az UART programok szépen működnek, de nem parancssorból szeretném vezérelni a cuccot.
Most vmi pfodApp nevezetűt próbálgatok.
Ennek sincs ESP32 támogatása - nem meglepő módon -, viszont az általa használt library pofon egyszerű (na jó azért kezdőként kell némi idő míg visszafejti az ember) és a meglévő BLE modulokhoz való UART porton kommunikál. Ezt a library-t akarom módosítani úgy, hogy ne a Serial stream-re tolja ki az adatokat, hanem a Kolban féle BLE UART függvényekbe. Elméletileg nem egy nagy munka átírni a library-t.
Csak mikor megláttam, hogy a Serial-t példányosítja és annak a print függvényeit használja, akkor hirtelen azt hittem elég volna copy&paste módon bedobálni a BLE notify() függvénybe mindent, ami ott megy át.
Persze aztán rájöttem ez se nem praktikus, se nem egyszerűen kivitelezhető.Amúgy okkal csináltam egy topikot ezeknek a témáknak, mert itt mindezt off-ba rakja a nép vmi oknál fogva.

-
Janos250
őstag
válasz
Teasüti
#7191
üzenetére
Ugye nem a másik topicban tárgyalt áthallásos problémát akarod szoftveresen megoldani? Mert az nem fog menni! Ez az átka a nagy energiatakarékosságnak, hogy olyan pici áramok mennek, hogy akár a Kossuth rádió is bezavar. Muszáj ellenállással mesterségesen megterhelni. Én a soros átvitelnél tapasztaltam ugyanezt: kb 20 centis vezeték a két IC között, és a csomagok 10-20 százaléka CRC hibásan érkezett.
Mit akarsz variálni?
"Az ESP32-n a HardwareSerial.cpp fájlba kell belenyúlnod. (hardware\espressif\esp32\cores\esp32)"
"int HardwareSerial::read(void)
{
if(available()) {akarmi =uartRead(_uart);
Itt megcsinálod amit akarsz
return itt meg adod neki ami jó Neked!
}
return -1;
}"Az szerintem nem lesz egy ördöngősség! Egyszerűen az uartRead(_uart); rész után csinálsz valamit, nem azonnal adod a returnnek.
-
Janos250
őstag
válasz
Teasüti
#7188
üzenetére
Mélyrehatóan nem, de valami:
Az ESP32-n a HardwareSerial.cpp fájlba kell belenyúlnod. (hardware\espressif\esp32\cores\esp32)
A Stream osztály virtuális függvényként megadja, hogy minden gyerekének (pl az egyes processzorok serialjei) kötelezően miket kell tartalmaznia,
ezzel nagyjából biztosít egy bizonyos kompatibilitást.
(class HardwareSerial: public Stream)int HardwareSerial::read(void)
{
if(available()) {
return uartRead(_uart);
}
return -1;
}}
size_t HardwareSerial::write(uint8_t c)
{
uartWrite(_uart, c);
return 1;
}Mint látható, használják az esp32-hal-uart.c fájlból az uartRead-et az meg a hardware\espressif\esp32\tools\sdk\lib\xQueueReceive.a assembly fájl tartalmát.
Érdemes még egy pillantást vetni a HardwareSerial.cpp fájl include-ok utáni első sorára: HardwareSerial Serial(0);
Itt példányosítja előre a mi beavatkozásunk nélkül "Serial" néven a 0-ás UART-hoz kapcsolva. Ezért nem kell őt nekünk példányosítani. -
szuszinho
őstag
Sziasztok,
Próbálnám használni az ESP8266 modulomat UNO-val.
Odáig már eljutottam, hogy firmware-t tudok a modulon frissíteni, de bármit csinálok, az AT parancsra nincs válasz. Igaz, nem vagyok biztos abban, hogy melyik a legfrissebb fw.
Az UNO RESET a GND-be van kötve, és rámértem a 3.3V-ra, és az is jó. (3.32V)
-
Janos250
őstag
Na, az UNO feeling kedvelőinek megjelent az ESP32 is "UNO-szerű" kivitelben:
https://www.ebay.com/itm/MINI-Wemos-D1-TTGO-UNO-R3-D1-R32-ESP32-CH340-WIFI-Bluetooth-Devolopment-Board-4M/263305416343?hash=item3d4e39ce97:g:ZRcAAOSwIJlaAZr4 -
Janos250
őstag
Srácok!
Valaki használta már ESP32-n a CCOUNT-ot? (getCycleCount(), vagy hasonlók)
A guta megüt vele, összevissza adatokat ad, és nem tudom, mi a bánatos Télapó a baja.
Ez egy uint32_t regiszter, ami az órajelciklusokat számlálja, de az uint32_t 240 Mhz-nél tizenegynéhány másodpercenként átfordul, tehát így időzítésre nem igazán jó.
Lehet resetelni (XTHAL_SET_CCOUNT(0)), úgy már jó lenne, de a getCycleCount() a program futása során ugyanarra az utasítássorra egyre nagyobb értékeket ad, még a delay() is egyre lassabb lesz. Mintha egyre csak lassulna, lassulna a gép.
Próbálta már valaki? -
brickm
őstag
válasz
gyapo11
#7168
üzenetére
Sziasztok!
Riasztóközpontom open-collectoros kimenetét szeretném GPIO-ra kötni és kommunikáltatni a hálózaton.
Ehhez szeretnék egy ESP 8266-os modult vásárolni, de láttam, hogy elég sok fajta van.
Az lenne a kérdésem, hogy melyik verzió, melyik tipus lenne nekem a legmegfelelőbb, van egy arduino megám is, lehetőleg azzal legkompatibilisebb változatot szeretném. -
Teasüti
nagyúr
Szeretném megköszönni ezúton is a rengeteg segítséget!
Igazán leköteleztek.
Alább látható az ESP32 vezéreltre ws2812 projektem.
Idővel szeretném interaktívvá tenni, a tacho és speed jelek kiolvasásával, meg épp készülőben van egy saját tervezésű féklámpa is 5730-as ledek felhasználásával (nagyon durvák ezek a fél wattos ledek, 5 db-ot próbáltam ki a prototípuson, de még 8%-on is bántja a szemem. 100%-on meg mintha napba néznék, instant vakufoltok.
Na ezt egy kicsit túllőttem 95 db ilyen leddel...).
Szóval egy szó mint száz, még keresem a bajt így sűrűn fogtok hallani felőlem. :] -
válasz
fpeter84
#7156
üzenetére
Tápfeszültség témához off: nemrég teszteltem, hogy lefelé meddig lehet menni. Kínai klón UNO lap +5V-ra két ceruzaelemről vidáman üzemel, sőt, két közepesen töltött ceruzaakksiról is, ami 2,8V.
On: szeretnék egy UNO és egy Wemos d1 mini lapot összekötni, i2c-n megy majd a kommunikáció. A Wemos az UNO +5V-ról kapja a tápfeszültséget, de ugye az esp 3,3V-ról üzemel, amit a wemos onboard regulátorral állít elő magának az 5V-ból. Van értelme a 3,3V-ot is közösíteni a két lap közt? -
Janos250
őstag
válasz
Teasüti
#7140
üzenetére
Elnézve a macerát, kezd az az érzésem támadni, hogy igaza volt annak, aki megírta "gyalog" módszerrel a WS2812 RGB led szalag programozását az ESP32-re, mert az legalább egyszerű, és működik. Mivel nagy a sebesség, és van 2 mag, nem szorít az idő, hogy hardware alapon kezeljük a szalagot, bár kétségkívül az a szebb, ezért meg kellene próbálni, valami egyszerűbb, áttekinthetőbb megoldást találni rá.
-
Teasüti
nagyúr
Próbálom visszakövetni a forráskódot hol lehetnek a pixelek eltárolva.
Ha megnézem a
digitalLeds_updatePixels(strand_t * pStrand)kódját a .cpp fájlban, akkor ebből apState->buf_data[0 + i * 3] = pStrand->pixels[i].g;
pState->buf_data[1 + i * 3] = pStrand->pixels[i].r;
pState->buf_data[2 + i * 3] = pStrand->pixels[i].b;
rész érdekes nekem. Az itt lévőpixels[]az lesz, ami a STRANDS[] objektumban van definiálva.Aztán ott van egyszer a szalag definíció a programban:
strand_t STRANDS[] = { // Avoid using any of the strapping pins on the ESP32
{.rmtChannel = 1, .gpioNum = 17, .ledType = LED_WS2812B_V3, .brightLimit = 32, .numPixels = 93,
.pixels = nullptr, ._stateVars = nullptr},Csak tippelek, de a
.pixelsaz az ami érdekes lehet nekem.Ez a .h fájlban így néz ki:
typedef struct {
int rmtChannel;
int gpioNum;
int ledType;
int brightLimit;
int numPixels;
pixelColor_t * pixels;
void * _stateVars;
} strand_t;Itt a
pixelColor_t * pixels;amit keresnem kell.
Felette meg is vannak az egyes komponensei a pixeleknek:inline pixelColor_t pixelFromRGB(uint8_t r, uint8_t g, uint8_t b)
{
pixelColor_t v;
v.r = r;
v.g = g;
v.b = b;
v.w = 0;
return v;
}Már csak a pStrand maradt hátra az egyedüli elemeként a puzzle-nak, amit még nem egészen tudtam lekövetni, mi hogy mikor és hol kerül meghívásra.
Jelenleg úgy sejtem a*pStrandaz lényegében egy&STRANDS[i]lesz. Na megyek alámerülni megint...szerk: oh ba.meg MEGVAN! Hisz ezzel indul a függvény meghívás a loop()-ban.

for (int i = 0; i < STRANDCNT; i++) {
strand_t * pStrand = &STRANDS[i];
rainbow(pStrand, 0, 2000);
scanner(pStrand, 0, 2000);
digitalLeds_resetPixels(pStrand);
}
Azt hittem ez globális lesz, mert mindenhol előfordul ez a név.
Közben meg ha jól értem, akkor a loop() deklarálja és innen kerül átadásra a függvényeknek, ahol meg újra lesz deklarálva helyi változóként minden egyes függvényben külön-külön.Akkor azt hiszem ezzel a helyére került minden eleme a puzzle-nak.

Elméletben. Jöhet a gyakorlat... -
Janos250
őstag
válasz
Tankblock
#7119
üzenetére
Ki, de kiakadt.
A demo2 már sokkal logikusabb.

Teasüti, azt nézd!
https://github.com/MartyMacGyver/ESP32-Digital-RGB-LED-Drivers/tree/master/esp-idf
Ezt a részét tedd a setupba:
gpioSetup(16, OUTPUT, LOW);
gpioSetup(17, OUTPUT, LOW);
gpioSetup(18, OUTPUT, LOW);
gpioSetup(19, OUTPUT, LOW);
if (digitalLeds_initStrands(STRANDS, STRANDCNT)) {
ets_printf("Init FAILURE: halting\n");
while (true) {};Ezt meg a loopba:
for (int i = 0; i < STRANDCNT; i++) {
strand_t * pStrand = &STRANDS;
rainbow(pStrand, 0, 2000);
digitalLeds_resetPixels(pStrand);
}Minden egyéb mehet az elejére a setup elé.
A millis() és a delay() deklarációját kommentezd ki!
Innen:
https://github.com/MartyMacGyver/ESP32-Digital-RGB-LED-Drivers/tree/master/arduino-esp32/demo1a
esp32_digital_led_lib.h és a esp32_digital_led_lib.cpp fájlpkat másold be oda, ahol a programod van. -
Tankblock
aktív tag
válasz
Teasüti
#7120
üzenetére
Hello,
Csak azért vannak a pointerek, mert a 8 csatornát másként teljesen általánosan kezelni nem egyszerű.
A mit miértért, meg javaslom, hogy nézd meg a esp32_technical_reference_manual_en -t. 14.2.1 RMT arcitecture elmagyarázza a HW működést a Remote Controller Peripheral nak. -
Janos250
őstag
válasz
Teasüti
#7112
üzenetére
Nem okozol gondot.
Igen, az a deklaráció. Egy vektor, aminek minden eleme egy struktúra, ami tartalmazza az adott led paramétereit.
A pStrand az egy strand_t* típusú pointer:class Scannerer {
private:
strand_t * pStrand;strand_t STRANDS[] : a STRANDS[] egy vektor, aminek minden eleme strand_t típusú.
A strand_t egy struktúra, ezért adod meg neki így a kezdőértékeket, pl.: .rmtChannel = 1typedef struct {
int rmtChannel;
int gpioNum;
int ledType;
int brightLimit;
int numPixels;
pixelColor_t * pixels;
void * _stateVars;
} strand_t;tehát tartalmazza az adott ledsor paramétereit (esp32_digital_led_lib.h).
A ledType pedig ezek közül valamelyik:
enum led_types {
LED_WS2812_V1,
LED_WS2812B_V1,
LED_WS2812B_V2,
LED_WS2812B_V3,
LED_WS2813_V1,
LED_WS2813_V2,
LED_WS2813_V3,
LED_SK6812_V1,
LED_SK6812W_V1,
}; -
Teasüti
nagyúr
válasz
Tankblock
#7113
üzenetére
Szia!

Erről volna szó:
[link]
Arduino IDE alatt. Jövő héten működésre szeretnék bírni egy projektet, így a megszokott környezetben szeretném berúgni a vasat. Az ESP-IDF-fel való ismerkedés inkább hosszabb távon realizálható.
De megvettem hozzá Kolban könyvét, szóval talán lesz egy épkézláb tananyagom hozzá. -
Teasüti
nagyúr
válasz
Janos250
#7111
üzenetére
Elnézést ha túl sok gondot okozok, nem akarlak feltartani a saját munkáddal!

Csak nem tudom hirtelen hová forduljak segítségért, próbáltam keresgélni az adott library-vel kapcsolatban, de semmit nem találtam még a github-os repo-n kívül, meg egy fórum bejegyzésen kívül, ahol a készítő maga kérdezett vmit.Nekem úgy tűnik, hogy a demóban ez volna talán a deklaráció:
strand_t STRANDS[] = { // Avoid using any of the strapping pins on the ESP32
{.rmtChannel = 1, .gpioNum = 17, .ledType = LED_WS2812B_V3, .brightLimit = 32, .numPixels = 93,
.pixels = nullptr, ._stateVars = nullptr},
};
int STRANDCNT = sizeof(STRANDS)/sizeof(STRANDS[0]);Viszont a programozási ismereteim idáig nem terjednek, így nem tudom mi ez:
strand_t STRANDS[]. Ez egy objektumként deklarált tömb volna? Az object array leírások nem igazán hasonlítanak erre a kódra. A kapcsos zárójelben lévő elemek is elég furák, mi az a pont minden egyes paraméter előtt? Meg hol van melyik változó milyen típus?
És ha jól látom, akkor a frissítés az már a rainbow és a scanner függvényekből történik, vagyis eredendően más megközelítést használ mint én eddig. Én ram-ba írtam az eredményt és azt dolgoztam fel, mielőtt burst write-tal kiment a szalagra - és tulajdonképpen az egész library-ből csak annyit használtam, hogy tolja ki a szalagra az általam felállított byte tömböt.
Ha ennyit el tudnék érni ezzel az ESP-n, hogy írja ki a saját byte tömbömet a szalagra, annyi nekem bőven elég lenne. Nem kell semmi más funkció.Ha megnézem a Scanner osztályát (a class használata nekem kicsit magas, régen sem találtam elég bő lére eresztett leírást a szintaktikájáról, a spéci szimbólumok magyarázatáról), akkor ott látok pár parancsot, ami nekem kell ide, mint a
digitalLeds_updatePixels(pStrand);valamint adigitalLeds_resetPixels(strands[i]);parancsok. Viszont nem látom, hogy a pStrand az minek van deklarálva. Az egy tömb lenne?MÁS
Mi a probléma a kapcsoló üzemű táppal?
Stabilizált a táp ill. vannak bypass kondik a lap előtt?
Valószínűleg nem ide tartozik, de én PC táppal tapasztaltam hasonló problémákat, amit meg egy a közelében lévő másik fogyasztó csap le állandóan. A táp egy gőzelszívó ventilátor felett helyezkedik el és valahányszor kikapcsolják a ventilátort, a PC táp reset-el vmiért. Először azt hittem a Nano hülyül meg, televágtam bypass kondikkal, meg ESD védelemmel és még alufóliával árnyékoltam.
De még így is levágta, aztán rájöttem, hogy nem a Nano reset-el (készenléti áramról kapja a tápot), hanem a táp maga kapcsol ki. -
Janos250
őstag
válasz
Teasüti
#7110
üzenetére
Hú, nehezet kérdeztél!
Én annak idején csak betöltöttem az elején pár demót, lefuttattam, hogy működnek-e, részletesebben nem foglalkoztam vele.Megnéztem ezt a demót és a libraryt.
A demó meglehetősen el van bonyolítva, de nem tűnik túlzottan vészesnek a library használata.
Persze, lehet, hogy a gyakorlat mást mutat. Majd megpróbálok valami nagyon egyszerű programocskát írni a használatára, de most azzal szívok, hogy az ESP32 mellé tettem a dobozba a kapcsoló üzemű táp panelt, és rendszeresen megbolondul, építhetem át.Persze, ha valaki már használta ezt a libraryt, akkor közösen várjuk az instrukciókat.
-
szuszinho
őstag
Sziasztok,
Megnéztem jópár leírást, videót, de nem tudom működésre bírni az ESP8266-ot. UNO-val próbálom, de a feltöltés mindig hibával elszáll.
Tudtok egy jó leírást hozzá?Köszi!
-
Janos250
őstag
válasz
Teasüti
#7090
üzenetére
Téglásítani szerintem nem lehet.
Sebesség:
Nekem a 921600-on minden második harmadik feltöltés ki szokott akadni, ezért én
115200-on programozom, bár így tovább tart.
Nekem jelenleg a Node32S típus van beállítva, de használtam már Doit-ra állítva is.
Nem tapasztaltam lényegi különbséget. Ott nincs Flash Mode választási lehetőség.
Én a feltöltéseknél a "Q" (négyszeres) módot nem szoktam semmilyen lapnál használni, mindig csak a
"D" (dupla) módot használom, tulajdonképpen nem is tudom, melyik lapnál lehet, és melyiknél nemNéhány megjegyzés Neked is, és azoknak, akik ezután kezdik használni:
Az első teendők egyike: azonosítani kell, hogy a mi panelunkon melyik láb melyik GPIO, mert a panelokon többféleképpen van feliratozva.
Az ESP32 chipnek 34 GPIO lába van: (0-19, 21-23, 25-27, 32-39), de az Espressif ESP-WROOM-32 tokozásban a GPIO6, GPIO7, GPIO8, GPIO9, GPIO10, GPIO11 ki van ugyan vezetve a 17-22 lábakra, de nem használható, mert az a memóriát kezeli.
A panelok ezeket a lábakat általában nem is vezetik tüskére.
Mivel az 1-es soros port alapból a GPIO9, GPIO10 –et használja, ezért ezeket át kell irányítani, ha az 1-es soros portot használni akarjuk.
Pl.:
#define Serial1_RXPIN 26
#define Serial1_TXPIN 27
pinMode(Serial1_RXPIN,INPUT_PULLUP);
Serial1.begin(115200, SERIAL_8N1, Serial1_RXPIN, Serial1_TXPIN) ;A Serial2-t használat előtt példányosítani is kell , a Serial-t, Serial1-et nem, azok előre példányosítva vannak, mint pl. az UNO-nál a Serial.
Egy kis plusz infó:
esp32-hal-gpio.h:
//GPIO FUNCTIONS
#define INPUT 0x0100000001
#define OUTPUT 0x0200000010
#define PULLUP 0x0400000100
#define INPUT_PULLUP 0x0500000101
#define PULLDOWN 0x0800001000
#define INPUT_PULLDOWN 0x0900001001
#define OPEN_DRAIN 0x1000010000
#define OUTPUT_OPEN_DRAIN 0x1200010010
innen látható, melyik bit mit jelenttypedef enum {
WIFI_MODE_NULL = 0, /**< null mode */
WIFI_MODE_STA, /**< WiFi station mode */
WIFI_MODE_AP, /**< WiFi soft-AP mode */
WIFI_MODE_APSTA, /**< WiFi station + soft-AP mode */
WIFI_MODE_MAX
} wifi_mode_t;Melegedést én nem néztem, de ma még megnézem.
-
Teasüti
nagyúr
válasz
Janos250
#7077
üzenetére
Szia!
ESP32 WROOM 38pin vezérlőm megérkezett a minap. Most raktam fel Arduino alá az alaplapi meghajtókat.
Viszont lett egy rakás új menüpont az Eszközök menüben. Ezeket te hogy állítottad be? Jó az alapbeállítás? El tudom rontani (téglásítani)?
Köszönöm!
Illetve normális az ha melegszik a lap? Olyan 30-40 fokos lehet, pedig semmit nem csináltam még vele csak lóg az usb-n.

-
Tankblock
aktív tag
ESP32-IDF hát ööö még bugos is, pl
ledc_set_fade_with_step fv ha a scale attribútummal oszt még akkor is ha az nulla...
eredmény győzelmi zászló.... -
Teasüti
nagyúr
válasz
Tankblock
#7076
üzenetére
Lehet kellene egy ESP32 ESP-IDF topic, hogy ezt ne offoljuk szét.
Az a maréknyi ember, aki ebben járatos mind ide jár.
Aki a legtöbbet ESP-zik, ő meg Arduino alatt programoz.
Aki meg más IDF-et használ, ő meg nem ESP-zik. Így hirtelen akik eszembe jutottak.
Esetleg lehetne egy Arduino komplementer topik. Aki Arduinózik az ne kapjon szívrohamot, ha betéved ide. Minden más platform meg mehetne külön.
Amúgy necces úgy topikot nyitni, hogy nem tudok hozzátenni semmit.
-
Tankblock
aktív tag
válasz
Teasüti
#7069
üzenetére
Hello,
Én élvezem, hogy végre eclipse alatt tudok fordítani, és nem az Arduino IDE-be vagyok korlátozva. C nyelvet sem mostanság használtam, és van lehetőség C++ is.
Nem vagyunk egyformák, nekem a Win10 egy csalódás, és kacsingatok az új Ubuntu 17.10 után.
A dokumentáció hiányosságai okoznak fejfájást. Nem minden működik a leírtak szerint az ESP-IDF ben. Van még rajta mit csiszolni.
Az interrupt kezelést kellene megtanulnom, pont ez az ami idegesít, mert a leírtakból pont nem lehet megcsinálni amit szerettem volna --> ledc fade végén interruptban visszafele fadelni szeretném A technikai sheet szerint az összes channel tud a végén interruptot. A HW képességei lenyűgözőek. A tudásom meg igen kevés.
Feltűnö h az Arduino ideben írt villogtatás 65% lassabb --> túl nagy az overhead.
ESP-IDF ben ezek mennek eddig :
RTOS Task kezelés, Queue, Semaphore/Mutex - > binary semaphoret értem , de nem használtam
i2c scannert sikerül már írnom.
Led villogtatás is megy.
MQTT-re üzenet küldés. igaz ez kész library-t használva.
Most küzdök a ledc -vel.Lehet kellene egy ESP32 ESP-IDF topic, hogy ezt ne offoljuk szét.
-
Tankblock
aktív tag
válasz
JozsBiker
#7072
üzenetére
Hello,
Meglehet, hogy igazad van. ESP8266 köré terveztem a projectet, ha már volt itthon. és RTC is.
Wifi-t szerettem volna mert NTP vel egyszerű a sync, és ha lesz időm akkor webservert vagy akár még MQTT vel is lehet pl riasztást beállítani. A HW ben a GPIO2 n van egy 100 Ohm ellenállás után egy buzzer is. Na az a része a softwarenek sincs még kész.
Amit élveztem eddig ebben a projectben :
- az a nyák tervezés -> előtte 0 tapasztalatom volt Eaglel és nyáktervezőt sem láttam középsuli óta.
- balzafa doboz készítés -> előtte 0 tapasztalatom volt ilyenel
- működik érzés. mégha tudom hogy félkész is.A project szigorúan itthonra készült, belegondolva, hogy mennyi időt tettem bele, és a 60 Neopixel kör sem olyan olcsó. Ez nekem csak hobby, így nem feltétlen a mindenek feletti ésszerű tervezés és kivitelezés a cél.
Ha kész lesz akkor nagyszerű karácsonyi ajándék lehet pl szülőknek egy második darab ahol az elvétett hibákat már nem követem el újra. -
Teasüti
nagyúr
válasz
Tankblock
#7068
üzenetére
Érzésre esp-idf is erősen fejlesztés alatt van.
Hát mit ne mondjak, nekem eddig egy hatalmas csalódás.
Nem igaz, hogy 2017-ben az appok világában nem tudnak felhúzni egy normális frontend-et.
Neeem, e helyett csomagolj ki 20000 apró fájlt, meg parancssorból telepíts a Github repojából.
És most felraktam vmi 2 giga hangyaf.sznyi fájlocskát és még egy szövegszerkesztőt is külön rakjak fel magamnak mert azt nem tartalmaz.
Azt hittem elsőre ez vmi vicc, de sajnos teljesen komoly.
Pont ezek miatt nem használok Linux-ot se.
-
Tankblock
aktív tag
válasz
Teasüti
#7067
üzenetére
Hello,
Ez engem is érdekelne, amúgy se szeretném használi tovább az arduinot, és egy kicsit programozni.
Eddig csak annyit tudok amit a demokban leírtak, vagy amit a pcbreflux csatornáján lehet tanulni a youtubon.
Érzésre esp-idf is erősen fejlesztés alatt van. a esp32 forumja iszonyat lassú. A frissen regisztrálóknak a moderátor nézi és engedélyezi a hozzászólását.Referencia alapján kezdtem a küzdelmet.
-
Teasüti
nagyúr
Szép estét!
ESP-IDF kapcsán van vmi bevezető a programozásba vhol? Vagy vmi közösség, ahol vannak "howto"-k?
Szeretnék belevágni a natív programozásába (mert megőszülök, mire az Arduino Core funkcionalitása teljes körű lesz), de azon kapom magam, hogy igazából sehol nem írnak arról hogy kell programozni.
Vannak példaprogramok, meg van API referencia és hardveres referencia is. De nem találtam még kezdőknek szóló tutorialt. A legtöbb írás addig terjed, hogy hogy kell felrakni a fejlesztőkörnyezetet és hogy kell feltölteni a Hello World példaprogramot. De azt nem, hogy hogyan írjak programot.
Erre vmi útmutató?
Köszönöm! -
Tankblock
aktív tag
Hallo,
Valaki esetleg ESP32 programozik ESP-IDF el?
Lenne egy kérdésem,
ledc re interruptot hogy lehet hozzárakni?ledc_fade_func_install(0);
ledc_isr_register(&ledc_isr_fnc, NULL, ESP_INTR_FLAG_IRAM , NULL);setupban tovább
printf("1. LEDC fade up to duty = %d\n", LEDC_TEST_DUTY);után amikor az interrput jönne belehal...
for (ch = 0; ch < LEDC_TEST_CH_NUM; ch++) {
ledc_set_fade_with_time(ledc_channel[ch].speed_mode,
ledc_channel[ch].channel, LEDC_TEST_DUTY, LEDC_TEST_FADE_TIME);
ledc_fade_start(ledc_channel[ch].speed_mode,
ledc_channel[ch].channel, LEDC_FADE_NO_WAIT);
}
vTaskDelay()ahol: --> itt ugye nem szabad printF használni, de ha másra cserélem akkor is megpusztul.
void IRAM_ATTR ledc_isr_fnc( void * arg) {
printf("OMG, it is works \n");
} -
Janos250
őstag
válasz
vargalex
#7023
üzenetére
És ha a CCOUNT-hoz számolod az időt, amennyit aludni szükséges?
Akkor legalább nem összegződnek a hibák. Bár nem tudom, hogy deep sleepben inkrementálódik-e, soha nem próbáltam.
Azoknak, akiket még esetleg érdekel a CCOUNT használata,de nem ismerik, ESP32-re egy minta:unsigned elozo = 0 ;
void setup() {
Serial.begin(115200) ;
Serial.println(" xthal_get_ccount() ");
}
void loop() {
unsigned a = xthal_get_ccount();
Serial.print(" xthal_get_ccount() erteke = ");
Serial.println(a);
Serial.print(" kulonbseg = ");
Serial.println(a - elozo);
elozo = a ;
delay(1000);
}kiírás:
xthal_get_ccount() erteke = 1927227995
kulonbseg = 240000000
xthal_get_ccount() erteke = 2167227995
kulonbseg = 240000000 -
fpeter84
senior tag
Mi értelme ennek az RF-es túlbonyolításnak? Miért nem külső RTC ami az INT lábával adott időben ébreszti? Egy DS3231 fillérekből kijön, a fogyasztása cirka zéró, évekig elmegy egy 2032-es elemről - adott esetben az elem akár el is hagyható, a cellára közvetlenül rá lehet kötni a vbat bemenetét...
(Mondjuk ezt alapból tudnia kellene az ESP-nek a belső RTC-vel is - tartok tőle csak szoftveres oldalról nincsen meg hozzá a megfelelő támogatás)
-
gyapo11
őstag
válasz
vargalex
#7023
üzenetére
Jó nagy tekercsek kellenek a passzív vevőhöz, az egész szoba körül, de elvileg megoldható. De ha van vezeték, akkor már elviheted az esp-ig, és akkor van táp, nem kell az akkus spórolás. Igazából az egész házat kellene körbekerülni a tekerccsel, és akkor akárhol lehet a mérőpont.
Viszont ha van RTC-d az esp mellett, akkor azzal nem lehet 10 percenként alarmot generálni az ébresztéshez? Vagy ha az nincs, akkor egy oszcillátor meg egy számláló cmos ic-kből. -
vargalex
félisten
Sziasztok!
Kis ötletelésre / tapasztalatra lenne szükségem.
Úgy gondoltam, hogy ledobok (még) néhány ESP8266-ot DS18B20-al a lakás különböző pontjaira. Ezek nem feltétlenül olyan helyen lennének, ahol elérhető valamilyen konnektor, így akkus táplálásra gondoltam. Ezt 18650-es cellákkal, HT7333-al fogom megvalósítani. Hőmérséklet olvasás percenként történik (akku feszültséggel együtt). A minél hosszabb akkuidő biztosítása miatt az ESP-t 2 mérés között deep sleep-be teszem, a wifi kapcsolatot csak 10 mérésenként építem fel, így a közben mért eredményeket RTC memóriában tárolom. A kódot megírtam, szépen működik minden.
Egyetlen problémám van, amivel úgy tűnik, hogy senki nem foglalkozik (legalábbis, amilyen deep sleep megoldásokat találtam). Ez pedig az, hogy az összes megvalósításban egyszerűen fix időtartamig küldik deep sleep-be az eszközt. Nekem viszont az kellene, hogy fix időközönként történjen meg a mérés és küldje a post-ot a szerverre. Ezt próbáltam megoldani úgy, hogy a szükséges deep sleep időből levonom az indulás óta eltelt időt (a micros() függvénnyel). Több kevesebb sikerrel megy, de úgy tűnik, hogy a deep sleep időzítése sem teljesen korrekt (mintha kevesebb idő telne el, mint kellene). Most éppen valamilyen korrekciós tényezővel próbálom még szorozni, de ugye a kód futása sem mindig pontosan azonos ideig tart (jellemzően a DS18B20 inicializálása és kiolvasási ideje ingadozik valamennyit).
Be lehetne még kavarni az NTP-t, de ahhoz vagy minden kiolvasásnál mégis csatlakoznom kell a wifi-hez, vagy csak 10 percenként a post-ot tudom szinkronizálni valamilyen egzakt időponthoz. Viszont a wifi folyamatos felébresztése nyilván növeli a fogyasztást (a wifi modul bekapcsolása és a nem deep sleep-ben töltött idő jelentős növekedése miatt is).Bármilyen ötletet várok.
-
válasz
Victoryus
#7021
üzenetére
A Wemos D1 az direkt olyan kialakítású, mint az UNO, a shield-ek elvileg kompatibilisek, leszámítva, hogy a csatlakozósor legtöbb lába nincs bekötve, mivel ugye az esp-nek kevesebb a kimenete. Tehát csak azokat a lábakat tudod használni. Na meg persze a táp is különbözik, mert az esp-nek 3v3 kell.
-
Esp32 lappal is lehet használni a shield v5-öt meg a motorvezérlőt?
-
Dalee
aktív tag
Probálkoztam ESP8266-on time server használatával (NPT client library). A könyvtár csak az időt, illetve az epoch időt szolgáltatja. A dátum megállapításához szükséges, hogy az epoch idő átalakításra kerüljön év, hónap, napra. Ehhez találtam egy könyvtárt, mely több forrásfájlt tartalmaz (Time.h, Time.cpp, TimeLib,stb...).
A sketch/library-ban létrehozva Time könyvtárt, az include <TimeLib.h> nem találja a TimeLib.h-t.
Hogy lehet a program számáta láthatóvá tenni egy könyvtár különböző nevű, a könyvtár nevével nem egyező fájlokat?
-
csubuka
addikt
válasz
csubuka
#7002
üzenetére
Az elején tesztüzemben amúgy egy sima DS18B20 hőmérséklet szenzor alapján akarom változtatni a fordulatot, azt könnyen tudom ellenőrizni a való életben akár kézbe vétellel.

Ámde amin agyaltam, hogy ez a 0-10V PWM vagy analóg kimenet szabályzásra elég gyakori. Ventik meg LED akármiknek is ilyen kell. Nincsen erre egy már kész panel, ami rámegy az Arduino 5V PWM kimenetére vagy az ESP3.3V-os PWM kimenetére és az alapján előállítja a kimenő jelet a kívánt 0-10V sávban?
*Nem abszolút célom elmerülni az elektronika részében, bár kétségkívül érdekes ez és hasznos. De limitál az idő és a fontos a működő rendszer és a sikerélmény lenne

-
csubuka
addikt
válasz
gyapo11
#7001
üzenetére
Köszönöm szépen válaszod!
A bemenő PWM jelszint okés, 3.3V-os. Azzal nincs gond. A frekije kérdéses.
A kimenet PWM feszültségszintjének növeléséhez viszont akkor utána kell néznem, hogy mi kell.
(#6998) aryes: Valóban ez így a ki-be kapcsolást megoldaná kellemesen, de azért azzal is lehet spórolni, hogyha mindig a kellő intenzitással kapcsol be a rendszer és nem maxira pörgetve. Maxin kicsit túl nagy sebeséggel jön a friss levegő amúgy, szóval az nem teljesen kellemes.
Főleg ha csak pár ember kerül be, akkor kicsit túltolná a maxi fordulattal a dolgokat a szellőzés. De az totálisan igaz, hogy így mondjuk éjszakára leállhatna a rendszer szépen, szóval a vezérlésben nem árt ennek is szerepet adni. Mondjuk ugyanakkor ha nincs bent ember, akkor szépen beállítja a megfelelő CO2 szintet és mivel nem lesz mi eltolja ezért magától lekapcsol.
(#7000) Gergosz2: Természetesen, három szenzor opció van.
1) Az első CO2, ami képes 0-4V analóg jelet is szolgáltatni (UAET és PWM mellett). Arduino-val ez lehet, hogy okésabb. A PWM jel feldolgozása akár nehezebb is lehet, mint ezé. De az ESP csak 0-1V között tud analóg-digitális konverziót aszsem, szóval az nem adja, komplikáltabbá tenné a dolgot feleslegesen.
2) CO2, ami UART vagy PWM jelet tud kiadni. A PWM frekije számíthat a dolog egyszerű vagy bonyolult megítélésében. Ugyanakkor lehet az UART lenne a legkorrektebb megoldás.
3) Mindenféle gáz érzékelő (VOC), I2C kapcsolattal. Bár ilyen szűk helyen sok embernél a CO2 lenne a leginkább releváns "szennyező". Ennyi erővel akár páratartalomra is rá lehetne menni, csak érdemesebb a legrelevánsabbra vagy a legolcsóbbra, de azért nem olyan egetverő összegek ezek

-
fpeter84
senior tag
Játszott e már itt valaki valamelyik bluetooth 4.0 modullal BLE observer módot? Hiába guglizok, nem találtam egyelőre olyat hogy bármelyik modul/chipset speciális firmware nélkül egyszerű AT paranccsal BLE observer módba váltható lenne és ha broadcast-et hall akkor kiírja amit vett... Nincsen párosítás, oda-vissza kommunikáció. Az adó időnként küld egy broadcast-et és ha valaki hallja akkor azt tesz vele amit akar...
Vettem egy ilyen TPMS készletet (beépített verzió) és ennek a működését térképezem fel, hogy ne csak a saját androidos szoftverével lehessen használni, hanem pl egy otthoni szerver tudja venni a riportjait induláskor/érkezéskor, és küldhessen egy figyelmeztető emailt ha anomáliát érzékel...
Linux alól bluez stack-el már sikerült megoldanom. Találtam egy python wrappert a bluetoothctl-hez, amivel tökéletesen sikerült dekódolnom a mért nyomás, hőmérséklet, elemállapot és hirtelen nyomásvesztés adatmezőket, de ha lenne olyan pár $-os BT 4.0 modul amivel meg tudom ugyanezt valósítani AT parancsokkal, akkor lehet megírnám ESP-re is ugyanezt...
Vagy lehet rossz kulcsszavakkal keresek? Az observer/broadcaster helyett más kifejezésre kellene vadásznom?
-
csubuka
addikt
válasz
Gergosz2
#6994
üzenetére
Köszönöm a választ Neked is!
A CO2 szenzor 0-2000ppm között méri a szén-dioxid koncentrációt a levegőben. Ennek függvényében kiad magából PWM jelet, valamint UART kommunikációt is képes folytatni, hogy elárulja az éppen mért értéket.
Nem nagyon vannak alkatrészeim, sem tudásom arra, hogy erősítőt hozzak létre sajnos. Inkább az Arduino-programozós irányba mennék el, ott csak a tudás hiányzik
. Akár ESP-n is ha meg lehet oldani, akkor jöhet
Van az is.A problémáim ott lennének, hogy hogyan lehet a kimenet PWM frekijét babrálni pl. Illetve feldolgozni a bejövő PWM jelet, aminek xy frekije van. Valamennyi külső kapcsolást akkor mindenképpen építeni kell majd eszerint...
(#6996) Vladi: A helyzet pikantériáját mi sem jelzi jobban, minthogy olyat nem szabad tenni. A nyitott ablak egyrészt ugye üzleti titok kiszivárgását eredményezheti
Komolyan. Sajnos. Valamint valami jogszabályi baromság is van, hogy miért nem lehet azon az oldalon nyitható ablak, ami már csak hab a tortán. -
csubuka
addikt
Sziasztok!
Egy kis segítséget szeretnék kérni egy Arduino-val létrehozott szabályzó kérdésében.
Egy EC motoros (állandó mágneses rotor, elektromosan kommutált DC) által hajtott levegő ventit kellene szabályozni (a fordulatszámán keresztül a szállított friss levegő térfogatáramot) egy szoba CO2 koncentrációjának egy értéken való tartására. PI szabályzó szükséges gondolom.
Erre abszolút vannak gyári megoldások, annak függvényében lenne érdemes használni azokat, hogy szerintetek mennyi idő egy ilyet összepakolni egy Arduino-n vagy ESP-n? Magának a CO2 szenzornak PWM vagy UART kimenete van...
A venti fordulatszáma 0-10V-os analóg jellel vagy PWM jellel szabályozható.
Köszönöm a segítségeteket előre is :-) Hátha nem elvetendő ötlet, mert izgalmasan hangzik.
*Egy parának az biztos jelen van, hogy 10V-os PWM jelet kell kimenetnek előállítani.
-
Janos250
őstag
Nem tudok róla sokat, mert végülis nem használom (mire begyakorlom , addigra megírom a C++ programot is, és az azt csinálja, amit én akarok.)
Itt van róla egy ábra:
https://www.survivingwithandroid.com/wp-content/uploads/2016/10/mqtt_publisher_subscriber-1.png
innen:
https://www.survivingwithandroid.com/2016/10/mqtt-protocol-tutorial.html
Olyasmi a hardvereknek, mint egy fórum az embereknek.
Van egy központi szerver, a hardverek (pl. arduinoval ellátott szenzorok, stb.) neki küldik a továbbítandó adatokat.
Ennek a szervernek a neve "MQTT Broker"
Aki küldi, az a "Publisher".
A "Broker" továbbküldi az adatokat a bejelentkezett telefonokra, számítógépekre, vagy arduinokra. Az ő nevük "Subsciber".
Hogy melyiknek küldje, annak a szűrésnek "topic" a neve. (Mint az embereknél, hogy ki melyik topicra íratkozott fel)
MQTT Brokernek főként a málnát ajánlják, arduinos verzióról nem tudok. Rajta futó szoftverként ajánlják többnyire a "Mosquitto"-t.
A "Subsciber" lehet pl. telefonon egy androidos MQTT kliens.ESP32: Publishing messages to MQTT topic:
https://techtutorialsx.com/2017/04/24/esp32-publishing-messages-to-mqtt-topic/
How to use Arduino ESP32 MQTTS with MQTTS Mosquitto broker:
http://www.iotsharing.com/2017/08/how-to-use-esp32-mqtts-with-mqtts-mosquitto-broker-tls-ssl.html
How to use MQTT and Arduino ESP32 to build a simple Smart home system:
http://www.iotsharing.com/2017/05/how-to-use-mqtt-to-build-smart-home-arduino-esp32.html -
Tankblock
aktív tag
válasz
S.Milan
#6977
üzenetére
Hello,
nincs mit, használd egészséggel.
A relével meg óvatosan, főleg ha AC kapcsolgatsz vele.Elsőre nem értettem a problémádat, és úgy látom mobilról nem jó ötlet válaszolgatni, mert nem láttam át a kódot egybe.
HW ismeret sosem árt. Anno ESP-01 volt néhány órám rájönni, hogy mit lehet és mit nem.... -
S.Milan
csendes tag
Sziasztok,,
Wemos D1 mini-t használok relé vezérléshez.
A problémám az lenne, hogy amikor áramszünet van és a Wemos újraindul akkor minidig behúzza a reléket.
Olyan mintha végig ellenőrizné hogy minden láb működik e.A becsatolt programkód, jól működik.
Van erre vala mi megoldás, hogy ne működtesse a relét újraindítás után?
#include <ESP8266WiFi.h>
#include <PubSubClient.h>
#define CONTACT1 4
#define RELAY1 2
#define RELAY2 0
int prevState1;
char ssid[] = "test"; //SSID of your Wi-Fi router
char pass[] = "test1"; //Password of your Wi-Fi router
IPAddress server(192, 168, 1, 136);
const char *inTopic = "domoticz/out";
const char *outTopic = "domoticz/in";
const char *onmsg1 = "{\"idx\" : 3,\"nvalue\" : 1 }";
const char *offmsg1 = "{\"idx\" : 3,\"nvalue\" : 0 }";
const char *onmsg2 = "{\"idx\" : 4,\"nvalue\" : 1 }";
const char *offmsg2 = "{\"idx\" : 4,\"nvalue\" : 0 }";
void callback(char* topic, byte* payload, unsigned int length) {
Serial.print("Message arrived [");
Serial.print(topic);
Serial.print("] ");
for (int i=0;i<length;i++) {
Serial.print((char)payload[i]);
}
Serial.println();
if((char)payload[0] == '3') {
digitalWrite(RELAY1, LOW);
delay(500);
digitalWrite(RELAY1, HIGH);
}
if((char)payload[0] == '4') {
digitalWrite(RELAY2, LOW);
delay(500);
digitalWrite(RELAY2, HIGH);
}
}
WiFiClient espClient;
PubSubClient client(espClient);
void reconnect() {
// Loop until we're reconnected
while (!client.connected()) {
Serial.print("Attempting MQTT connection...");
// Attempt to connect
if (client.connect("espClient")) {
Serial.println("connected");
// Once connected, publish an announcement...
client.publish(outTopic,"Az espClient-nek sikerült csatlakozni az MQTT szerverhez");
// ... and resubscribe
client.subscribe(inTopic);
} else {
Serial.print("failed, rc=");
Serial.print(client.state());
Serial.println(" try again in 5 seconds");
// Wait 5 seconds before retrying
delay(5000);
}
}
}
void setup() {
pinMode(CONTACT1, INPUT);
pinMode(RELAY1, OUTPUT);
pinMode(RELAY2, OUTPUT);
digitalWrite(CONTACT1, HIGH);
digitalWrite(RELAY1, HIGH);
digitalWrite(RELAY2, HIGH);
Serial.begin(115200);
delay(10);
// Connect to Wi-Fi network
Serial.println();
Serial.println();
Serial.print("Connecting to...");
Serial.println(ssid);
WiFi.begin(ssid, pass);
while (WiFi.status() != WL_CONNECTED) {
delay(500);
Serial.print(".");
}
Serial.println("");
Serial.println("Wi-Fi connected successfully");
client.setServer(server, 1883);
client.setCallback(callback);
}
void loop() {
int curState1 = digitalRead(CONTACT1);
Serial.println(curState1);
if (!client.connected()) {
reconnect();
}
if (curState1 != prevState1){
prevState1=curState1;
if (prevState1 == LOW){
client.publish(outTopic, offmsg1);
client.publish(outTopic, offmsg2);
}
if (prevState1 == HIGH){
client.publish(outTopic, onmsg1);
client.publish(outTopic, onmsg2);
}
}
client.loop();
} -
szabifotos
senior tag
válasz
Janos250
#6912
üzenetére
Köszönöm mindenkinek a segítséget. Tehát PI+ router helyett elég egy harmadik ESP, amin webszerver fut, és erre kapcsolódunk telefonnal, hogy lássuk az állást.
Én úgy képzelem, hogy amint bekapcsoljuk a klienseket, azok felcsatlakoznak, és automatikusan kiíródik a versenyzők neve a html oldalon a számokkal. Így megoldható lenne, hogy azonosítható az oldalról, hogy ki játszik, nem csak #versenyző1 #versenyző2 lenne.
A jelküldés hogyan oldható meg? pl. Nyomás történik A0 bemeneten, akkor html kéréssel léptet egy számot az oldalon. Valami ilyesmi kellene...
Nem mondom el mihez kellene pontosan, de nem is jut eszembe milyen projektben használhatnak hasonlót, hogy példa kódot keressek

-
Tankblock
aktív tag
válasz
Janos250
#6942
üzenetére
Hello,
Ha lenne annyi időm... már nem lenne
[link] de van akinek sikerül...
Maradtam a jó öreg Raspi 3 Mosquitto / Nodered párosnál, s ha már itt tartunk akkor a SonOff Touch egyet be is üzemeltem ma.
Alexa köszöni jól el van, szobában a fő villany már szépen kapcsolható web/Alexa/touch alapon....
esp32 nél a freeRtos vagyok úgy hogy jó lenne minden részét végigpróbálni, de a TaskNotify még nincs kész. Talán a hétvégén marad némi felesleges időm....
-
Köszönöm! Egyelőre csak gondolkodok/tervezgetek, amíg nincsenek itt az alkatrészek. Úgy néz ki rendelek akkor egy esp32-es vezérlőt is.
Végül is most 4 tervem van csak: hőmérés+kijelzés, led szalag vezérlése karácsonyra, led mátrix vezérlése feliratokkal, 1-2 guruló robot amit lehet távirányítani, aztán majd szumó.
Végül is tényleg túlgondoltam, mert annyi elég, hogy maradjon bent a körben, érzékelje hol a széle, és ha talál valamit maga előtt tolja ki. -
Janos250
őstag
válasz
Tankblock
#6927
üzenetére
Ha már itt tartunk!
MQTT brokert telepítettél már ESP32-re?
Korábban, mikor néztem, nekem nem sikerült találnom, mindenütt a mosquittot ajánlották, de az meg - ugye? - nem megy ESP-n?
Ezért én félre is tettem a dolgot, és maradtam egy egyszerű server/client megoldásnál, pedig nálam is egy központi szerver van, ami tulajdonképpen a broker szerepét játssza, a topicok pedig valahol vannak.Hogy miért ragaszkodom az ESP-hez? Csak!

-
Janos250
őstag
válasz
Victoryus
#6932
üzenetére
Mindkettőben van.
Én az ESP32-t javasolom mindenkinek. Nem sokkal drágább, viszont több szabad GPIO van. Továbbá a két mag se hátrány, mert a user programja önállóan fut egy magon, a rendszeré meg a másikon, ha nem variáljuk át.Na, közben látom, már kaptál jó választ, amivel én is egyetértek.
Új hozzászólás Aktív témák
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- GoodSpeed: Munkaügyi helyzet Hajdú-Biharban: észak és dél
- Milyen monitort vegyek?
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- GL.iNet Flint 2 (GL-MT6000) router
- Lassacskán fenyőfát állítanak a hardverek
- Kerékpárosok, bringások ide!
- PlayStation 5
- Apple asztali gépek
- iPhone topik
- További aktív témák...
- Xiaomi 13 256/8GB 2024
- Karácsonyi Akció ! PHILIPS Ambilight 48OLED759/12 4K OLED Smart 120Hz Gaming TV
- Felsőkategóriás AMD Gamer PC-Számítógép! Beszámítás! R7 9800X3D / 9070XT / 32GB DDR5 / 2TB SSD!
- Új, bontatlan Kingston FURY 32GB (2x16GB) DDR5 6000MHz CL36 Beast Black RGB XMP/EXPO - 2 év gari!
- Új, felbontott Kingston FURY 16GB (1 modul) DDR5 5200MHz CL40 Beast Black - 10 év bolti garival! -
- Intel Xeon E5-2600v4 processzorok készleten 2680v4,2683v4,2697v4,2697Av4(áfás számla, 2 év garancia)
- Gamer PC-Számítógép! Csere-Beszámítás! I7 12700E / RTX 3070Ti / 32GB DDR5 / 1 TB SSD
- iPhone 15 Pro Max 256GB Black Titanium -1 ÉV GARANCIA - Kártyafüggetlen, 100 % Akksi, MS4047
- Honor 400 Lite / 8/256GB / Kártyafüggetlen / 12Hó Garancia
- Apple iPhone 13 256GB / Kártyafüggetlen / 12Hó Garancia / 100% Akku
Állásajánlatok
Cég: BroadBit Hungary Kft.
Város: Budakeszi
Cég: ATW Internet Kft.
Város: Budapest




, a gerber adatok is megvannak:
eMAAOSwv-ZZ9YZE

), akkor már neki állhatnék a natív Android-nak is.



De még így is levágta, aztán rájöttem, hogy nem a Nano reset-el (készenléti áramról kapja a tápot), hanem a táp maga kapcsol ki.
ekkold

