[megoldva] ESP32 WiFi ritkán jó

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.

Szerkesztve: 2024. 05. 24., p – 14:39

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

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)

Mi van, ha az AP-t 2.4 GHz only-ra állítod?

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...

Szerkesztve: 2024. 05. 25., szo – 10:47

Ezt a minimális példát futtattam:

#include <WiFi.h>

const char *ssid = "xxx";

const char *password = "xxx";


int LED = 2;

int btnGPIO = 0;

int btnState = false;


void setup() {

  Serial.begin(115200);

  delay(10);


  // Set GPIO0 Boot button as input

  pinMode(LED, OUTPUT);

  pinMode(btnGPIO, INPUT);


  // We start by connecting to a WiFi network

  // To debug, please enable Core Debug Level to Verbose


  Serial.println();

  Serial.print("[WiFi] Connecting to ");

  Serial.println(ssid);


  WiFi.begin(ssid, password);

  // Auto reconnect is set true as default

  // To set auto connect off, use the following function

  //    WiFi.setAutoReconnect(false);


  // Will try for about 10 seconds (20x 500ms)

  int tryDelay = 500;

  int numberOfTries = 20;


  // Wait for the WiFi event

  while (true) {


    switch (WiFi.status()) {

    case WL_NO_SSID_AVAIL:

      Serial.println("[WiFi] SSID not found");

      break;

    case WL_CONNECT_FAILED:

      Serial.print("[WiFi] Failed - WiFi not connected! Reason: ");

      return;

      break;

    case WL_CONNECTION_LOST:

      Serial.println("[WiFi] Connection was lost");

      break;

    case WL_SCAN_COMPLETED:

      Serial.println("[WiFi] Scan is completed");

      break;

    case WL_DISCONNECTED:

      Serial.println("[WiFi] WiFi is disconnected");

      break;

    case WL_CONNECTED:

      Serial.println("[WiFi] WiFi is connected!");

      Serial.print("[WiFi] IP address: ");

      Serial.println(WiFi.localIP());

      digitalWrite(LED, HIGH);

      return;

      break;

    default:

      Serial.print("[WiFi] WiFi Status: ");

      Serial.println(WiFi.status());

      break;

    }

    delay(tryDelay);


    if (numberOfTries <= 0) {

      Serial.print("[WiFi] Failed to connect to WiFi!");

      // Use disconnect function to force stop trying to connect

      WiFi.disconnect();

      digitalWrite(LED, LOW);

      return;

    } else {

      numberOfTries--;

    }

  }

}


void loop() {

  // Read the button state

  btnState = digitalRead(btnGPIO);


  if (btnState == LOW) {

    // Disconnect from WiFi

    Serial.println("[WiFi] Disconnecting from WiFi!");

    // This function will disconnect and turn off the WiFi (NVS WiFi data is

    // kept)

    if (WiFi.disconnect(true, false)) {

      Serial.println("[WiFi] Disconnected from WiFi!");

    }

    delay(1000);

  }

}

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 :

 

ets Jun  8 2016 00:22:57

 
rst:0x1 (POWERON_RESET),boot:0x13 (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:1
load:0x3fff0030,len:1448
load:0x40078000,len:14844
ho 0 tail 12 room 4
load:0x40080400,len:4
load:0x40080404,len:3356
entry 0x4008059c

 
[WiFi] Connecting to BKSI_2GHz
[WiFi] WiFi is disconnected
[WiFi] WiFi Status: 0
[WiFi] WiFi is connected!
[WiFi] IP address: 192.168.4.202
[WiFi] WiFi Status: 0
[WiFi] WiFi is connected!
[WiFi] IP address: 192.168.4.202

 

IDE:  
 

Version: 2.3.2
Date: 2024-02-20T10:04:35.814Z
CLI Version: 0.35.3

Copyright © 2024 Arduino SA

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:
 

[WiFi] Connecting to BKSI_2GHz
ets Jun  8 2016 00:22:57

 
rst:0xc (SW_CPU_RESET),boot:0x13 (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:1
load:0x3fff0030,len:1288
load:0x40078000,len:13872
load:0x40080400,len:4
ho 8 tail 4 room 4
load:0x40080404,len:3048
entry 0x40080590

 
[WiFi] Connecting to BKSI_2GHz
ets Jun  8 2016 00:22:57

 
rst:0xc (SW_CPU_RESET),boot:0x13 (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:1
load:0x3fff0030,len:1288
load:0x40078000,len:13872
load:0x40080400,len:4
ho 8 tail 4 room 4
load:0x40080404,len:3048
entry 0x40080590

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

Szerkesztve: 2024. 05. 25., szo – 13:13

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

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

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.

Szerkesztve: 2024. 05. 25., szo – 19:15

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

Így le tudom kérdezni a RESET okát. De még nem találtam meg a kapcsolatot a WiFi-s dologgal... 

char resettxtVerbose[80];

const char *resettxtverbose[] PROGMEM = {
    "Ismeretlen ok miatt újraindítás",
    "POWER ON.",
    "Külső újraindítás",
    "Szoftveres újraindítás",
    "Rendszer összeomlása vagy kivétel. (PANIC)",
    "Watchdog újraindítás.",
    "freeRTOS WD újraindítás.",
    "Egyéb watchdog újraindítás.",
    "Mélyalvó állapotból történő újraindítás.",
    "Brownout újraindítás (szoftver vagy hardver)",
    "SDIO okozta újraindítás",
    "USB-perifériával újraindítás",
    "JTAG újraindítás"};
...
esp_reset_reason_t reset_reason;
...
reset_reason = esp_reset_reason();
...
// akár: (sz -- időpont) így is
    snprintf(resettxtVerbose, sizeof(resettxtVerbose), "(%s - %s)", sz.c_str(), resettxtverbose[reset_reason]);

 

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

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...

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.

A FET-es eszköz megy régóta panasz nélkül.

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.

lehet ilyen, hogy részleges boot?

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.

Itt az lehet, hogy egy ellenállást teszek oda?

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

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

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

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

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.

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)