Stabilita ESP8266

[redustin]

Samozřejmě záleží na situaci, ale obecně mi několik dní úplně nepřijde jako naprosto dokonalá stabilita.

[Reklama]

[hazardrok]

No když tak čtu na co všechno se zde ESP8266 používá tak to možná není moc stabilní. Pokud se to používá jen jako modem a všechna ostatní chytristika je jinde, tak občasný restart nevadí, protože spojení se obnoví do pěti sekund od resetu. To nikdo ani nepozná.

[mhi]

Někdy se to samo zmátoří, ale dost často ne.

To mi prijde jako dost zasadni defekt, pokud nedokaze uz znovu navazat komunikaci, to bych oznacil za kardinalni bug. O to mi ale uplne neslo, myslel jsem skutecne pad SW uvnitr.

Muj celkovy dojem z ESP je ze to je echt cinsky produkt. Ono to nejak funguje, nejak to i splnuje parametry (obcas tedy clovek zjisti ze v DS pisou ze to ma PWM, ale pak se zjisti, ze to je vlastne SW fake), zadokumentovane to moc neni, moc se nejde spolehnout na kontinuitu (predchozi IDF nekompatibilni s novymi), ale je to LACINE.

Budu se muset omluvit firme ST, ze jsem nadaval na jejich dokumentaci :-).

[hazardrok]

V navázání komunikace to není, ta je bez problémů. Třeba problém na kterej jsem nikdy nepřišel když je ESPčko připojené k TCP serveru a to spojení někde na cestě zanikne. Toto není v TCP nijak ošetřeno nebo nevím jak. ESPčko si stále myslí, že je spojení aktivní a čeká na příchozí data, protože z pohledu aplikační vstvy je v komunikaci slave. Těch se už nikdy nedočká. Toto je pro mě situace ze které se ten client jednoduše nedostane. Toto je samozřejmě řešitelné. Hůř řešitelná situace je, když espčko samo náhodně spadne. Z mých zkušeností to je v 99% způsobeno při mechanizmu přidělování dynamické paměti, který zkolabuje. Toto je samozřejmě také řešitelné, ale už je to v celku náhodný proces, který se nedá jednoduše ladit. Jedině zkoušením.

[Ovrscout]

V navázání komunikace to není, ta je bez problémů. Třeba problém na kterej jsem nikdy nepřišel když je ESPčko připojené k TCP serveru a to spojení někde na cestě zanikne. Toto není v TCP nijak ošetřeno nebo nevím jak. ESPčko si stále myslí, že je spojení aktivní a čeká na příchozí data, protože z pohledu aplikační vstvy je v komunikaci slave. Těch se už nikdy nedočká. Toto je pro mě situace ze které se ten client jednoduše nedostane. Toto je samozřejmě řešitelné. Hůř řešitelná situace je, když espčko samo náhodně spadne. Z mých zkušeností to je v 99% způsobeno při mechanizmu přidělování dynamické paměti, který zkolabuje. Toto je samozřejmě také řešitelné, ale už je to v celku náhodný proces, který se nedá jednoduše ladit. Jedině zkoušením.

S ESP nemám zkušenost tak nevím jestli podporuje.
Ale obecně, pokud nemůžete nebo nechcete zasahovat do komunikace(přidat si tam nějaké "pingy" každých x vteřin/minut), tak může být řešením povolit na tcp spojení(respektive socketu) tzv TCP keepalive, který to dělá na pozadí komunikace, ale je třeba si pohlídat že to druhá strana podporuje, a upravit časy - defaultní jsou většinou dost dlouhé ale trošku to také zatěžuje linku, tak to zas moc nepřehánět.
Na malých "procesorech"je taky třeba fávat pozor na stav TIME_WAIT pokud ukončujete na straně zařízení.

[Reklama]

[Josef Pavlik]

S esp32 jsme delali rizeni nekterych systemu na demonstracnim aute. Bylo jich tam radove 10, nektere ovladaly svetylka, nektere otviraly dvere. Prusvih byl v tom, ze se naprosto nahodne zasekl radic CAN busu. Softwarove se z toho nedalo dostat. Nektere stavy se daly vyresit resetem pres watchdog, nektere stavy se nedaly vyresit ani takto. Nastesti se podarilo prijit na to, ze ten radic zdechne po prijeti nekolika spatnych packetu po sobe a podarilo se upravit program tak, aby se to do tohoto stavu nedostalo (resetnutim citace spatnych packetu jeste nez dosahl maximalni hodnoty).
Proste bug v hardware. Dokumentace mizerna = pravdepodobne vedeli, ze ta periferie nefunguje dobre, tak to radsi ani nezdokumentovali, prestoze v seznamu periferii byl. To byl zazitek. Tri dny jsem kvuli tomu nespal. Ne, ze bych nemohl spat, ale nebyl cas. Auto uz bylo v autosalonu a ja jsem se v tom po zaviracce hrabal az do doby, nez rano zase otevreli. Naopak behem doby, co byla vystava otevrena, jsem musel byt pripraveny v kteremkoliv okamziku pribehnout a resetnout cele auto, kdyby se zase nektery controller zablokoval a nesly treba otevrit dvere.
Uvahy o tom, ze "me to bezi i nekolik dni v kuse" jsou z pohledu serioznich aplikaci naprosto smesne. Takove zarizeni musi bezet stovky dni v kuse, pokud je to potreba. V nasem pripade to bylo jenom demo, tam slo o rychlost vyvoje. V pripade zarizeni ktere by melo jit treba jenom do prototypu, by takove reseni nebylo akceptovatelne.

[Mirek Prýmek]

ten radic zdechne po prijeti nekolika spatnych packetu po sobe a podarilo se upravit program tak, aby se to do tohoto stavu nedostalo (resetnutim citace spatnych packetu jeste nez dosahl maximalni hodnoty).
Proste bug v hardware. Dokumentace mizerna = pravdepodobne vedeli, ze ta periferie nefunguje dobre, tak to radsi ani nezdokumentovali, prestoze v seznamu periferii byl.

Můžeš se o tom víc rozepsat? S CAN na ESP32 dělám hodně (amatérsky) a na tohle jsem nenarazil. Chybové stavy a jejich čítače jsou zdokumentované imho docela dobře a zatím jsem se nesetkal s tím, že by nedělaly přesně to, co je tam napsáno.

https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/can.html#driver-states

Ani se mi nikdy nepodařilo dostat ESP32 do záseku, který by nešel řešit přinejhorším resetem sběrnice/driveru. Mám tady na zkoušku ESPčko, které jede nějaký cca dva měsíce kolem 50 zpráv za sekundu a žádnej problém tohodle typu jsem nezaznamenal (tím neříkám, že neexistuje, jenom by mě fakt zajímaly podronosti - jestli se dá třeba nějak vyvolat, jestli je k tomu někde nějaký potvrzený bugreport apod.)

Uvahy o tom, ze "me to bezi i nekolik dni v kuse" jsou z pohledu serioznich aplikaci naprosto smesne. Takove zarizeni musi bezet stovky dni v kuse, pokud je to potreba. V nasem pripade to bylo jenom demo, tam slo o rychlost vyvoje. V pripade zarizeni ktere by melo jit treba jenom do prototypu, by takove reseni nebylo akceptovatelne.

To je otázka definice pojmů "seriozní aplikace" a "takové zařízení", že Nikdo by asi fakt neměl na ESPčku stavět sondu na Mars. A nikoho by to ani nenapadlo. Ty ale špatně interpretuješ to, co tady zaznělo. Zaznělo tady, že místní lidi nemají zkušenost s delším uptimem. A zazněly jasně důvody, proč delších uptimů nedosahují. A ty důvody jsou jiné než poruchovost ESPčka. Čili polopaticky: nezazněl důkaz, že to nejde, jenom nezaznělo osobní svědectví, že to jde.

[PanVP]

Proste bug v hardware

Tak bohužel bugy nejsou jen v ESP, ale i v dalším HW.
A teď to neberte, že útočím na vás, nebo že chci strkat za ESP ruku do ohně!
Fakt je, že lidé často řeší nějaký problém, ale nedají o něm vědět výrobci.
Případně to napíšou do nějakého tiketu a tupec na 1st supportu to shodí ze stolu, protože si myslí, že jedná s někým na své úrovni, tj. taky s blbcem, což je v 99% případů pravda.

Lidi, když už objevíte takovou chybu, musíte se postarat, aby se o ní výrobce skutečně dozvěděl!
Bohužel, jsme lidé, snad většina lidí na pozicích "přijímač tiketů" má podobnou inteligenci jako Cortana nebo Alexa.
Říct, výrobce si to má ošetřit, no to by měl, ale 99% tiketů se týká hovadin, kdy lidé prostě neví, jak se co dělá správně, takže pro jednání s blbci jsou jiní blbci naprosto ideální. V podobných případech je potřeba získat kontakt na vedoucího servisu a problém poslat jemu. Často má hovno co na práci, tak to jednak udělá pořádně a dost možná to je člověk, který má o pár mozkových buněk víc, než ti jeho vořežpruti, kteří ale jinak odvádí skvělou práci při jednání s blbci. Přes vedoucího se takový reálný problém spíš dostane ke kompetentním lidem.

Zkuste na to myslet.

[Mirek Prýmek]

V navázání komunikace to není, ta je bez problémů. Třeba problém na kterej jsem nikdy nepřišel když je ESPčko připojené k TCP serveru a to spojení někde na cestě zanikne. Toto není v TCP nijak ošetřeno nebo nevím jak. ESPčko si stále myslí, že je spojení aktivní a čeká na příchozí data, protože z pohledu aplikační vstvy je v komunikaci slave. Těch se už nikdy nedočká. Toto je pro mě situace ze které se ten client jednoduše nedostane.

Je to ošetřeno pomocí TCP keepalive. A to, co popisuješ, je normální chování, je to tak i na Linuxu (IIRC): https://stackoverflow.com/questions/25502859/linux-doesnt-detect-dead-tcp-connections/25503821

Zároveň ale není moc důvod k tomu "situace ze které se ten client jednoduše nedostane". Ten program umí jenom jednoho klienta? Nebo se to stává tak často, že počet mrtvých spojení nabobtná a něco někde přeteče?

[mhi]

Můžeš se o tom víc rozepsat? S CAN na ESP32 dělám hodně (amatérsky) a na tohle jsem nenarazil. Chybové stavy a jejich čítače jsou zdokumentované imho docela dobře a zatím jsem se nesetkal s tím, že by nedělaly přesně to, co je tam napsáno.

https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/can.html#driver-states

To neni dokumentace toho CAN controlleru, ale uz driveru. Taky by mne zajimala, nekde jsem cetl, ze je SJA1000 kompatibilni (ze by vzali neco z opencores? ).

Jak tu nekdo pisete, mel jsem u Microchipu problem, taky s CAN-BUS controllerem, a taky s tim, ze se dostal do stavu kdy s nim uz nic neslo delat. Bylo to 2x nahlaseno, podruhe jsem jim udelal dokonce demo ktere vedlo k zaseknuti, sice potvrdili chovani i u sebe, ale nic nevyresili, ani do errata se to myslim nedostalo (reseni: pouzit externi CAN controller ktery sel resetovat). Dale jsem resil problem s JTAGem, mesice klid a na 24.12. mi volal nejaky sileny Ind, ze to se mnou moc chce ihned resit. Nedokazal jsem mu ani vysvetlit kde je problem, vzdy se to dostalo do roviny "no tak nam to prece funguje".

[Mirek Prýmek]

To neni dokumentace toho CAN controlleru, ale uz driveru.

Jasně, samotná HW dokumentace není moc ideální. Ale nic jinýho než IDF stejně používat nebudeš, takže primárně tě stejně zajímá, jak se chová IDF. A to se podle mé zkušenosti chová tak, jak je to tam popsáno.

Jinak když už jsme u toho, IDF považuju za opravdu dobře udělanej a hlavně user friendly framework. Když to porovnám třeba s STM32 LL nebo tím šíleným cirkusem, co generuje Cube*, tak je to ráj na zemi. A dokumentace je imho slušná, zdrojáky čitelný. Bugy jsou, ale kde ne?

* O IDE ani nemluvě, o tom se nebudu zmiňovat, ať se mi nezvedne tlak na dvojnásobek. Jo, chápu, že pro profesionály, kteří s tím dělají celej život, je to možná docela fajn, ale pro amatéra nebo poloprofesionála, co to vidí poprvé, je to prostě WTF jako prase.

[mhi]

STM32 programuju v gcc/CMSIS, jako ide pouzivam vi. Dokumentace neni rozhodne idealni, ale k vysledku se obvykle nejak doberu. Vlastne u vsech MCU/SoC ktere jsem kdy pouzival jsem sel spis cestou vlastniho kodu, nez pouzivat nejake knihovny ci "framework" a i u takoveho MediaTeku jsem se vrtal primo v registrech.

ESP32 je podle meho nazoru o nekolik urovni horsi, viz jen ten problem jak tvrdi ze maji PWMku a pritom maji jen timery. Nebo ten CAN-BUS. Proste dokumentace je OTRESNA. IDFko je fajn na hobby projekty, ale jakmile by se to melo pretavit do neceho komercniho, je potreba opet sahnout o uroven niz.

Zaujal mne support Espressifu, na 2 dotazy mi vzdy odpovedeli e-mailem kde kladli dalsi otazky - ale ne technicke, pokazde "proc to potrebujete zrovna takhle" / "jaka je Vase aplikace" atd ?

[Mirek Prýmek]

viz jen ten problem jak tvrdi ze maji PWMku a pritom maji jen timery.

To je fakt divný, uznávám.

Nebo ten CAN-BUS. Proste dokumentace je OTRESNA.

Hele, já si myslím, že na to, že je to čínská firma, a vzhledem k tomu, kolik to stojí, je to úplně v pohodě.

IDFko je fajn na hobby projekty, ale jakmile by se to melo pretavit do neceho komercniho, je potreba opet sahnout o uroven niz.

To bysme se asi museli bavit o konkrétním důvodu, proč IDFko obcházet. Já jsem zatím na nic, kde bych to potřeboval, nenarazil.

Zaujal mne support Espressifu, na 2 dotazy mi vzdy odpovedeli e-mailem kde kladli dalsi otazky - ale ne technicke, pokazde "proc to potrebujete zrovna takhle" / "jaka je Vase aplikace" atd ?

To mi přijde spíš pozitivní, že je zajímá, jak uživatelé jejich produkt používají

[Josef Pavlik]

Můžeš se o tom víc rozepsat? S CAN na ESP32 dělám hodně (amatérsky) a na tohle jsem nenarazil. Chybové stavy a jejich čítače jsou zdokumentované imho docela dobře a zatím jsem se nesetkal s tím, že by nedělaly přesně to, co je tam napsáno.

https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/can.html#driver-states

To neni dokumentace toho CAN controlleru, ale uz driveru. Taky by mne zajimala, nekde jsem cetl, ze je SJA1000 kompatibilni (ze by vzali neco z opencores? ).

V te dobe dokumentace nebyla zadna, zda se, ze espressif tajil, ze tam tato periferie je, protoze asi prisli na to, ze nefunguje dobre. Nedokazu ti rict, jestli je to kompatibilni zrovna se SJA1000, ovsem s necim to kompatibilni bylo a psali jsme to podle toho kompatibilniho device.
Je hodne pravdepodobne, ze dnesni verze ESP32 uz tento bug nemaji.

Ale ten projekt byl rozhodne zajimavy. Vubec nelituju, ze jsem kvuli tomu za 4 dny naspal asi 5 hodin. Napriklad tady si predni dvere se zadnimi musely po CAN predavat info o tom, v jakem stavu jsou a jestli se nesrazi.  https://youtu.be/yBw8ziAmlFE Prvni den autosalonu jeste nefungovalo vnitrni tlacitko na otevreni dveri, pri slavnostnim predstavovani museli dvere otvirat dalkove, aby ridic mohl vystoupit :-) Ja jsem se mezitim potil mezi obecenstvem, jestli se otevrou nebo jestli se CAN mezitim zblazni a nic nebude fungovat.

[mhi]

SJA1000 compat jsem videl nekde v dokumentaci. Realne to ale zda se nejak chodi, data se neztraci, neseka se to, ale pravda zadne mezni stavy jsem jeste nevyzkousel.

Co to bylo zac ten concept ? Vypada to docela zajimave (chapu, ze ESP32 na demo staci, nicmene desim se okamziku kdy to nekdo skutecne realne pouzije v necem critical ... )