Hirdetés
- Mobil flották
- Xiaomi 15T Pro - a téma nincs lezárva
- Samsung Galaxy Fit 3 - keveset, de jól
- iPhone topik
- Fotók, videók mobillal
- Motorola Edge 70 - többért kevesebbet
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Kezünkben a OnePlus 15 és az Oppo Find X9-ek
- Csőtörés lett a Red Magic 11 Pro gyötréstesztjéből
- Samsung Galaxy Watch6 Classic - tekerd!
-
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
-
Tankblock
aktív tag
válasz
cog777
#23911
üzenetére
Maradjunk annyiban hogy ismerkedem vele, és itthon én Linuxot használok.
VSCode-ot használok a projectjeimhez, mert van Git integráció és C++ support.
VScode ill terminálból lehet a west futtatni.
a west kezeli a gitről a modulokat/layereket.Device drivereket a Vendornak illene adnia, a Device tree ill overlay lehet adott HW tuningolni. Elméletileg applikáció fordítható, mert nincs hozzákötve HWhez.... POSIX kompatibilisre írod meg akkor boardok között átvihető a kód, ha azonos hw driverek elérhetőek... Téli szabadság alatt majd játszok vele, nem biztos h ESP lesz a cél HW...
-
Janos250
őstag
válasz
cog777
#23898
üzenetére
Én nem szoktam a flageket állítgatni.
Amit beidéztem, ez írta ki ESP-n Arduino alatt:Serial.print("C++ standard: ");Serial.println(__cplusplus);
Serial.print("GCC: ");Serial.println(__VERSION__);
Az már korábban volt, amikor a C++11 volt a preferált. Most a 20.
De mint írtam, a 23 zöme is benne van. Irodalmi adat a 90 %, azaz 10%-ot még nem fordít le, szintaktikai hibát jelez. -
Janos250
őstag
válasz
cog777
#23887
üzenetére
"lemaradtak a c++ szabványokban"
Ez a lemaradás azért nem annyira súlyos:
C++ standard: 202002 (ez ugyebár a C++20)
GCC: 14.2.0
Az már más kérdés, hogy a későbbiek is elég jól benne vannak, GCC: 14.2.0-ben, de nem minden, ezért hivatalosan csak a C++20-ig támogatott.
A C++23 kb. 90 %-ban támogatott, a C++26 Csak kísérleti flaggel (-std=gnu++2c)
A C++23-ból amit kipróbáltam, azok mentek, a C++26-ot nem próbáltam
Az
auto(x)
unique_ptr / shared_ptr
nyelvi elemeket használtam, azok működnek.
Az auto(x) különösen tetszik.
Ha másban is csak ennyire lennénk lemaradva, az nagyon jó lenne! -
válasz
cog777
#23894
üzenetére
Hihetetlen jol optimalizalnak a c forditok.
Az biztos. Amikor oszcilloszkópot csináltam UNO board-ból (amire egyébként nem alkalmas
) kellett kicsit optimalizálnom a kódot, hogy magasabb frekvenciát tudjak vele elérni, és akkor néztem a fordító által generált ASM kódot, sok olyan megoldás volt benne, ami eszembe se jutott volna, de azért így is tudtam rajta gyorsítani. 
(Kellett bele pár ASM sor ahol számolni kellett az utasítások periódusidejét a pontos időzítés miatt, meg pár trükk a C kódban, ami rövidebb gépi kódot generált.)Mivel abszolút hobbista vagyok, megtehetem, hogy ilyenekkel cseszem el az időmet
persze ha ez lenne a szakmám, nyilván én is a mindentudó lapokat részesíteném előnyben. Amúgy pedig az AVR-eket azért szeretem, mert értem, hogy mi folyik benne, mindent én irányítok, kb mint annak idején a C64 esetén. Az ESP-k már az én agyamnak túl komplikáltak, az RTOS miatt például. Ez nem jelenti azt, hogy nem használom arra, amire csak azt lehet.
Hozzám hasonlóan gondolkodik az 8bit guy a youtube-on, ha ismeri valaki, az ilyen kattantak számára tervezett és vitt gyártásba egy 8bites gépet, amit a C64 MOS 6510 procija köré tervezett, modern perifériákkal, azoknak, akik szeretik a hardver közeli programozást. -
Postas99
őstag
válasz
cog777
#23277
üzenetére
Csak megjegyzésként mondanám, hogy a héten láttam egy nagyon érdekes oktató anyagot arról, hogy lehetne másképp megvalósítani egy "multitaskingot", ahol akár egyenként tudod a szálaknak megmondani hogy melyik magon fusson. Lehet érdemes lenne kipróbálnod neked is és nem kell túl sok mindent átalakítani a kódban hozzá.
Valami fenomenális és rohadtul jól magyarázó anyag, és az egész 13 perc.
[ITT]
Esetleg ismerte valaki ezt a módszert, használja már? Elgondolkoztam, hogy ezentúl így fogok minden kódot elkészíteni.Vélemények?? Szívesen átbeszélném ha valaki már megnézte.
-
Postas99
őstag
válasz
cog777
#23230
üzenetére
BUÉK Mindenkinek!
Ezek az eszközök analóg értéket adnak (feszültség)
Nincs dokumentáció megadva, hogy ekkora meg akkora füstnél milyen érték jelenik meg a kimeneten. Ezt neked kell kitapasztalni. És itt jutottunk el a kalibráláshoz.
Nem lehet kijelenteni, hogy ha 50% komparálási értéket veszel alapul, hogy tudod egyáltalán hogy az mennyi füstöt jelent. Vagy csak 75% is elegnedő vagy ki tudja mennyi.Ezekkel az a gond, hogy ha még meg is írod a rá a programot, ahhoz hogy jó működjön nem lehet EXhas kitalálni hozzá egy értéket.
Tényleg jobb megoldás egy gyári füstértzékelő, és max ott keresgetsz rajta egy pontot amivel tudod detektálni, hogy füst van a házban. A legjobb megoldás a piezo lábára párhuzamosan kötni egy esp32 nano valamelyik lábát megfelelő illesztéssel. A táplálás pedig szerintem szintén megoldható valamelyik forrpontról.
Sajnos jobb nem jut eszembe. -
válasz
cog777
#23231
üzenetére
ESP32-re lehet pl. ESPEasy-t telepíteni, ami tud külső szerverre adatot küldeni (Blynk.io, thingspeak, ilyesmik), onnan meg tudod tovább feldolgozni, értesítést köldeni akár.
Telepítésről van infó a logout cikkemben, röviden letöltöd, modulodnak megfelelőt ráflasheled, ESP32-nél 2 lépésben kell. Utána webes felületen megadod milyen bigyók és hol csatlakoznak. Rules részben tudsz szabályokat felállítani, "programot írni" hozzá.
Controllereknél kiválasztod, h hova szeretnél adatot küldeni, az eszközöknél bepipálod, h adat küldése controllerre, ennyi... Leírva bonyolultabb, mint végigmenni a beállításokon és megcsinálni. elég alapos doksi van hozzá, a fórumon is sok infó van. -
Postas99
őstag
válasz
cog777
#23223
üzenetére
Én a helyedben nem használnám:
[Típusok]
Ezek alapján a füst érzékelő a : MQ-135 Gas Sensor
A paraméter típus alapján ez több modell típus is lehet, ha nem jót vettél akkor semmire sem lesz jó. Ezen felül akár 48 órán át is eltarthat a kalibrálás.Janos250: Ha a megfelelő modult válasszuk akkor akár arra ia jó lehet.
Szénmonoxid érzékelő: MQ-7 Gas Sensor -
Tankblock
aktív tag
válasz
cog777
#22846
üzenetére
Szia
ezen parancsok C++ 11 verziótól elérhetőek, nincsen semmi köze a FreeRTOS-hoz, működnek FreeRTOS nélküli C++ projectekben ahol a minimum feltétel C++ 11 supportálva van. ESP-IDF menni fog emlékeim szerint C++ 17 is....
A freeRTOS egy scheduler / ütemező ami abban segít hogy REAL TIME lehessen a program. Ehhez ad eszközkészletet. Nem kötelező használni.
Megszakításból threadSAFE módon adatot módosítani azért nem egyszerű.... Erre van a freeRTOS, lehetne más is.....GCC 11.2 használ a ESP-IDF
[link] itt lehet nézegetni mit is szupportál
-
Istv@n
aktív tag
válasz
cog777
#22802
üzenetére
Köszben rájöttem, hogy hol hibáztam.... Azt gondoltam, hogy a freertos task-ok úgy viselkednek mint a loop, de nem.
Betettem egy for ciklust, illetve az időzítést a vTaskDelay()-al oldottam meg és így futott rendesen.
Viszont valamiért akkor is megszakad az mqtt kapcsolat, ha külön taskban futtatom az sql insertet és az mqtt kezelést. Pedig próbáltam még külön cpu maghoz is rendelni őket...
A miért kell kérdésre: jelenleg csak a webes felület és az sql van használatban, aminek az adataiból egy grafanás dashboardon tudom nézni a rendszer aktuális állapotát, illetve a weben tudok kapcsolni/időzíteni néhány dolgot. Nemrég viszont beállítottam egy home assistant-ot, amibe szeretném ezt is beintegrálni a jelenlegi meghagyása mellett.
Egyébként találtam egy HA addont, ami az mqtt adatokat át tudja küldeni egy sql adatbázisba. Még próbálozom egy kicsit, de ha megunom, lehet, hogy megpróbálom azt a vonalat... -
Tankblock
aktív tag
válasz
cog777
#22704
üzenetére
Ha nagyon nagyon fontos:
[link]#ifdef FREERTOS#define malloc(size) pvPortMalloc(size)#define free(ptr) pvPortFree(ptr)#endifCsak ne feledd definiállni FREERTOS nevű definet
Az általad említett ArduinoJSON könyvtár leírása szerint hacsak nem több szálból szeretnél 1 JSON t írni nem lesz gond...
kérdés h megéri e, kell e, jó ez a SW arhitektúra.... kell e több szál vagy sem.
-
cog777
őstag
válasz
cog777
#22701
üzenetére
Exception-ok mukodnek, bena voltam.
Amugy megtalaltam hogy a heap3 memoria allokacios strategia thread safe-et csinal a malloc-bol es a free-bol:
heap_3– simply wraps the standardmalloc()andfree()for thread safety.
platformio.ini-be tettem ezt:
board_build.freertos.heap_model = heap_3 -
Tankblock
aktív tag
válasz
cog777
#22695
üzenetére
Json és a TCP socket - rakd egy egy külön threadbe és Queue keresztül kommunikálj vele mint egy driverrel, nem fog összeakadni.
Emlékeim szerint stack külön van szálanként kezelve --> FreeRTOSKérdés embedded környezetben miért szeretnél folymatosan memóriát foglalni... az pont a legnagyobb pocsékolás. std::vector és egyébb tároló társai tudnak olyat h initkor lefoglalnak egyben nagyobb helyet és akkor nem emgy folyamatosan a memória foglalás sem....
std::vector<int> v; v.reserve(110); // Not required, but improves initial loading performance
lehet méretezni, meg lehet fix tömböt is használni..... -
Tankblock
aktív tag
válasz
cog777
#22693
üzenetére
Szerintem a Thread Safe probléma nem a memória foglalásnál lesz a legnagyobb probléma sokkal inkább azon erőforrásokkal (i2c, SPI) /memória területekkel amiket egyszerre szeretne több szál is elérni. ezeket mutexel, semaphorral,.... és megfelelő arhitektúra tervezéssel lehet kiküszöbölni. std::atomic erre kiváló megoldás lehet....
libek használatakor érdemes belenézni először a dokumentációba (megemlíti e a kívánt viselkedést vagy az ellenkezőjét), majd utána a kódba is, legtöbbször statikusan le van foglalva a kellő hely.
-
Tankblock
aktív tag
válasz
cog777
#22684
üzenetére
Az a kérdésem mire szeretnéd használni ezt.
HA szálakból szeretnél folyamatosan memóriát foglalni akkor azt lehet mutex segítségévrl kölcsönösen kizárni h a new(), delete(), malloc, free, függvények ne akadjanak össze. Azt azért gondold át hogy ez a megközelítés kell e neked, mert van sok másik megoldás is.
-
válasz
cog777
#22676
üzenetére
Nem biztos! Mivel ezek passzív IR szenzort tartalmaznak, amik az emberi test "hőjelére" aktiválódnak, nem mindegy az se, hogy hol, milyen környezetben, milyen körülmények között használod! Ha a háttérben erős napsugárzás van, vagy ha télen vastagon fel vagy öltözve, az elfedi a hőjelet, és a szenzor nem fog látni téged. Ez nem a szenzor hibája, hanem korlát.
-
cog777
őstag
válasz
cog777
#22640
üzenetére
Na mit szivtam... mar a vegere rajottem hogyan kell feltolteni egy programot, de zavart hogy ki-be kellett huzkodni a csatlakozot, reset gombot nyomogatni stb hogy feltoltsek barmit.
Egyszer csak bevillant, toltsem fel a BOOTLOADER-t! Es voala, el kezdett mukodni a debugger is, nem csak a feltoltes es futtatas.
Almomban sem gondoltam hogy bootloader nelkul jon
Most tokeletesen mukodik! -
válasz
cog777
#22634
üzenetére
Na most néztem már utána, mi ez a nano esp. Ez egy esp32 s3 chip, natív usb-vel, nincs rajta usb-ttl chip. Valami usb-otg beállítást kell módosítani, hogy működjön a serial port, de most nem jut eszembe mi az.
szerk: ez: [kép]
Esetleg válaszd ki a generic esp32-s3 lapot a nano helyett és próbáld úgy.
Amúgy a debug lehet, hogy csak a tx1-ről fog működni külső usb-ttl adapterrel, bár nem akarok hülyeséget mondani. -
-
-
válasz
cog777
#22581
üzenetére
Áhh, értem. Valami koordinátor kell akkor is. Google: ESP coordinator. Nem próbáltam. Okos otthon topikban lehet, h vkinek működik így.
-
Postas99
őstag
válasz
cog777
#22415
üzenetére
Tudsz de akkor tedd bele, hogy ha nem talál fájlt akkor
File file = SPIFFS.open("/startup.txt");
if (!file || file.isDirectory()) {
writeFileWithPrint("/textFile.txt", "1");
}
void writeFileWithPrint(const char *path, const char *content) {
Serial.print("Creating file with SPIFFS.print(): ");
Serial.println(String(path));
File file = SPIFFS.open(path, "w");
if (file) {
file.print(content);
file.close();
Serial.println("Text file created and written successfully");
} else {
Serial.println("Failed to create text file");
}
}Akkor hozza létre.
-
-
lanszelot
addikt
válasz
cog777
#21081
üzenetére
Először is köszönöm szépen a választ.
Nem tudom mi az az ESP32. Kell e hozzá Arduino /nano, uno, meg
a/?
Minek a Bluetooth benne? Azzal mit csinálok?
Vagy a kamerán kívül tud még valamit? Ahhoz van a Bluetooth?
Erre írtam hogy nem tudom mi az.
Csak bele ugrott valahogy a kosaramba, és mit lehet ilyenkor tenni
-
-
Undoroid
őstag
-
Tankblock
aktív tag
válasz
cog777
#20995
üzenetére
milli [ m ] > mikro [ u ] > nano [n] ha jól emlékszem...
A boardom 200 nano Amper fogyaszt amíg vár.
amit te írtál az 200 mikro Amper (azaz 1000x e) még mindig nagyon szép érték.
(Mondjuk ha az akkumulátor önkisülési tartoményéban vagy akkor mind 1, a célom az volt hogy 5.5 uA alá tudjak menni, azt hiszem sikerült :-)
A szerkesztő játszik velem -
Tankblock
aktív tag
válasz
cog777
#20966
üzenetére
Ezért terveztem saját boardot, rtc megy LiPoról közvetlen, amikor kell FETet nyit az LDO felé és ESP32-őt ébreszt, az megtartja a FETet. ESP-NOW protocollal villámgyorsan elintézi amit kell, majd lekapcsolja magát. RTC 200 [nA] eszik a 70 [uA] el szemben. Wifi meg mire felcsatlakozik addigra ESP32 már rég nem kap feszt.... 3000mA LiPo alig merül, ha megtámogatom napelemmel és töltővel örök élet + 2nap.... ha negatív hőmérsékelt is játszik akkor meg LiFePo4 és még az LDO-t is kikapcsolhatom (Bypass kapcsoló beépítve az LDO nál...)
Státus : 2. áramkör reviewzom (az első nem lett tökéletes) és SW íródik, igaz esp-idf ben és nem arduinoban .....
-
válasz
cog777
#20266
üzenetére
thingspeak esetleg, meg van más is, ami mqtt-ből adatokat tud megjeleníteni. Mail küldés is van, android app van. Értesítést, ilyesmit sohasem engedélyezem, de gondolom bekapcsolható, ezeket nem tudom sajnos.
-
válasz
cog777
#20250
üzenetére
Ahonnan mindent is: a sarki hobbielektronika boltból.
Nagy lapokban adják, méretre kell vágni. Van több féle, van, ahol minden forrasztási hely külön van, meg olyan is, ahol hosszú vezetősávok vannak, amit meg kell szakítani, meg olyan is, ahol hármasával vannak összekötve. Mindegyikből tartok, mikor melyik a praktikusabb, azt használom. -
t72killer
titán
-
t72killer
titán
-
JozsBiker
aktív tag
válasz
cog777
#12485
üzenetére
Köszi szépen, én is nézegettem ezt is, de itt is az volt a konklúzió, hogy valami nem kerek.
Viszont, talán megvan a megoldás. Erről az oldalról kipróbáltam a középső példaprogramot, és legnagyobb meglepetésemre egész szép eredményt adott ( anélkül hogy az áramkörön bármit is változtattam volna ). A soros plotteren a következő képet kaptam ( a nyílnál kapcsoltam be egy ledes asztali lámpát mint fogyasztót ):
Mivel a hardver ugyanaz volt, valószínűleg sok múlik a programon. Sőt még az sem mindegy, hogy a soros monitorozás sebessége mennyire van állítva. A fenti 9600 baud volt,
átállítva 115200 -ra ez lett az eredmény:
Szóval az áramkör rendben van, az ismereteimet kell bővítenem valamellyest. Megpróbálok rájönni mi okozhatja az eltéréseket, megírom ha jutok valamire, hátha másnak is jól jön.
-
gyapo11
őstag
válasz
cog777
#12483
üzenetére
Lehet logikat modositani ugy hogy nem inditod ujra?
Nem tudom, a plc-khez én se értek, de ilyet szeretnék. Inkább egyszer dolgozzak vele többet, mint minden apró módosításnál mindent leállítani, mert jön a reset.
Ha egy szelep megszűnik a programban, akkor nincs mit tenni, le kell választani a hardware-ből és vége. Esetleg azt a portot megkapja valami más, szóval veszélyes is lehet otthagyni és nem rácsatlakoztatni az új eszközt. Ha változik a hw, akkor az már nem annyira simple user feladat.
Ezt a módosítást kifejezetten arra az esetre gondolom, amikor apró változtatások kellenek, mert nem jól találta ki a user, hogy 1 percig világítson a lámpa vegy kettőig. Még az is lehet, hogy ezek a paraméterek egy külön adatblokkban csücsülnek, és a parser onnan olvassa ki az adott sor értelmezésekor, így még könnyebben módosíthatók. Az időzítő minden beolvasáskor összeveti a futó időt a fölső határral, és ha túllépte egy adatmódosulás miatt, akkor leáll. Abban az egy loopban lehet, hogy hosszabb lesz, de a következőben már jó.Pl 3 blokkbol egyet kitorolt a felhasznalo. Mi legyen ha eppen a masodik volt futas alatt. stb.
Szerintem megvárnám a loop végét, és akkor olvasnám be a programot, illetve az elején a változásokat, amit még a pc írt oda, hogy ne az arduinonak kelljen kitotózni, hogy a változások milyen portokat érintenek. A megszűnő vagy megjelenő eszközök portját, alapállapotát, időzítőket, hogy amikor a parser elölről kezdi beolvasni a sorokat, akkor már minden be legyen állítva. Az időzítőkön még gondolkodnom kell, ott még nem látok tisztán.
Mindenképpen megjegyzem az esp32+python ajánlást. Mindkettő ismeretlen egyelőre, jócskán kell tanulnom hozzájuk, de a jövő arrafelé mutat.
-
gyapo11
őstag
válasz
cog777
#12478
üzenetére
A python egy programnyelv. Akkor az esp-ben a python értelmező futna, és byte kód helyett python forrást kellene átküldeni? Ez azzal járna, mintha arduino forrást vinnék át, vagyis reset. Ha egy csomó kapcsoló, relé, triak, szelep, motor van valamilyen állapotban, időzítők futnak, akkor egy reset nem túl jó. Ha elmentem az állapotokat, és reset után beolvasom, akkor talán folytatható minden ugyanonnan, de ezt ha lehet elkerülném. Lehet olyan program, ahol semmi ilyesmi nincs, ott nyugodtan lehet resetelni.
Az alapötlet az, hogy nem vadi új programokat töltök rá, hanem az ott levőt kicsit változtatva. PL. hozzáadok új feladatokat vagy törlök másokat, ez az egyszerűbb, a bonyolultabb, hogy meglévő feladatok változnak, ezen még gondolkodnom kell hogyan tudom egyeztetni az aktuális állapotot az új részekkel. Pl. megy a szivattyú 5 perc időzítéssel, most 3 percnél tart, az új programban viszont 7 vagy 2 perc időzítés van, egyiknél 2 perccel meg kell hosszabbítani az időzítést, a másik esetben viszont azonnal ki kell kapcsolni a szivattyút.
Lehet, hogy ezt is a pc-vel kell feldolgozni, és infót tenni a byte kód mellé, hogy mit kell csinálni, jobb ha nem akarom ezt is bezsúfolni az arduinoba.
) kellett kicsit optimalizálnom a kódot, hogy magasabb frekvenciát tudjak vele elérni, és akkor néztem a fordító által generált ASM kódot, sok olyan megoldás volt benne, ami eszembe se jutott volna, de azért így is tudtam rajta gyorsítani. 
persze ha ez lenne a szakmám, nyilván én is a mindentudó lapokat részesíteném előnyben. Amúgy pedig az AVR-eket azért szeretem, mert értem, hogy mi folyik benne, mindent én irányítok, kb mint annak idején a C64 esetén. Az ESP-k már az én agyamnak túl komplikáltak, az RTOS miatt például. Ez nem jelenti azt, hogy nem használom arra, amire csak azt lehet. 
Bocsánat, hülyeséget mondtam! Előfordul. 
Új hozzászólás Aktív témák
ekkold
- Sima Vs.Windows Logitech Mx keys s plus és hagyományos Mx keys magyar bemutatása. Új videó linkel
- Telefon felvásárlás!! iPhone X/iPhone Xs/iPhone XR/iPhone Xs Max
- Samsung Galaxy S21 Ultra 256GB, Kártyafüggetlen, 1 Év Garanciával
- AMD AM5 Setup! Akár kamatmentes rèszletre is! Èrdeklődj!
- Logitech Webkamera MeetUp 120 -os látótér, mikrofon, 4K Ultra HD
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest