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.