Sziasztok!
Csináltam ESP32 mikrovezérlővel egy több csatornás hőmérsékletmérő eszközt.
Működik a mérés szépen, viszont a WiFi AP-hoz kapcsolódása nagyon bizonytalan.
Van, hogy bekapcsolás után szinte azonnal megy, van, hogy hosszú percek után, van hogy nem
is csatlakozik.
Már széttúrtam mindent nem látom a probléma megoldását.
(Közben egy van az az infó, hogy a C8-C9 kondenzátorokat a lehető legközelebb tegyem az MCU-hoz. Oda tettem, de nem változott...)
Ideteszem a Platform.IO (Arduino framework) nagyon egyszerű programját, amivel a WiFi-t tesztelem, a jelenség
a leírt.
Amit megfigyeltem, hogy ha a számítógép USB portjára van bedugva az eszköz és nem kapcsolódott az AP-hoz
akkor ha megnyitom a soros portját az eszköznek (pl. Putty, RealTerm, ...) kapcsolódik!
Találkoztatok már ilyennel?
#include <Arduino.h> #include <WiFi.h> #include <driver/adc_common.h> const char *ssid = "xxx"; const char *password = "xxx"; uint32_t ind = 0; void setup() { setCpuFrequencyMhz(240); adc_power_off(); btStop(); Serial.begin(115200); delay(3000); pinMode(LED_BUILTIN, OUTPUT); WiFi.mode(WIFI_STA); WiFi.setTxPower(WIFI_POWER_19_5dBm); WiFi.disconnect(true, true); delay(100); WiFi.begin(ssid, password); Serial.print("Connecting to WiFi .."); while (WiFi.status() != WL_CONNECTED) { Serial.println(ind); delay(1000); if (ind > 20) { WiFi.disconnect(); digitalWrite(LED_BUILTIN, HIGH); delay(300); digitalWrite(LED_BUILTIN, LOW); ESP.restart(); //WiFi.disconnect(true, true); //WiFi.begin(ssid, password); //ind = 0; } ind++; } Serial.println(WiFi.localIP()); Serial.println("WiFi kapcsolódott"); } void loop() { if ( WiFi.isConnected() ) digitalWrite(LED_BUILTIN, HIGH); delay(100); digitalWrite(LED_BUILTIN, LOW); delay(2000); Serial.println("LED"); }
Itt a kapcsolás: sch
És egy részlet, hogyan van az ESP32 a nyákon: kep
A 2-es lábra odaforrasztottam már nagyon közelre egy 33 uF-os kondit.
Mit nem veszek észre?
Hozzászólások
Nem megint valami energiagazdálkodási beállítás hülyeség? Hacsak nem az AP vacakol.
Nem gondolom, van több ESP32 eszköz rácsatlakozva - azonnal mennek.
AP: Unifi UAP-AC-LC
esp_wifi_set_ps(WIFI_PS_NONE); hátha segít csak melegedni fog :)
vagy az ap-n fixre tenni a wifi channelt-t ha auton van
UAP-AC-LR fix channel: 1 (40 MHz sávszélesség)
Szerintem a C6, C7-nek a 10 uF nagyon kevés! Az adatlap szerint a tápnak le kell tudnia 500 mA-t, gondolom nem állandóan, hanem csúcsban. Én C6-nak legalább 100 uF-et, C7-nek 220..470 uF-ot raknék. Amikor próbál az AP-hoz csatlakozni, akkor hirtelen sok energia kellene, ami nem fér el 10 uF-os kondikba. Ha van szkópod, megnézheted a VDD3V3-at a modul oldalán.
Szkóppal a cégnél meg tudom nézni.
Az C6, C7 értékét az AMS1117 adatlapjából vettem.
Érdekes, hogy amikor próbál csatlakozni, és megnyitom a soros portját (Putty, RealTerm, ...) újraindulás után simán kapcsolódik - egyébként a lejárt időnként újraindul (csatlakozás nélkül ugye)
Egyetértek. Ha táp pufferről van szó, akkor inkább legyen nagyobb.
A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.
Szerintem a delay()-t felejtsd el.
https://www.esp8266.org/
már melyiket?
(egyébként a teljes programban a "vTaskDelay(...)" van)
Mindegyiket. Egyébként a loop a setup vége után indul.
https://www.esp8266.org/
?
Mi van, ha az AP-t 2.4 GHz only-ra állítod?
ott van/volt.
A loopban lehetne ellenőrizni, hogy kapcsolódott-e, és ha nem, akkor próbálkozzon újra.
Amikor nem csatlakozik, el sem jut a loop-ig. Az elején lévő ciklusban növelgeti az "ind" változót -> meghaladja a 20 értéket -> újraindul. Ezt teszi örökhajtósan. Érdekes, hogy ha ilyenkor az eszköz
soros portját megnyitom, újrainduláskor azonnal csatlakozik...
Ha a soros port megnyitáskor jó, akkor azzal az RTS DTR logikával van valami.
Erre nem gondoltam így. Köszönöm.
Azon töprengek, hogy kiveszem az UMH3N IC-t, nem lesz így automatikus indulás flash-eléskor. Van EN és IO0 gomb - marad kézzel indítás.
A 10uF az EN lábon furcsa, inkább 100nF kellene.
Régebben egy
www.esp32.comfórumról vettem, 100 nF-al nem ment az automatikus flashelés indulás (se Arduino IDE-ben, se Platform.IO-ban sem)Innen: https://electronics.stackexchange.com/questions/569788/how-esp32-auto-u…
Ezt a minimális példát futtattam:
Induláskor (flashelés után, USB újracsatlakozása után) ezt kapom (20x):
..
[WiFi] WiFi is disconnected
[ 3284][V][WiFiGeneric.cpp:362] _arduino_event_cb(): STA Disconnected: SSID: gentoom, BSSID: 18:e8:29:fb:75:08, Reason: 15
[ 3285][D][WiFiGeneric.cpp:931] _eventCallback(): Arduino Event: 5 - STA_DISCONNECTED
[ 3292][W][WiFiGeneric.cpp:955] _eventCallback(): Reason: 15 - 4WAY_HANDSHAKE_TIMEOUT
[ 3300][D][WiFiGeneric.cpp:975] _eventCallback(): WiFi Reconnect Running
[ 3308][V][WiFiGeneric.cpp:97] set_esp_interface_ip(): Configuring Station static IP: 0.0.0.0, MASK: 0.0.0.0, GW: 0.0.0.0
...
(és ezt se mindig, most pl. 5x próbáltam, és mindig kapcsolódott - de nem ez a jellemző.)
Majd megnyomom a gombot:
rst:0x1 (POWERON_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13104
load:0x40080400,len:3036
entry 0x400805e4
...
[WiFi] WiFi is disconnected
[WiFi] WiFi is disconnected
[WiFi] WiFi is disconnected
[ 1201][V][WiFiGeneric.cpp:362] _arduino_event_cb(): STA Disconnected: SSID: gentoom, BSSID: 18:e8:29:fb:75:08, Reason: 4
[ 1202][D][WiFiGeneric.cpp:931] _eventCallback(): Arduino Event: 5 - STA_DISCONNECTED
[ 1209][W][WiFiGeneric.cpp:955] _eventCallback(): Reason: 4 - ASSOC_EXPIRE
[ 1215][D][WiFiGeneric.cpp:975] _eventCallback(): WiFi Reconnect Running
[ 1224][V][WiFiGeneric.cpp:97] set_esp_interface_ip(): Configuring Station static IP: 0.0.0.0, MASK: 0.0.0.0, GW: 0.0.0.0
[ 1300][V][WiFiGeneric.cpp:355] _arduino_event_cb(): STA Connected: SSID: gentoom, BSSID: 18:e8:29:fb:75:08, Channel: 1, Auth: WPA2_PSK
[ 1301][D][WiFiGeneric.cpp:931] _eventCallback(): Arduino Event: 4 - STA_CONNECTED
[ 1327][V][WiFiGeneric.cpp:369] _arduino_event_cb(): STA Got New IP:192.168.3.135
[ 1328][D][WiFiGeneric.cpp:931] _eventCallback(): Arduino Event: 7 - STA_GOT_IP
[ 1331][D][WiFiGeneric.cpp:996] _eventCallback(): STA IP: 192.168.3.135, MASK: 255.255.255.0, GW: 192.168.3.1
[WiFi] WiFi is connected!
[WiFi] IP address: 192.168.3.135
Kapcsolódik. Lehet az AMS117 IC-nél lévő kondik (10 uF) kevesek?
Kipróbáltam ESP32 dev boardon, ha ez segít, nekem nem jelentkezik a hiba, reset , usb megszakit , vissza, csak connect van :
IDE:
Version: 2.3.2
Date: 2024-02-20T10:04:35.814Z
CLI Version: 0.35.3
Copyright © 2024 Arduino SA
https://blog.claryel.hu
Wemos d1 mini esp32 , kb 4-5 éves , a programoddal ami a dev boarddal megy ugyanezzel az ide-vel, (wemos d1 mini esp32 board) nem működik sehogy:
https://blog.claryel.hu
Nodemcu-32S modulon nekem is működik.
Egyre jobban a hw. a probléma... Annak ellenére (is), hogy pont erről a dev modulról vettem a soros, flash, ... részeket.
Nem ide tartozik, de miért nem megy régi jópáréves D1 mini ESP 32-n, vagy legalább figyelmeztetne, gondolom van egy jópár verziója az ESP 32 nek, aztán találd ki melyik verzióhoz melyik ide való.
https://blog.claryel.hu
platformio -ban lehet valogatni.
Normális dolog egy kódba blokkolásokat írni? Itt a delay()-re gondolok. De az is gyönyörű, hogy while (true), majd a belsejében if () return;. Ezt lényegesen szebben is le lehetett volna írni.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Igazad van, de a delay() már vTaskDelay(). Lehetett volna szép, de itt ennél a teszt volt a lényeg. if {} - volt benne valami, kivettem az if maradt
A vTaskDelay() csinál taszkváltásokat, s közben a többi task fut? Az if ()-ben nem a kapcsos zárójeleket hiányoltam, hanem az volt fura, hogy a kilépési feltétel nem a while ()-ban volt, hanem a ciklusmagból az if () végrehajtó részében csak úgy távozunk a függvényből.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Amit megfigyeltem, hogy ha nincs kapcsolódva soros porton program (pl. PuTTY, RealTerm, ...), akkor hiába nyomom az EN (RST) gombot,
nem történik semmi. De amint van a soros porton (megnyitva) program, működik az EN gomb! Azaz újraindítható!
Nem lehet, hogy te a wifiben keresed a hibát, de közben a soros kezelés van bénán, blokkolósan megírva, így ha a soroson nincs forgalom, egy zárt ciklusban vár, majd emiatt nyilván timeout-ol a wifi is, mert nem kapta vissza a wifi kezelése a vezérlést? Közben meg szénné debugolod az esetleg hibátlan wifi kezelést. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Lehet. Csak azt nem tudom, hogy lehetne megkeresni a hibát. Közben gondolkodtam, lehet a CH340C DTR/RTS vonalán van a hiba?
Esetleg vedd ki az összes Serial.begin, Serial.println és egyebeket, azok úgyis csak debugoláshoz kellenek.
Meg aztán fene tudja, mi megy IT-ből, mi megy alap szinten, mi DMA-zik, milyenek a megszakítási prioritások, és azok jók-e úgy, használ-e például egy timer-t, amelyet már mi magunk is. Egy kész függvénykönyvtár elemeit a saját programba integrálni a legritkább esetben áll annyiból, hogy #include <valami.h>, ennél ez lényegesen összetettebb probléma szokott lenni.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Kivettem. Ugyanaz a jelenség. Néha kapcsolódik, néha nem. Ill. EN gomb csak akkor megy, ha van soros program. Függetlenül a Serial.begin()-től.
Az nem lehet, hogy a nyamvadt UMH3M IC rossz (automata flasheléshez )? Teljesen tanácstalan vagyok.
Csináltam egy faék egyszerű programot. Semmi WiFi, semmi Serial.begin(), csak villogtatom a LED-et fél másodpercenként.
Hogy lássam az EN lábon lógó gomb működését a setup()-ban egy 5 mp-es késleltetés, mire induljon a loop-ban a villogás.
Szóval, tápmegszakítás után megvan az 5 mp késleltetés. Viszont utána nyomogathatom az EN gombot - nem csinál semmit (persze a LED villog - fut a program). HW hiba?
Mivel több - azonos gyártásból származó - ESP32 lap van, gondoltam megnézem a többit is. Ugyanez a jelenség.
Csináltam egy másik kapcsolást is régebben, de abbamaradt a projekt.
Most elővettem a szerelt NYÁK-ot, és ezt a pici teszt (WiFi-st is, LED-est is) programot letöltöttem.
És oppá, ugyanaz. Tehát erős a gyanúm, hw. De mit néztem be? (ugyanúgy pl. az EN gomb megnyomására nem tesz semmit,
WiFi vagy csatlakozik vagy nem)
Ez a régi áramkör: https://imgur.com/a/qBh8FY2
Az a C4 nekem nagyon ellenszenves. Mennyiben tekinthetjük normálisnak bizonyos körülmények között az RTS-re kötött 10 µF-ot? D1-ben mi a fantázia?
Nem világos, miért gyanakszol hardware hibára, ha több nyákon ugyanaz a jelenség. Vagy arra gondolsz, hogy a tervezés van elrontva? Szerintem erre tudsz tesztet írni. Lehet olyasmit, hogy időbélyeggel logolsz egy rakás dolgot, aztán teszel bele ideiglenesen debug logokat. Például logold ki, mi volt a reset oka. Power on, brown out, watchdog, software, hogy csak így hirtelen négy lehetséges okot említsek.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
A C4 - 100 nF-os kondira gondolsz? Valszeg a C2. amúgy anno ebből vettem:
https://electronics.stackexchange.com/questions/569788/how-esp32-auto-u…
D1-ben egy régi változatnál volt lehetőség egyéb tápot is adni, ennek volt védő szerepe - bent maradt.
A hardver hibára én ebben az esetben már a tervezési hibámra gondolok.
Tesztet átgondolom.
MCU Swithes bal alja, C4, 10 µF. Nem tetszik, mert DTR magas és RTS alacsony szintnél RTS-t nem hagyja lemenni alacsony szintbe, csak nehézkesen. Ronda, de nagyon.
Ennek ellenére érzésből inkább a firmware bugjára gondolok.
Szerk.: Közben megfejtettem: a régi kapcsolási rajzon néztem, mert azt linkelted, s arra válaszoltam. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
itt is az EN lábra 10 uF-ot javasol:
https://randomnerdtutorials.com/solved-failed-to-connect-to-esp32-timed…
OK, de nekem nem elsősorban ez volt a bajom, hanem az, hogy ez terheli az RTS-t. Meg lehet úgy tervezni, hogy ez ne így legyen.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Így le tudom kérdezni a RESET okát. De még nem találtam meg a kapcsolatot a WiFi-s dologgal...
Azért téged nagyon meg kéne verni, hogy a táblázat neve és a buffer neve között egy kis- illetve nagybetű a különbség, az is valahol a belsejében.
Azért fontos a reset oka, mert egyrészt kiderül, hogy elhasal-e a cucc menet közben. Ha a táp beszakadása miatt van brown out reset, az is kiderül. A watchdog is. Én kiíratom annál a műszernél, amelynek a firmware-ét írom, cseppet sem haszontalan.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Jogos a verés.
Én is sokat használom másnál, ez egy hirtelen íródott. Az okés a reset oka, csak még ebben a POWER_ON és SOFTWARE_RST.. kivételével más nem volt.
Így szoktam:
"reset_verbose_str" ill. "reset_verbose_array"
Ez valami önálló wifi modul, vagy hogyan képzeljem el? Inkább gyanús a firmware.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Igen. DS18B20 értékeit tolja WiFi-n keresztül egy szerverre. Vagy konkrétan mire vagy kíváncsi?
Ja, most eszmélek, te a második, relés eszközre gondolsz? Az egy kijelzős termosztát.
Arra, hogy az MCU és a 2.4 GHz-es antenna között mi van. Tehát van egy MCU meg egy wifi modul, vagy valahogy másként kell elképzelni?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Az ESP32-WROOM-32E chipben alapból van a WiFi modul és a PCB WiFi antennával szerelt.
ESP vs wifi instabilitast nalunk tap problema okozott. 12V akkura volt kotve, par oraig ment stabilan aztan le-leszakadt 1-2 orankent aztan egyre gyakrabban, majd vegul fel nap mulva teljesen, de masnap meg neha felcsatlakozott par masodpercre. ahogy merult az akku es a dcdc egyre kevesbe tudta tartani az aram igenyt egyre inkabb instabil lett a wifi resze...
Jó tudni. Köszönöm, figyelek erre is.
Eredeti rajz szerint C3, C4 felesleges, pergésvédelmet csináld meg a firmware-ben. C2 szörnyű RTS miatt. A piezo meghajtása egy rémálom, azt így nem szabad. Felfutó élnél a felső FET nagy árammal rántja meg az MCU tápját, amiben lehet egy megcsuklás.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Amikor az RST ill. BOOT gomb használva van, akkor még nem is "működik" az MCU. Bekapcsoláskor ezek döntik el run/flash módba induljon. Nem jól értelmezem?
Piezot most nem használom, a későbbiekben lehet majd ilyen igény.
Az a piezo csak egy elnevezés, ez egy sima hangkeltő elem lenne. De még nincs kidolgozva, akármi lehet.
A FET-es eszköz megy régóta panasz nélkül. Ezt csak ezért tettem ide, hogy erre letöltve ezt a minimális (itt mutatott) programot letöltve ugyanazt csinálja.
Félreértettél, nem a relé meghajtóról beszélek. Az jó. :) A mikrokontroller portját meghajtó felső, p-csatornás FET-jéről beszélek. Akár piezo-t hajtasz, akár valami önálló szirénát, az ott kapacitív terhelés lesz. Amikor bekapcsolod a portot magas szintre, kinyit az MCU belsejében lévő felső FET, a csatornaellenállásán keresztül töltődni kezd a portra lógatott kapacitás. Tehát rövidzár lesz, az áramot az MCU-ba épített FET csatornaellenállása fogja korlátozni. A hozzávezetéseknek van ellenállása és induktivitása, ezért rövid időre megrogyhat az MCU tápja. Bár a reset infó alapján nem ez a baj.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Ja, értem. Itt az lehet, hogy egy ellenállást teszek oda?
Teljesen más. Gondolkodtam, lehet ilyen, hogy részleges boot? Vagy nem megfelelő? (pl. 10 uF-os EN lábon lévő kondi miatt) Ill. rögtön sleep-be megy a WiFi, azért nem kapcsolódik, csak ha
a soros kommunikáció "felébreszti"? Ill. az általa indított reset?
Ignoráljátok, ha bődületes hülyeség. Minden eszembe jut már.
Bevallom őszintén, nem használtam soha ezt az MCU-t. Hardware fejlesztő vagyok, ezért általánosan tekintve van rálátásom, de a konkrét eszközt nem ismerem. Engem az a 10 µF több ok miatt frusztrál. Az egyik az EN lábon kialakuló alacsony slew-rate. Nincs ezzel baj akkor, ha az EN láb Schmitt-trigger bemenetű. A másik gondom, hogy van egy tranzisztoros logika, ami RTS == 0, DTR == 1 esetén alacsony szintbe húzza az EN nevű lábat. Igen ám, de annak a 10 µF-nak a kisütő árama az RTS-en fog átfolyni, az U1-ben lévő, 14-es lábhoz csatlakozó n-csatornás MOSFET drain-jébe. Az a FET fogja kihúzni a kondenzátor áramát nagy kínkeservesen.
Ezek nagyon amatőr megoldások, digitális rendszerekben félig analóg módszerek. Ha van egy statikus hazárd egy digitális jelben, arra nem az a korrekt megoldás, hogy tegyünk rá egy gyógykondenzátort, amelyik lenyalja, eltünteti a néhány nanosecundumos tüskét, hanem az, hogy hazárd mentes kombinációs hálózatot tervezünk. Ez lehetséges, az az elve, hogy amelyik jel változásakor létrejön a statikus hazárd, azt a jelet elimináljuk, kiegyszerűsítjük, s az így kapott termet beledekódoljuk a többi közé, így hiába változik több jel egyszerre, az a jel áll, mint a cövek, amelybe bele sincs vezetve az az input, ami most éppen változik, s a hazárdot okozza.
Itt a 10 µF valamiféle időzítés, de akkor azt tessék korrekt módon csinálni, nem efféle gányolással! Vagy tessék olyan boot loadert írni, amelyiknek erre semmi szüksége. Írtam PIC32MZ-re boot loader-t, és meg tudtam úgy csinálni, hogy nincsenek benne efféle megoldások, illetve fel lehet éleszteni a szerkezetet akkor is, ha program letöltése közben jönne áramszünet. Végig kell gondolni alaposan, mi történhet, mit szeretnénk, és algoritmizálható. Nem muszáj mindig a már kész, sokak által használt, de esetleg nem jó megoldásokat használni.
Ha nincs jól megcsinálva a bootloader, akkor lehet olyan, hogy részlegesen tölti le a futtatandó kódot.
A többi kérdésedre az a válaszom, hogy mivel számítógép, bármi lehet. De ha nincs rendes reset a wifinek, akkor miért nincs? Legyen! Két feltétel van. A hardware legyen olyan, hogy a firmware a szükséges beavatkozásokat, műveleteket el tudja végezni, a firmware pedig legyen olyan, hogy azokat el is végezze. Ez tényleg ennyire egyszerű. Persze, amikor fél nap alatt eredményt akarunk, akkor ez nem megy. Végig kell diszkutálni, mit kell csinálni, kell bele logolás, utána meg logokat kell olvasni. Ha van elég RAM, akkor kell mondjuk egy legalább 16 kiB-os, vagy kétszer ekkora log buffer, amelybe időbélyeggel - bekapcsolástól eltelt idő másodpercben µs felbontással - írsz formátumozottan logot, onnan meg küldi ki UART-ra pl. 115.2 kbaud-dal. Vagy USB-n lehet lekérdezni rendszeres időközönként.
Ilyen logolós függvényt a vprintf(), vsprintf(), vsnprintf(), va_start(), va_arg(), va_end(), meg a ... függvény argumentum segítségével lehet írni.
Elvileg lehet, de sokkal jobb lenne egy erősítő fokozat oda. Komolyan egy MCU portjáról kell hajtani közvetlenül egy kis hangszórót, vagy annak elektronikáját? Elhiszem, hogy nagyon vagány és olcsó, de ne legyünk ennyire spórolósak, aztán majd kitépjük az összes hajunkat azt keresve, mitől labilis a cucc.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Ennek az MCU gyártója (ESPRESSIF) csinálta a boot loaderét, nem kívánok nagyon mélyen belemászni.
Az RTS/DTR használatának ilyen módját szintén a gyártó is használta. https://dl.espressif.com/dl/schematics/ESP32-Core-Board-V2_sch.pdf
És ebben is: https://docs.ai-thinker.com/_media/esp32/docs/nodemcu-32s_product_speci…
Egyébként ennek az MCU-nak van sok memóriája (520 kB SRAM)
Nem vagyok annyira liberális, hogy tagadjam a tekintélyelv helyességét, de ebben az esetben azért óvatos lennék. Ennek az MCU-nak a gyártó cégénél is valódi emberek, mérnökök dolgoznak, a munkájuk hol jobb, hol kevésbé jó. Ha valami nem elég jó, ahelyett van lehetőség saját magunknak jobbat csinálni. Persze, ha gyanítjuk, hogy az elég jó, akkor viszont vélhetően máshol van a hiba. De mindig legyen ott, hogy ne essünk csak azért hasra, mert azt valamit ismert cég csinálta. És? Ott tévedhetetlen emberek dolgoznak? Ha azok lennének, nem adnának ki az MCU-khoz errata-kat, amelyben egy rakás hiba, azok megkerülési módja van leírva, ha egyáltalán meg lehet kerülni a hibát, és nem az a „megoldás”, hogy ne használd azt a funkciót vagy modult.
Én helyedben debugolnám, mi történik, meg nagyon nézném azt a kódot. Sok esetben hardware anomália is debugolható, hiszen kiderül, hogy valami örökké busy állapotban marad, nem azt válaszolja, amire számítasz, valami hülyeség van egy regiszterben, bármi. Aztán kiderül, valahonnan lemardt a volatile kulcsszó, ami megint csak nem látszik azonnal, ha nem gondolod végig, hova kell és miért.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Azon a rajzon 1 nF-ot látok, nem 10 µF-ot.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Igen. A másikon meg 1 uF. Tehát tényleg túllőttem a 10 uF-al.
Meg kellene érteni, minek mi az oka, nem hol ezt, hol azt a rajzot elhinni. Más megfogalmazásban méretezz oda egy olyan kondenzátort, ami alkalmas a feladatra. Ha az jön ki, hogy egy szempont szerint nagy kellene, egy másik szempont szerint nem szabad ott akkorának lennie, akkor pedig módosítani kell a firmware-t. Nem szent tehén az, hozzá szabad nyúlni a kódhoz.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Igen. Most az MCU adatlapját bújom, eddig olyant találtam, hogy min. 50 us idő kell az EN (CHIP_PU) lábon. Szóval tisztázni akarom a képet erről.
https://www.espressif.com/sites/default/files/documentation/esp32_datas…
(19 oldal.)
Az RTS-t nem lehet a kívánt ideig alacsony szintben tartani, miközben a DTR-t magasban? Azaz nem lehet ezt efféle analóg gányolás nélkül megoldani?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Hát ezt én nem tudom. Gyártó.
Gondolom, jobban költői a kérdésed....
Ebből 24 µs-os időállandót számoltam. Tehát 10 kΩ-os felhúzásnál 3.3 nF már elég. Mivel 50 nA a maximális bemeneti áram, akár 100 kΩ is lehet a felhúzás, akkor meg az 1 nF is bőven jó. Már persze, ha nincs ott belső felhúzás.
Szerk.: persze nem muszáj az alsó határ közelében lenni, egyezzünk ki 10 nF-ban. Az a 10 µF hülyeség, hacsak nincs valami olyan szerepe, hogy a handshake megszűnése után maradjon sokáig resetben az MCU, amíg a host oldalon a PC-s program eljut valameddig, de efféle dolgokat nem időzítéssel, hanem kommunikációval - pl. USB-n - kell intézni.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Köszönöm!
10 nF-ra átcserélem.
Nincs szerepe a 10 uF-nak. Vakon követtem pár "komolynak látszó" weboldal ajánlását. Aztán megmutatta ez a beszélgetés, hogy méretezni, átgondolni. Amit amúgy is szoktam tenni, de ebben az esetben
tényleg a gyors idő faktor meghatározta a felületességem... Amire persze nincs mentség, ha összeadom a rátöltött plusz időt, elején kellett volna odafigyelni.
Köszönöm. Holnap teszt.
Bocs, elvétettem! 100 nF a jó megoldás, mert 725 µs az időállandó! Eléggé fejben akartam megoldani. Kb.: T = 50 µs / (ln (3 V / (3 V - 0.2 V)))
Azért nem 3.3 V, mert levontam belőle a tranzisztor szaturációját, de ezt figyelembe vettem ott is, hogy nem 0.6 V-os komparálást helyettesítettem.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Ugye az eredeti összefüggés: Ut = U0 * (1 - exp(-t / T)), illetve T = R * C.
De azt se feledjük, ezt az időt nem egy RC-tagnak kell megtartania, hanem a DTR, RTS-nek, szóval szerintem kisebb kondival is mennie kellene, ha a host oldali kód jó.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Igen
Közben én is átszámoltam: T = 725 us -> R = 10 k-ból C kb. 73 nF.
Szerk: mielőtt írtad volna te is.
100nF - 10kOhm van a devkit c-n. Resettel parhuzamosan megint csak egy 100nF.
Mi van, hogyha egyszerűen leszedem a C2 (10 uF) kondenzátort? És marad a 100 nF-os C3 ebben a részben. Tudom 10 nF-ban maradtunk. De ezt gyorsan meg tudom tenni.
R7 miatt nem biztos, hogy az történik, amit szeretnél, a C3 nem sül ki elég gyorsan, ha rövid a GND felé húzó impulzus.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Csináltam egy gyors szimulációt (hamarosan meglesz élőben)
Itt az eredmény. Nem látok érdemi különbséget (működés szempontjából) hogy 1 vagy 2 kondi van (ugye 2x időállandó)
Rossz a modelled. Nem ezt kellett volna szimulálni. Amikor RTS == 0, DTR == 1, rövid idő alatt nagy árammal kisütöd a 100 nF-os kondenzátort, majd utána kicsit több, mint 50 µs múlva éred el a 0.6 V-os alacsony szint maximumát.
Ha ott a 470 Ω, akkor elkezd kisülni a 100 nF, de ha hamar elmúlik ez a feltétel, akkor simán 0.6 V fölött marad, s onnan 10 kΩ-on keresztül töltődve újra nő a feszültség.
Azaz tud lenni olyan rövid kisütő impulzus, ami a 470 Ω-mal nem működik jól, de anélkül igen.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Én most RTS és DTR hiányát (ugye USB-s tápnál nincs) próbáltam közelíteni.
Az RTS / DTR változás csak az automatikus flashelésnél van.
Nyugtass meg, hogy ez az RC-tag nem a CPU reset akar lenni!
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Nemnem. Ez csak egyszerű RC tag. Csak megcsináltam, egy egyszerű egyenlet is ok lett volna :)
Itt a reference design, nem kell feltalálni semmit:
https://www.espressif.com/sites/default/files/documentation/esp32-devki…
Ha valaha volt is olyan hiba, hogy túl rövid volt a jel valamelyik lábon, akkor azt már javították az esptool.py-ban.
Köszönöm! Igazából a szükséges kapacitás értékéről, kiszámításáról volt már szó.
Onnan indult ki, hogy több sémán más és más a C értéke. Miért?!
1) typo
2) mas kovetelmenyek, korulmenyek
3) rossz design
4) random, AI+"szakerto" altal generalt tartalomba futottal
Vigyazz, a router is lehet ludas! En belefutottam egy ilyenbe. Keress ra a neten, vannak ra tippek; nalam egy asus router-en az 'IGMP Snooping' -ot kellett kikapcsolni, utana megjavult. De sok hasonlo advanced setting van meg egy mai router-ben, keresgelj, mert altalaban valami apro hulyeseg beallitas, ami altalaban oke, de az ESP ugye nem egy 'normalis' wifi kliens, es gyanitom, jopar dolgot nem ugy csinal, ahogy a router szeretne.
Illetve nalam meg olyan beallitas is van a router-en, hogy 'dobalja' a klienseket 2.4 es 5ghz kozott, mert 'nagyon smart', es igy akarja ki-enforce-olni, hogy a kliens menjen 5ghz-re. Az asus router-en 'smart connect' -nek hivjak, ez is lehet az oka; mindenesetre nezegesd meg a router-ed is, mert siman lehet ott a gond! Esetleg probalj meg egy alap hotspot-ot csinalni a laptop/mobil -lal, es nezd meg, azon is dobalja-e, akkor kiderul, hogy nem veletlen csak a router-ed probal okos lenni.
Értem. Ez egy MT és Unifi AP kombó.
Évek óta használom ESP32 kliensekkel hiba nélkül.
Amiket leírtál, körbefutom, megnézem.
A megoldás végül ez lett:
* az EN és IO0 ágban lévő 470R ellenállásokat ki kellett szedni, rövidre zárni a helyüket
* Az IO0 ágban lévő 100 nF-os kondenzátort ki kellett venni. (ez fontos)