- Mobil flották
- Milyen GPS-t vegyek?
- Samsung Galaxy A55 - új év, régi stratégia
- Milyen okostelefont vegyek?
- Redmi Watch 5 - formás, de egyszerű
- Samsung Galaxy Watch4 és Watch4 Classic - próbawearzió
- Második bétánál jár a One UI 8
- Megvan, milyen chipet használ a Pura 80 Ultra
- Garmin Instinct – küldetés teljesítve
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
-
Mobilarena
Arduino hardverrel és szoftverrel foglakozó téma. Minden mikrovezérlő ami arduinoval programozható, és minden arduino program, board, és hardverrel kapcsolatos kérdések helye.
Új hozzászólás Aktív témák
-
adatfalo
senior tag
Köszi!
Abban van tapasztalatod, hogy hogyan lenne érdemes ezt a napi 1x-i bekapcsolást elvégezni? Találtam már időzítős reléket, illetve gondolkoztam már RTC modulon is, de nem tudom, hogy mi lenne a legjobb megoldás, sajnos az arduinonak nem olyan jó az energiagazdálkodása, mint mondjuk egy ESP-nek.
-
ecaddsell
aktív tag
Mert ipari használatra minden amit ki lehet hagyni kihagynak (extra költség) azaz direktbe hajtják a kijelzőt.
Nekem meg hobbizni (ami leginkább a prototípus készítéshez hasonlatos) sokkal fontosabb, hogy felesleges dogok nem viszik az időm, pl. úgy használhatok 3 fajta kijelzőt, hogy mikor most rá akartam keresni a kijelző kódra, hogy hány % rájöttem, hogy tűt keresek a szénakazalban... -
ecaddsell
aktív tag
OK, de fogadjuk el, hogy lehet olyan nagy felbontású kijelző sok gyors változással ahol ez szükséges lehet.
Neked meg nekem nem, de másnak esetleg igen (én erre annyi pint ami ehhez kell nem áldoznék be, meg mivel ez nincs offloadolva a procit is megfogja kicsit, de ha valakinek ez a legfontosabb rész miért ne). -
fagylalt
senior tag
Legalább 20 percet kellene tudnia folyamatos működés mellett (nem baj, ha picit kevesebb). Tehát ilyenkor az összes egység üzemelne. Egy hobbi robot "járműhöz" kellene.
Ezekről mi a véleményed? Xiaomi külső akksi -
fagylalt
senior tag
Mindenképpen akkumulátoros megoldásra van szükségem, mert ahol a "rendszer" lesz használva, ott nem lesz vezetékes hálózati áram. Az alábbi egységeket kellene meghajtani:
- Arduino Mega 2560
- 1db szervómotor (MG996R)
- 1db WiFi modul (ESP8266 ESP-01)
- 1db GPS modul (uBLOX NEO-6M)
- 1db gyorsulásmérő (MPU-6050)
- 1db hőmérő (DS18B20)
Esetleg még pár ultrahangos szenzor (JSN-SR04T) lesz rajta.(#9635) gyapo11 és (#9636) quint: Viszonylag sürgős lenne, így a külföldi rendelést kizárnám. 18650-es akkumulátoraim szint úgy nincsenek.
Itthon lehet valahol ilyet vásárolni?
-
Ha eleve boost konverter van a készülékben, akkor semmit nem kell áttervezni, 2db AA elem és kész.
Nem tudom mennyire toleráns az esp32 lefelé a tápfeszültség terén, de 2db AA elemről közvetlenül is lehetne hajtani, megspórolva a konverter fogyasztását.Ha ennek lehet hinni, 2,3V-ig merült elemekkel még elvileg működőképes az esp. Egy próbát megér.
-
Janos250
őstag
Az akku is a kapcsolóüzemű tápot hajtja. Valami a hálózatról jön, fene tudja mi. Ha a szigetelt vezetéke a hőelemnek hozzáér a fém állványzathoz, vagy a vezetékhez kézzel akárcsak közelítek, egyből megbolondul, 20-30 fok hibákat is mutat. Mindegy, már nem foglalkozok vele, áttérek - mihelyt lesz időm - Pt100-ra. Egy másik projektnél, ahol az ESP32 és egy másik IC közötti UART kapcsolat hibázik gyakran a hálózati tápról táplálásnál, ott meg szűrök, és a soros vezeték a korábbi levegőben menő drótok helyett a panelen marva lesz.
-
Janos250
őstag
Ugyebár azt mondják a hozzáértők, hogy a föld és a tápfesz közé tegyünk 100 nF-os kerámia kondit is az elko mellé párhuzamosan, mert a nagyfrekis rántásokat, zavarokat az tudja kiszűrni, az elko nem. Ugyanakkor azt is mondják, hogy a tantál kondik a nagyfrekis zavarokat is jobban szűrik. Mivel SMD változatban már elég olcsók a nagyobb kapacitású (pl. 330 uF, 470 uF) tantál kondik, logikus a használatuk. Tehát csak az elkoval kell párhuzamosan kerámia kondi, vagy a tantálnál is?
-
vargalex
félisten
Ezzel az a baj, hogy a saját fogyasztása néhány nagyságrenddel nagyobb, mint az ESP8266-é deep sleep-ben (kb. 20 microAmper).
Egyébként mérések szerint az ESP8266 megáll 170 mA-nél, úgyhogy nincs gond a HT7333-al...
-
Janos250
őstag
"sajnos nem derül ki, hogy milyen IC van rajta."
MicrOne ME2149F
https://solbatcompany.ru/ssl/u/60/90fbc6405211e58c0b8bcf05b33166/-/ME2149.pdf
https://www.aliexpress.com/item/50PCS-LOT-ME2149-2149F-ME2149F/32836018384.html
https://www.yoycart.com/Product/542542144844/ -
Janos250
őstag
"Mindig rájövök milyen jó az arduino könyvtárrendszere"
Többször előfordult már, hogy egy teljesen nyitott rendszer felbolygatta az addigi állóvizet.
Annak idején a világ számítástechnikai iparában rettentő nagy túlsúllyal rendelkező IBM sokáig teljesen kimaradt a kisgépes területről. Mikor rájöttek, akkor már késő volt, de egy ügyes húzással mégis taroltak: megcsinálták a TELJESEN NYITOTT IBM PC-t. Olyan szinten nyitott volt, hogy a BIOS ASM forrásnyelvű programját is közzétették, a hardverről is teljesen részletes leírást adtak ki.
Eredmény: taroltak.
Aztán mindenki elkezdett mindenféle klónokat, és hozzá ezt-azt gyártani. Később ugyanez történt pl. a linuxszal, most az arduinoval. -
Janos250
őstag
Kösz, tulajdonképpen csak tartaléknak rendeltem, mert amivel most bütykölök, azoknak kevés ez az áram.
Korábban valaki itt a fórumon linkelte ezt:
https://www.banggood.com/10pcs-DC-DC-3_3V-3A-Power-Supply-Module-Buck-Regulator-Module-12V-5V-To-3_3V-Fixed-Output-Car-Power-p-1216603.html?rmmds=myorder&cur_warehouse=CN
Én - azt hiszem - elsősorban ennél maradok. Eredetileg egy másik panelt terveztem használni, de - úgy tűnik - nagy a zaja, mert azzal gyakran kiakad, pedig elemről és LDO-ról stabilan megy.
Kondizásokat természetesen alkalmaztam (elko, tantál, kerámia), de nem sok sikerrel. -
Janos250
őstag
-
ecaddsell
aktív tag
Nekem méretileg elég lenne az 1.8-as kijelző is, ha kiférnék rá, lévén a nézési táv max 1m.
Egyébként megoldottam a ST7735-el a HW SPI-t is.
Mint sejtettem is fogalma sincs a könyvtárnak mit kellene használni ezért a default-ot használja.
Innen már csak az SPI default-ot kellett megkeressem és meg is lett az SPI.cpp-ben:if(sck == -1 && miso == -1 && mosi == -1 && ss == -1) {
_sck = (_spi_num == VSPI) ? SCK : 14;
_miso = (_spi_num == VSPI) ? MISO : 12;
_mosi = (_spi_num == VSPI) ? MOSI : 13;
_ss = (_spi_num == VSPI) ? SS : 15;Ezek meg a HSPI pinek amit a generátor chip-re használok, nem csoda, hogy összeakadt.
Áttettem a generátort VSPI-ra a TFT-t meg a HSPI pinekre és láss csodát megy a HW SPI és relatíve gyors is lett a frissítés (de még van mit javítanom).Na szóval összegzésnek ezek az SPI pinek ESP32-n:
HSPI
CLK 14
MOSI 13VSPI
CLK 18
MOSI 23A TFT HW SPI meg szépen lefoglalja a HSPI-t, szóval nekünk marad a VSPI...
Azért túl nincs dokumentálva a dolog...
-
ecaddsell
aktív tag
Én is újraírással frissítem. Korábban a kék háttérszínnel írtam újra, de nem volt jók a színek, szóval most nálam is fekete (de #define mondja meg mi a háttérszín szóval flexibilis).
Csak string-et használok, sprintf formáz.
Az alakzatokból max a filled rect lehet érdekes, ha az gyorsabb mint a háttérszínnel újraírás...Nem mondanám, hogy könnyebb kezelni az OLED-et, csak más. Sajnos könyvtáranként lehet más az inicializálás, kurzor kezelés (vagy nem kezelés), font méret beállítás (konstans, font nevében a méret stb), színbeállítás stb. Ezek egy része jól makrózható (én is ezt tervezem, ha eldől mik maradnak), más része nem annyira.
-
ecaddsell
aktív tag
Azt vettem észre a mérettel nagyon meredeken emelkednek az árak, szóval még akár reális is lehet amennyiért vetted. Én se vennék mást csak soros interfészes kijelzőt (hiába olcsóbb az ilyen-olyan shield).
A könyvtár linkjét köszi, ezt láttam is, csak annyi a könyvtár mint csillag az égen...
Viszont jó eséllyel megvárom amíg megjön a nagyobb kijelző, mert nemcsak a frissítéssel van gondom.
(A frissítéssel is azért inkább, mert jó pár adatot kell kiírni és ha 1 változik, akkor jó eséllyel az összes megy utána, szóval több részletben lényegében teljes újraírás van).
Minden kijelző, könyvtár variáns stb., pár extra #ifdef-t indukál és már most is rontja a kód minőségét a sok #ifdef, szóval most inkább még várok.Eredetileg 128x64-es OLED-el indult ez a projekt (dual color monochrome, felső 1/4 sárga, többi kék), aztán mikor kitaláltam legyen még ez meg az akkor láttam, kevés lesz a kijelző és megvettem a 160x128-as TFT-t.
Viszont ennél meg kiderült, hogy a textsize() az 10, 20, 30 stb. pixelt állít. Az 1-es méret az még nekem is kicsi, a 20-as mérettel meg nem fér ki az eddigi 4 sorból 2 (pl. frekvencia 9 digiten amit azért ultra gáz lenne több sorra osztani). Szóval hiába lett most 6 sor a 4 helyett, ha vízszintesen meg nem férek el (újabb tapasztalat: érdemesebb 1-el nagyobb kijelzőt venni, mint amiről azt gondolja az ember hogy elég lesz).Egyébként egy hasonló óra progi volt vsz. az első progi amit futtattam az EP32-n, ott volt a példaprogramok között és gond nélkül felment. WiFi-n szedi le a pontos időt. Nem is akartam WiFi-t használni (azóta se használtam), de pont ez esett kezem ügyébe.
-
ecaddsell
aktív tag
Én teljesen elégedett vagyok a betekintési szögével (arra amire használom tökéletes).
Fektetve használom, alul-felül nézve hibátlan, oldalra képes romlani. Ahhoz képest milyen olcsó volt több mint jó.Viszont ha te ilyen nagyban utazol akkor biztos számít a sebesség. Itt (is) keresek valami megoldást. A változásokat elég lassan frissíti a kijelző, de vsz. ez nem a kijelző hibája, hanem nem tudom, hogyan kellene rávenni az Adafruit ST7735 könyvtárat, hogy HW SPI-t használjon (ESP32). Én a jelgenerátor chipet már rég így használom és tökéletesen megy.
Szóval, ha így indítom akkor megy de láthatóan lassú:
Adafruit_ST7735 tft = Adafruit_ST7735(TFT_CS, TFT_DC, TFT_MOSI, TFT_SCLK, TFT_RST);
Az irodalom szerint a HW SPI-hoz így kellene:
Adafruit_ST7735 tft = Adafruit_ST7735(TFT_CS, TFT_DC, TFT_RST);
Viszont így egyáltalán nem megy.Nem mellékesen nem is értem honnan tudja a fenti hívásból melyik SPI-t kell használni (VSPI vagy HSPI) . Amikor a generátorhoz csinálom az inicializálást ott meg kell adni, melyiket hozza létre...
hspi = new SPIClass(HSPI);
(A VSPI is hasonló).
Az SPI könyvtár viszont automatikusan tudja, hogy pl. HSPI esetén ezek a pinek:
CLK 14
MOSI 13 -
ecaddsell
aktív tag
Jelenleg 160x128 színes TFT (Bangood, 6 USD alatt), de már tervezem, hogy áttérek 320x240-re, mert egyre csak hízik ez a projekt aztán mindig kicsi a kijelző...
tvamos
Nincs időm arra, hogy mindenkinek mindent részleteiben elmagyarázzak. Vsz. elég jól leírtam a problémát meg az ötletet is, sőt adtam kódot is. Ennyi mindent meg kell magyarázzon.
A kód amit lent leírtam nem mellékesen (most próbáltam ki öt perce) nemcsak hibátlanul fordult, hanem hibátlanul is fut (csak a az encoder nyomógombjára). Nem tudom ki hogy van vele, de nekem nem mindig megy elsőre...
Amit meg kell oldjak még az a számláló. -
Teasüti
nagyúr
Nem kell tranzisztor, ezért vettem programozót. Azon rajta van minden kiegészítő áramkör, ami egy devkit-en is rajta van. Viszont akkor kell rá tervezned legalább egy mikrokapcsolót az IO0-ra (de inkább még egyet az EN lábra a reset-hez, különben kapcsolgathatod a tápot), különben gyakorlatilag nem fogod tudni download módba tenni.
-
Teasüti
nagyúr
RX, TX, IO0, EN, Vcc, GND.
Már ha kell az auto download. Kézi reset esetén az EN és IO0-ra nyomógomb kerül ugye.Igen, nálam még van itt egy kis extra - bár nem hiszem, hogy látszik a képen. UART0-ra csatlakozik ugyanis a gps modul is majd normál üzemmódban. (Majd idővel ha eljutok odáig, akkor kikísérletezek egy bluetooth programfeltöltést a gps modulon keresztül. Az úgy sokkal kényelmesebb lesz, mint vezetékezni állandóan.)
-
Teasüti
nagyúr
Az alsó réteg egy komplett GND plane, a csatlakozó felöli végétől a modul hűtúfelületéig - az antennát viszont a lehető legnagyobb távolságban elkerüli mindenféle vezetősáv. Felül csak azért van behúzva, hogy azokat a lábakat is és a hozzájuk kapcsolódó alkatrészeket átvezessem alulra egy via-val.
(#9358) mArZsi
Paszta.Fura, mert angolul is keverik a flux-szal. Solder pasta név alatt fut a lágy ón és a folyasztószer is.
-
Janos250
őstag
A driverekkel már nekem is sok bajom volt, ezért én - ha csak lehet - innen töltök drivert:
http://www.catalog.update.microsoft.com/Search.aspx?q=CP210x -
Teasüti
nagyúr
Nem tartom valószínűnek, szerintem teljesen mindegy mikor olvasod ki azt a két bájtot - azok el vannak tárolva, amíg felül nem íródnak. Ha csak olvasási hiba lenne, esetleg menet közben kerül felülírásra, akkor ez egyszeri eset lenne és nem állna le az adatbusz sem.
A következő lépés szerintem mindenképp az anomália megmérése. -
_q
addikt
Leesett a kódban a 9 ms valószínűleg elég, mivel 2 byte-ot olvas ki a szenzorból, külön történik a hőmérséklet és külön a páratartalom kiolvasása. Adatlap szerint 6.5 ms egy kiolvasás, ahogy linkelted, a 20 már lehet sok.
Viszont mivel freertos-ban írom a kódot, a
delay(9)
, közben lehet, hogy jön egy másik prioritású task ami elkezd futni. Ennek a task-nak lehet sokáig tart, mire lefut és ismét futásidőt kap a hőmérséklet kiolvasó task. Ez nem feltétlen mindig történik meg, de ha igen akkor az a ritka eset elő állhat ami nálam, hogy néhány óra/nap után történik meg az, hogy nem jó értéket küld a szenzor.Ez így mennyire lehet esélyes? Ha igen akkor hogy küszöbölhető ki?
-
Janos250
őstag
Én nem gondolnám, hogy a wire könyvtár ne lenne jó. Amit én tapasztaltam, amikor az UNO-n ment a prg, de ESP32-n nem, akkor a következő volt a hiba:
A szenzorra (vagy másra) parancs írás után kell némi idő, mire az képes válaszolni.
A lassú UNO esetén ez nem volt probléma, de a gyors ESP32-nél az írás után, és az olvasás elé kellett várakozást betenni. Persze az is lehet, hogy ez csak véletlen volt, és én észleltem várakozási idő problémaként. -
Teasüti
nagyúr
Nem tartom valószínűnek, h összeakadnak a folyamatszálak. Arduino-ból kiindulva esélyesebb, h az I2C könyvtár bénázik el vmit, egyáltalán nem lepne meg.
Meg kéne nézni a busz forgalmát, h tudjuk mi történik.Ha az általad javasolt szerint, mindent áttennék core 1-re, mivel ugye minden ciklikus, akkor a core 0á-n semmi se lenne
Tévedés. Azon fut a FreeRTOS, meg az összes periféria mint írtam volt. Miért érzed szükségét multitask programot írni? Ha le tudod programozni lineárisan (és Arduino főként erre épít), akkor miért akarod szívatni magad több szálas kóddal? Nem tűnik indokoltnak erre a feladatra.Vagy esetleg csináljam azt, hogy core 1-en futtassak egy task-ot, ami ütemezi a core 0-án a taskokat, amiket 1x meghívok, majd törlöm? Így is ciklikus lesz, de task szempontból 1x fut csak le.
Én így programozom. Nekem így tűnik logikusak. Mivel a nulladik magon nem szabad blokkolni, ezért célszerű minél rövidebb kódokat idehelyezni. Vagy ami ritkán fut le, pl megszakításra csak rendszertelen időközönként. Olyat ami mellett sok üresjárat van. Amit egy magos procinál megszakítással kezelnék, azt itt a nulladik magon párhuzamosítva.Ennél jobban nem igazán használom ki.
Meg én nem is akarok nagyon belemászni a párhuzamosításba. Én inkább csak két egymástól független kódot választanék külön, amik teljesen különböző erőforrásokhoz férnek hozzá. Pl amit én bütykölök: motorkerékpár perifériái egymástól függetlenül működ(het)nek, van úgy 5-6 jól elkülöníthető feladat, amik ugyan használhatják ugyanazokat a szenzoradatokat, de a logikájuk egymástól teljesen független és így adja magát a párhuzamosítás. Mondjuk történik egy megszakítás amikor rálépek a fékre és ez meghív egy függvényt, ami külön folyamatként fut le a nulladik magon, aztán törlődik.
De semmi köze ahhoz a folyamathoz, ami mondjuk a ledszalagokat kezeli. Ez meg egy viszonylag számításigényesebb feladat, egy primitív grafikus motor dupla pufferes futószalaggal és FPS-ben mérem a futási teljesítményét. Ez az első magon fut.
Ebből jól látható, hogy a nulladik magot én a gyors reakcióidejű rövid kódokra használom, az első magot meg a hosszabb, nem időkritikus műveletekre. -
Teasüti
nagyúr
Elolvastam ötször egymás után, de még mindig nem értem pontosan mire akarsz kilyukadni.
CPU0-n fut az oprendszer, ha úgy tetszik. CPU1 meg malmozik, ha nem írsz rá programot. Arduino alatt a loop() fut rajta végtelen ciklusban - akkor is, ha a loop() üres.
Ha szinkronizálni akarod a folyamatokat akár a két mag között, akkor azt így lehet megoldani.Amúgy én a nullás magra nem raknék ciklikusan futó kódot, csak olyat ami meghívásra egyszer fut le.
Minden ciklikus folyamat meg mehet az egyes magra, ott legfeljebb csak a watchdog hisztizik ha blokkol a kód.
Persze ha nincs szükség kifejezetten mindkét mag számítási kapacitására, de adatfeldolgozásra meg nem mikrovezérlőt használnék. -
ZTE_luky
aktív tag
Először köszönöm szépen mindnekinek a válaszokat, új vagyok a témában, nem szeretnék elégetni semmit, és fejlődni szeretnék, ebben nagyon sokat segítenek az itt ért kritikák
értem tehát szerencsésebb töltőről, ez teljes mértékben megoldható. HA esetleg nem lenne stabil az áramforrás csak a board mehet tönkre ugye? vagy ha teljesítményre nem okés a táp akkor az. de a szalagnak nem lehet baja? mert nagyon nem csinálnám ezt a forrasztgatást újra, elég nagy meló volt
és amúgy a bekötéssel nincs gond? pontosabban úgy néz ki jelenleg hogy a szalag befut GND-re és 5V-ra és ugye usb-re a táp.
Jól értem? VIN-re mehetne akár 12V is? és mondjuk 5V-ra az arduinón meg a szalag?
nope
a szalagon WS2812B ledek vannak. köszönöm szépen a választ, neekm is feleslegesnek túlt a túloldali bekötés de nem került plusz energiába, ezért úgy gondoltam ink bekötöm, ki tudja mi hol megy szét benne később elpattan egy forrasztás és akkor másik oldalt még megkapja
Tankblock
a program egy nyan cat szerű végigfutó effekt, folyamatos színváltozással és kihagyással, tehát van amikor ledek nem is világítanak, egyidőben tehát soha nem ég az összes led.
Probléma a táppal a következő lehet:
WS2812B típusú címezhető led szalagomnál függetlenül az arduino nano-s vezérlőtől és/vagy a futtatott progamtól a ledek amint áramot kapnak, max fényerőn fehéren felvillannak pár másodpercig és utána indul csak a program. Fogalmam sincs mitől van ez a jelenség, és hogy hogyan kerülhető el. Ezt az egy dolgot találtam mi passzol a témához. Az a helyzet talán nem is zavarna engem ez a felvillanás, igaz kicsit gagyin néz ki hogy a rendszer fele van csak ilyen szalagból és a másik nem villan fel, de a fő problémám hogy elég sokat zabálhat ebben a pár másodpercben és félek vlamim rá fog menni erre, főleg hogy nagyon kényes helyen vannak beépítve a ledek. kb 120 pixelem lesz (még nincs kész a telejs) és ebből pontosan 60 darab iylen felvillanós, és egy 2A-es power bankről futna. A program elég fogyasztásbarát, hisz kihagyásal futnak végig színek a soron, tehát egyszerre nem is világít az összes led, meg persze csak egy egy színben. kérdés az hogy ez a felvillanás jelenthet e problémát a későbbiekben? hamarabbi led elhalálozást, táp túlterhelést vagy akármit, és ha igen, hogyan vehető ki belőle? A cikkben említett MOSFET sajnos nekem nem mondott sokat, ne mvagyok szakmabeli
elég ha az arduinot mini usb-ről táplálom csak árammal? --> külön igen, közösítsd a földet ebben az esetben.
ezt h érted? usb-ből a földet kössem rá az arduino földjére? ez mennyire fontos? mert már korlátozott a hely meg a kötögetés
"A lenti kapcsolásból hiányzik kondenzátor a táp vonalak közé, minnél közelebb a LED sorhoz."
milyen kondi kellene és hogy kössem? (ne haragudj de nem vagyok jártas a témában)
Tehát akkor nem probléma hogy arduinón fut a szalag árama is? tehát hogy csak usbről kap áramot az arduino, is minden azon fut át? mert ugye a rajz elcsal annyit hogy a szalag nem közvetlen az áramforráshoz van kötve hanem az arduinóról kapja az 5V-ról
-
Az a 6-20V inkább 6,5-12, a kínai lapok regulátorai nem nagyon bírják a 12V-nál magasabb betápot. Az 5V az lehet akár 3V is, az általam eddig próbált atmega*** lapok 2db AA ceruzaelemről is stabilan üzemeltek.
A képről nem tudom megállapítani a lap típusát, de ha pl. pro micro, abból van 3,3V-os is, annak viszont nem nagyon tesz jót az 5V az 5V bemenetére.
A power bank-ok azért elég stabil 5V-ot adnak ki, ha nem léped túl a korlátait. -
Janos250
őstag
Én szeretem egyetlen stringbe összerakni txt formátumban a html lapot, és egyetlen utasítással kiküldeni. SZÁMOMRA ez a kényelmes. A frissítés valóban növeli a macerát. Mivel nálam nincs túl gyors változás, és a műszer mellett állva vezérlik telefonon, én 5 sec-re állítottam az automatikus frissítés. Ez az ÉN ESETEMBEN megfelelő.
-
AcCEsS
senior tag
Szerintem azért írta, mert a kódban ugyan 115200 van beállítva, de annak futtatásáig már nem jut el a board. Viszont: "The default baud rate of ESP8266 is 74880" és emiatt a loader üzenetei a kód elindításáig 74880-el mennek. Gondolom ezért látszik minden boot első pár karaktere vagy sora bináris szemétnek.
-
Teasüti
nagyúr
A megoldás az volt, hogy nem elég a két ESP-t 1-es csatornára tenni, hanem még a routert is 1-es csatornára kellett állítani. Más kombinációval sajnos nem működött.
Igen, azt hittem ezt már megbeszéltük korábban. ESPNow adhoc hálózatának és a WLAN-nak is egyazon csatornán kell lennie!
Így akkor ez most jó? Működik? Kipipálva ez a rész?Kíváncsi lennék egy BLE vs ESP-Now összehasonlításra, melyik lehet az energiatakarékosabb vajon.
-
Janos250
őstag
Én már rég elvesztettem a fonalat, csak egyetlen megjegyzésem lenne:
Saját tapasztalat alapján az ESP32 8 (nyolc) clientet tud párhuzamosan kezelni.
Mondom ezt anélkül, hogy valaha is lementem volna a socket programozás szintjére. Én maradtam a WiFiServer, WiFiClient szintjén, oldják meg ők a socketek kezelését. -
Teasüti
nagyúr
Úgy értettem, hogy egy ESP32 duóval megoldani a gateway-t. Szenzor alatt meg a vezetéknélküli másik ESP-t értettem. Vagy használhatsz egy külső BT modult a gateway-en, pofon egyszerű programozni sima UART-vel kommunikál. A belső wifi-t meg netre ráállítani. Így nincs RAM limit se, mivel sima UART használat van csak, nem kell betölteni a BT könyvtárat. Igaz ez már nem BLE, hanem classic BT.
(Ha meg BLE modult használsz, annak meg lesz saját könyvtára amit megint csak be kell tölteni és vagy befér a ram-ba, vagy nem.)
Passz. BLE+Wifi ram korlátba ütközik, ez nem működik még natívan sem jelenleg.
ESPNow+Wifi viszont érdekes, annak elvileg mennie kéne. -
Teasüti
nagyúr
Ahogy nézem már írnak ezekről a Serial osztályban is. Hmm, meg mernék esküdni rá régen nem volt ennyi függvény ebben. Viszont üdvözítő újítások! Ha már úgyis Stream osztályt kell használni String-ekkel, akkor legalább natívan oldja meg a feladatot, ne kelljen külön ramot foglalni a saját függvényekhez!
-
Janos250
őstag
"Akik minimum 2 db ESP32-t használnak és ezek egymással kommunikálnak (hogyan teszik, Bluetooth, ESPNow, más?), plusz netre is akartak csatlakozni esetleg, ők milyen lehetőséget tudtak használni? "
Mint már többször írtam, nekem neten lóg egy szerver, ahova be lehet jelentkezni az egyik porton, és egy másik porton megy a http lekérdezés, hogy kiféle, miféle van épp bejelentkezve. Ez nem javaslat, csak infó.
-
Tankblock
aktív tag
Hello,
nem örültem meg, még,
esp-idf használom és néha megyek a development pathra néha meg a latest release pathra. Van róla rendes guide meg How to.... Nem oly ördöngős. Gitről meg lehet vadászni eléggé jó könyvtárakat is hozzá.
De igen volt rá példa h nem volt driver és hát nem maradt más hátra csak a technical reference....
Amúgy annyira nem kínai, sztem még az aurduino core is belerakható. Van kódkiegészítés, C++ hoz függvényekhez support. Refraktorálahtod a kódot. Megmuattaja hány helyen használod. Próbál írási időben segíteni.... (csak nem nekem :-P)
Az arduino ide-nek itt még van hova fejlődnie. -
Teasüti
nagyúr
ESPNow miért nem jó? Úgy olvastam, ha ugyanazon a csatornán megy, mint a normál wifi, akkor tud párhuzamosan mindkettőn kommunikálni.
Amúgy BLE-re nem gondoltál még? Sztem adja magát, gyakorlatilag erre van kitalálva, hogy szenzor adatokat küldözgessünk vele elemes kis fogyasztású eszközöknél. Mondjuk azt nem tudom, hogy a BT és a Wifi együtt működik-e. Wifi-s projektem még nem volt.Amúgy Core 0-s hibákat nálam a nagyobb delay() oldotta meg, de újabban inkább csak olyan műveleteket indítok azon a magon, ami egy meghívásra csak egyszer fut le. Minden ciklikus folyamat az 1-es magon van.
-
Janos250
őstag
"Ezt úgy érted, hogy mindegy hogy én a bemásolt task-ot core 0 vagy core 1-re teszem, a wifi fogadása mindenképpen a core 0-án, a háttérben történik? Tehát ha én egy client.read vagy client.readStringUntil meghívást csinálok, akkor már nem a klienstől fog olvasni, hanem egy már háttérben beolvasott bufferből szedi ki az adatot? "
Igen, én így tudom.
"a core 0-ra nem tehetek semmit?"
Én szoktam, ez csak egy ötlet volt, hátha..
Vagy szintén csak ötlet, a delay(10) megnagyobbítása mondjuk 100-ra. Tudod, kísérletes tudományKözben itt töprengek.
Ha jól emlékszem, az ESP az 1-es csatornán forgalmaz. Esetleg más csatornán? Úgy rémlik, valahol azt is meg lehet adni, de nem emlékszem pontosan, hol.
Nálam az egyik projekt egy erősen "zajos" wifi környezetben gyakran hibázik, de kisebb forgalmú helyeken hibátlan. Tudod, csak ötletek, kellő kritikával fogadd!Közben megtaláltam:
bool softAP(const char* ssid, const char* passphrase = NULL, int channel = 1, int ssid_hidden = 0, int max_connection = 4);
-
Tankblock
aktív tag
Hello
itt a
void loop() {
// listen for incoming clients
WiFiClient client = server.available();
if (client) {
Serial.println("new client");
// an http request ends with a blank line
boolean currentLineIsBlank = true;
while (client.connected()) {
if (client.available()) {
char c = client.read();
Serial.write(c);
....itt hasonló módon nézi meg ugyanazt.... én nem vagyok híve a túl sok változó újrainicializálásnak....
-
Janos250
őstag
Én mit néznék meg először:
1. Kiíratnám serialre azt az adatot, amit el akarok küldeni
2. Hogy a szenzor biztosan elvégezte-e a mérést. Nem tudom, milyen szenzor, de van, aminél kiadom a mérés parancsot, utána várni kell egy kicsit, mire tényleg olvasható.
De ez csak egy halk tipp. -
Teasüti
nagyúr
A jegyzőkönyv kedvéért: ESP8266 és az ESP32 is 5V toleráns a GPIO lábakon.
A mikrovezérlő mondjuk ha 8266-ot használsz és bírja az 5V-ot, akkor úgy leosztani hogy az AD konverterre max 5 V kerüljön de inkább kevesebb.
Erre írtam, hogy bírni bírja, de az AD konverter 3,3V felett nem mér. GPIO használatban nincs különbség a 8266 és 32 között.I2C kapcsán meg mérés nélkül nem lehet rá mondani semmi értelmeset. Amiben biztosak lehetünk, hogy abban a beállításban nem működik. Nekem úgy tűnt tényszerűen kezelted, ezért ugrottam rá.
Korábban is azt hiszem az én esetemben került szóba a dolog, azóta kellően utánajártam a dolognak. Főleg ha már 2 méteres buszt tervezek rajta 6 slave-vel. -
Teasüti
nagyúr
Már ne haragudj, de honnan veszed ezeket a blődségeket?
ESP32 és ESP8266 portjai 5V toleránsak, ez igaz. De ez nem azt jelenti, hogy üzemszerűen rá kell küldeni az 5V-ot egy 3,3V-os logikára. Az meg hogy éppen egy ADC-re kötnél be 4V-ot, az meg külön vicces: ugye az tiszta, hogy 3,3V-ig tud csak mérni az ADC?I2C-hez visszatérve: I2C amúgy nem igazán plug&play protokoll, a buszt minden esetben méretezni kell egyrészt vezetékezés szempontjából, másrészt a buszon lógó eszközök szerint.
Az, hogy próbapanelen random összedugdosol vmit random felhúzókkal, random vezetékekkel az vagy működni fog, vagy nem. Az meg hogy mérés nélkül egyből konklúziót vonsz és olyan kijelentéseket teszel, hogy 10 cm felett nem működőképes az I2C, az még jóindulattal is megmosolyogtató.Mellékesen nekem sikerült értelmezhető jelet kicsikarnom egy SI1145-ös szenzorból 10 méter vezetéken keresztül.
A SCL-re kellett berakjak külső felhúzót, ami kb 3k-s eredővel rendelkezik. SDA-ra nem is kellett külső felhúzó, illetve inkább csak rontott a jelen, mint javított volna.
Ami viszont fura, hogy 1k-s felhúzóval meg se mukkant a busz.Ha vki hozzáértő megnézi az alábbi képet, akkor a sárga jelnél mi az a két lépcsős emelkedés? Ha erősebb felhúzót rakok rá, akkor magasabb feszültségre fut ki a feltölés. Aztán vmiért meredeken ugrik fel a tetejére. Ezt a hirtelen ugrást nem értem. Lehetséges vmi áthallás a két csatorna közt? Mintha az SCL húzná magával az SDA-t, úgy tűnik.
-
AcCEsS
senior tag
Köszönöm, huhhh, azt hiszem felfogtam a bekötési sémát. Írtad, hogy a "Feszültség osztót pedig úgy érdemes megválasztani, hogy passzoljon az aksidhoz". ??? Az is legyen zöld színű?
Ok, ez egy fárasztó poén volt, de kb. ennyire értek hozzá. Feltételezem, hogy a két ellenállás értékét kellene jól megválasztanom, de nem tudom hogyan kell... Az ábrán látható 270k és 976k az nem jó? Panasonic NCR18650B 3400mAh aksit használok. Ja, és az egyik alkatrész, a BSS670S2L fet még a Google számára is eléggé ismeretlen, legalábbis a magyar találatokra szűrve.
-
Teasüti
nagyúr
Akkor vmit rosszul csinálsz szerintem.
Több beszámoló szerint is működik néhány méterig, ha a busz kapacitása határértéken belül marad.
Csináltam egy gyors mérést 10cm-es és 10 méteres vezetékkel, 100 Khz-en. Felhúzó mindkét esetben az Uno belső ellenállása volt (50k körül, ha jól emlékszem).10 méter telefon vezeték (ez már nem működik):
Próbaképp beraktam egy-egy 10k-s külső felhúzót. Nem igazán láttam különbséget a felfutási és lecsengési időkben. Nem teszteltem sokáig, mert már késő van. De majd lesz kedvem játszadozok vele egy kicsit.
Mindenesetre nem tűnik annyira vészesnek, egy feszesebb felhúzóval talán életre kelthető.Ami nekem fura ezen, hogy a hosszú vezetéken hogy tud megjelenni 5,6V az 5V-os Unóról USB-ről táplálva?
Talán vmi indukció a vezetékben? Fel van tekercselve. -
Teasüti
nagyúr
Még véletlenül sem kéne felhúzni a portot az akku feszültségére!
Az egy dolog, hogy 4,1V-os akkunál és 3,3V-os vezérlésnél a Q2 PNP fet talán kapcsolható*, de ettől függetlenül a mikrovezérlő lábát nem lehet felhúzni 4,1V-ra!Ráadod a HIGH értéket, kap a port egy visszirányú áramot és pápá mikrovezérlő.
Ebben az esetben az R54-et el kell hagyni!*Ami egyáltalán nem garantált, hisz az IRLML6302 Vgs(th) feszültséget -0,7 és -1,5V közé írja, a 4,1V-os akkuval és 3,3V-os mikrovezérlővel meg ugye -0,8V-ra lehet csak beállítani a Gate-et ami még nem biztos, hogy elég a teljes nyitáshoz. Ha 4V alá merül az akku, akkor már elvileg jó lesz.
Konklúzió: PNP tranyóhoz kell a driver.
-
Na ez így már igen.
Egy dolgot nem értek, de már régebb óta. Miért van az, hogy az n csatornás feteknél a pozitív ágba kell tenni a fogyasztót, a p csatornásnál pedig a negatívba? Látom ennél a rajznál is azért van egy p csatornás bevonva, hogy az osztót a negatív ágba lehessen tenni ( a pozitív oldalon nem lenne értelme az osztónak).Teasüti: tranzisztoroknál és feteknél a "nyit" és a "zár" nem pont fordított értelemben használatos, mint a kapcsolóknál?
-
Teasüti
nagyúr
Kell oda az az NPN meghajtás. PNP fetet nem tudsz vezérelni mikrokontrollerrel, mivel az pozitív feszültségre nyit és az akku kapocsfeszültsége nagyobb, mint a GPIO-é. Ha azt közvetlen gpio-ra kötnéd, akkor folyamatosan zárná az áramkört és így merülne az akku, amíg el nem éri a Vcc+küszöbfeszültséget, ha jól tévedek. Mondjuk ahogy nézem a küszöbfeszültség -2 és -4 V közt van IRL9530-nál, így még az is lehet, hogy talán még működne is valamennyire a 4,1 V-os akku esetében.
-
Hát akkor elég rosszul értelmezted.
Az a két ellenállás nem feszültségosztó, ráadásul nincs rajta az ábrán az analóg bemenet bekötési pontja. Ha a [Load] helyére gondoltad a bemenet bekötését, akkor az szépen rákapcsolná a teljes akkufeszültséget a bemenetre, amiből szépen kijönne a füst. Bár az esp8266 i/o lábai 5v toleránsak, ha jól tudom az adc-re ez nem vonatkozik.
-
Hát én tudom mi a feszültségosztó, de ezzel az ábrával engem is összezavarsz.
Ha jól tippelek, akkor a bal oldali ábrán a fet "alá" (fet és a föld közé) kell mondjuk két egyforma 10k ellenállás sorba kötve, az analóg lábat, ami a mérést végzi, pedig a két ellenállás közé kell kötni? Ebbe bele kell számolni a fet-en eső feszültséget is, nem lesz egyszerű számolni, bár igazság szerint én azt csinálnám, hogy az alsó határértékre merített akksira kötném az egészet, csinálnék egy mérést, és azt az értéket hardcode-olnám a programba, mint kikapcsolási/riasztási határértéket.
Vagy a [Load] helyére kell a feszültségosztó?
A Vdd pedig ez esetben nem a táp (3,3V), hanem az akkumulátor + ága. -
Teasüti
nagyúr
Azt tegyük hozzá, hogy a LAN oldalon a kliensek gateway címnek a router LAN oldali címét látják, vagyis a router címét kell megadni, ugyanazt amin a webes felületet nyitod meg.
Ezt is minden eszközön be kell állítani a saját IP cím és subnet mellett, ami nem dhcp-vel kapja meg a kapcsolati adatokat.
Egyszerűbb lenne az életed, ha olvasgatnál kicsit a helyi hálózatokról, ahogy korábban javasoltam. -
vargalex
félisten
Ahogy írtam, amiről a képet készítetted az a WAN, azaz Wide Area Network (tehát a routered külső lába, amin az internet felől látszik). Az most más kérdés, hogy a Digi a WAN oldalra is privát IP címet adott neked (100.x.x.x tartomány), tehát ezt az internet felől sehogy nem fogod elérni (lehet, hogy nem is akarod, tehát nem biztos, hogy gond neked).
A belső kliensek (legyen az vezetékes, vagy vezeték nélküli) a LAN, azaz Local Area Network-hoz kapcsolódnak, azaz abból a tartományból kapnak IP-t.
Ezek egy része a wifi kliensek, WLAN
A Wifi kapcsolat a WLAN, azaz Wireless Local Area Network, ahogy írtam a LAN része.
Remélem így tisztább lesz.
Új hozzászólás Aktív témák
Hirdetés
- Anime filmek és sorozatok
- Kerékpárosok, bringások ide!
- Macron betiltatná az EU-ban a közösségi médiát a 15 év alattiaknak
- Mibe tegyem a megtakarításaimat?
- Formula-1 humoros
- Viccrovat
- One otthoni szolgáltatások (TV, internet, telefon)
- gban: Ingyen kellene, de tegnapra
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- bitpork: MOD Júni 13 Augusztus 2- szombat jelen állás szerint.
- További aktív témák...
- ÚJ PS5 Slim - FW 8.40 - Lemezolvasó - Lua Loader - Lua játék - Lapse
- új, bontatlan, iPhone 16E gyárilag kártya-független, apple világgaranciával
- Üzletből, garanciával, Macbook Pro Retina 16" 2019, Gray i9 64GB RAM 1TB SSD Radeon Pro 5500M
- Üzletből, garanciával, Macbook Pro Retina 16" 2019, Gray i9 64GB RAM 2TB SSD Radeon Pro 5600M 8GB
- MacBook Pro 14" M1 MAX - 32GB / 1TB (2021) - 1 év garancia
- Samsung Galaxy A16 128GB Kártyafüggetlen, 1Év Garanciával
- ASUS TUF Gaming F16 FX607JV-QT212 Notebook
- BESZÁMÍTÁS! Gigabyte H510M i5 11400F 16GB DDR4 512GB SSD GTX 1070Ti 8GB Rampage SHIVA TT 500W
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5800X 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- ASUS Radeon RX 7600 V2 Dual OC 8Gb - Aqua gari 26.12.12 ig
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest