Arduino Mega Ethernet ledobja a láncot

Miniszámítógépek, SBC-k

Van Arduinora egy saját smart home kódom, ami több eszközön megy. Jelenleg 8db arduino nano, és egy arduino mega.

Lényegében ugyanaz a kód, amik vannak különbségek az eszközökön beállításban, más ethernet miatt vagy 1-2 eltérő szenzor miatt, azok fordítási feltételekkel vannak lekezelve. A nanok UIPEthernet.h-val, a mega Ethernet.h-val megy.

A nanok betonstabilan mennek. A megán viszont időnként lerohad a webszerver.... Igen, csak az, mert pingelni lehet ilyenkor is. Hogy milyen időnként? Van hogy pár nap után, van hogy 1 hónapig is megy... Cseréltem kompletten megát+ethernetet másikra 2x is, nem volt változás.

Régi probléma, a használt libraryk frissültek már többször is, feltettem rá újra a programot, nincs változás.

A kódot többször átnéztem, hibát nem látok, a releváns részen próbálgattam pl több féle módon azt, hogy a kapcsolatot hogy zárom le... Mekkora a buffer... Már nem is tudom, elég sok mindent.

Csak tök fura, hogy a nanon megy hibátlanul, a mega meg szarakodik (egyébként az egyetlen dolog, amit ott mega van, az a digitális kimeneti lábak száma; sem teljesítmény, sem semmi más nem indokolja)

Tudom, így kód nélkül nehéz... De mit tudtok tanácsolni? Debug ötlet? Mit nézzek, mit próbáljak? Valaki esetleg találkozott már hasonlóval? Azért szar ez, mert ugye van hogy hetekig megy....

  • 876 megtekintés

( locsemege v | 2025. 07. 02., sze – 21:38 )

Azt mondod, kész libre támaszkodsz. Abban meg bármi lehet, amit nem saját magad írtál.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

De, egy része igen. Mondjuk amelyik a server, még úgy ahogy. De maga a tényleges hardver kezelés, írás-olvasás memóriába, regiszterbe, hogy miért oda, miért azt a hexa értéket stb, ezt így a chip mély ismerete nélkül halvány fingom sincs hogy jó vagy nem...

"Sose a gép a hülye."

Nincs róla katalóguslap?

Itt inkább az az aggasztó, hogy ritkán jön elő a hiba. Ez tipikusan rosszul kezelt race condition, ami ránézésre nem látszik. Mondjuk egy rövid kódrészbe becsapó megszakítás. Vagy valami nem volatile, aminek annak kellene lennie. Vagy nem atomikus. Mondjuk 16 bites architektúrán 32 bites művelet.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( kisbetu v | 2025. 07. 02., sze – 21:47 )

"mert pingelni lehet ilyenkor is"

Ha Wiznet chip van a modulodon, az magától válaszol a pingre, ha fel van húzva. Külön regiszterbittel kell tiltani, hogy ne válaszoljon.

"Normális ember már nem kommentel sehol." (c) Poli

Hmm, szóval tegnap mikor megállt megint, nem indítottam újra (elfelejtettem).

Most meg nézem, és... magához tért és megy tovább. :)

https://i.imgur.com/K1KPn0Y.png

Szóval lehet hogy mégsem zárja le mindig a kapcsolatokat, vagy valami bug van, és míg valami timeout ki nem fut, addig nincs új kapcsolat.

"Sose a gép a hülye."

Nem lehet, hogy valami koztes eszkoz vagja fejbe a sessiont? Nekunk volt anno olyan, hogy a kabelmodem 5 perc idle utan dobta a sajat session/upnp tablajabol a kapcsolatot, ami miatt az SSH-k es egyeb kapcsolatok is "szakadoztak". Mivel ez a routernek egy security feature-je volt, ezert nem lehetett felulirni, maradt az ssh keepalive 2 percre allitasa...

( locsemege v | 2025. 07. 02., sze – 22:01 )

Azok a libek forrásban vannak meg, s fordítod a projecthez, vagy binárisok, s csak linkelni kell? Mert ha forrás, akkor írhatsz logolást is gyanús helyekre, persze figyelve arra, hogy ne több kilobyte log keletkezzen másodpercenként.

Én műszer firmware-éhez nagyon szép logokat csináltam µs felbontással. Elképesztően sokat segít. Akár abban, hogy azt hiszem, minden a legnagyobb rendben, aztán a logból látom, hogy valami baj van, amivel foglalkoznom kell, érzékelhető tünete nem is volt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( renard | 2025. 07. 02., sze – 22:06 )

Cseréltem kompletten megát+ethernetet másikra 2x is, nem volt változás

ENC28J60-at is próbáltál a megával? Érdemes lenne, ha a nagyobb kód nem probléma. 

Miért lenne nagyobb a kód?

Azért nagyobb a kódja, mert ez kicsit "butább" chip, mint a másik, pl. ott van hardveres TCP/IP stack, itt meg nincs.

 

Egyébként meg pont a megába hogy a viharba ne férne el, ha a nanon elfér

Azt nem tudhatom, hogy a megában miket futtatsz, ahhoz mekkora méretű kódot írtál. :) 

Ugyanaz a kód, mint a nanon.

Konstansokat írok át, és fordítási paraméterekkel van összerakva, hogy mit buildeljen. Így lesz a megán Ethernet.h, a nanokon UIPEthernet.h, így lesz más a MAC és IP címük, a nevük, a kimeneti/bemeneti lábak paraméterei. A nanokon van egy AM2320 sensor, a megán ez nincs, helyette van DS18B20 (később került rá, a mega már előtte is fagyott), valamint az ehhez kapcsolódó lekérdezések. Ennyi.

"Sose a gép a hülye."

Ugyanaz a kód, mint a nanon.

vs

Konstansokat írok át, és fordítási paraméterekkel van összerakva, hogy mit buildeljen

Tehát nem ugyanaz a kód kerül bele az egyes mikrokontrollerekbe. :)

Ha Ethernet vezérlőt cserélnél a mega és egy nano között, kiderülhetne, melyik kódrészlet okozhatja a hibát. Ha átmegy a hiba a megáról a nanora, akkor az Ethernet.h a bűnös, ha nem, akkor az jó, máshol kell a hibát keresni a megára forduló kódban.

A linken vettem. Egy legótvarabb kínai fos, de a tantálkondi javított a helyzeten. Nem táphiba volt, 5V 2A jó minőségű kábeles USB tápról kapta a szuflát. Ez szerintem processzorfüggő hiba. Csak ötlet volt, nekem ez megoldotta a hibát. Tranziensek, emp, faszomtudja mi. Nem is érdekel, most jó.

https://www.esp8266.org/

Nekem mégis úgy tűnik, hogy a tápot rángatta meg a relé. A soros dióda jó megoldás, de én tettem volna utána egy nagyobb elkót, hogy előtte ne piszkáljon bele a tápba a relé. A tekercsről meg levenném a kondit, az lassabb, gyengébb meghúzást okoz.

A tápok kábelezése kritikus tud lenni, a GND-ket meg a + tápfeszt is egy-egy erős csillagpontból célszerű vinni, nem felfűzve megoldani. Én az erek vastagságával sem szoktam spórolni, a tápot is jól kell megválasztani, ezek a  kínai csodák sokszor a felét is alig tudják annak, ami rájuk van írva, de ez - gondolom - köztudott.

Megoldás lehet még az elektromágneses zavarok ellen az árnyékolás. Ha nem nehéz kivitelezni, akkor érdemes megcsinálni.

Nekem mégis úgy tűnik, hogy a tápot rángatta meg a relé.

Kizárt, mivel előtte a tekercsen folyó áram nulla, azaz épp soft módon alakul ki az áram. Pont a párhuzamos tantál kondi lesz az, ami iszonyat mód meg fogja cibálni a tápot bekapcsoláskor.

Simán gondolnék arra, hogy a kapcsolt körről, a kontaktusokról származik az a zavar, amitől az MCU megdöglik. De lehet úgy táplálni MCU-t, hogy kellő mennyiségű hidegítő kerámia kondi, sorosan meg kb. 560 nH induktivitás. Én így csináltam, s amikor EMC/EMI laborban megkínálják a gép házát 8 kV-os feszültség tüskékkel, vígan megy tovább, nem fagy szét. 

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem is érdekel, most jó.

Aztán így keletkeznek a tévesznék. Fekete kakast áldoztunk teliholdkor éjfélkor, az uram majdnem elpatkolt, de ettől meggyógyult, bivalyerős mára, naponta megdug, minden rendben Marikám, szóval neked is azt ajánlom, szerezz egy fekete kakast és várd a teliholdat...

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez viszont jó ötlet, hiszen az u(t) = L * di(t) / dt összefüggés alapján - a képlet másik tagja hiányzik, mert feltételeztem, hogy az L induktivitás időben nem változik - az áram nem változhat meg ugrásszerűen azon okból, hogy realitása csak véges feszültségnek van, tehát kikapcsoláskor az áram tovább fog folyni. Legegyszerűbb, ha körbe járatjuk, s az 1 / 2 * L * i ^ 2 energiát a diódán illetve a tekercs ellenállásán hővé alakítjuk.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Volt hogy csak a használt GPIO láb fagyott ki, volt hogy az egész proci. Garantáltan jó USB kábellel, táppal egy WeMos D1 mini csinálta ezt a hibát, a modul lábaira (G, 5V, GPIO) direktbe kötöttem a relé modult. Volt benne visszdióda. Érdekes, 3.3V lábon nem fagyott, de nem mindig húzott be (értelemszerűen). Én se értettem.

https://www.esp8266.org/

( Nyosigomboc v | 2025. 07. 03., cs – 05:57 )

Esetleg ha a Nano (ATMEGA328P) atomstabil, es csak a digitalis outputok hianyoznak, nem lenne jo megoldas a Megat masra hasznalni, es lecserelni egy ujabb Nano-ra + egy marek 595-re? 3 labbal (extrem esetben 2-vel) IC-nkent 8 bit kimenetet kapsz, es lancolhato, szoval ha 4 darabot teszel moge, 32 kimenetet kapsz 3-ert. Kezelni is nagyon konnyu, vagy rateszed az SPI-ra, es csak 1 engedelyezes kell (bar ez bezavarhatja a halozatodat, ha az is azt hasznal), vagy az egyszerubb eset a shiftOut fuggveny. Az 595-ost meg kb. gombokert utanaddobjak. A vegen a kutyu lehet, hogy meg kisebb is lesz - amilyen batar a Mega.

A strange game. The only winning move is not to play. How about a nice game of chess?

Nem porog vegig. 1 adat lab, 1 orajel, es egy, ami a shift regiszterbol attolti a belso latch-be. Ha azonos adat marad, semmi nem tortenik. Ha az utobbit elhagyod, akkor persze vegigporog, de megy 2 labbal is (nem ajanlom ezt a modot, csak ha muszaj).

Azt persze megertem, es elfogadom, ha nem akarsz sajat kutyut. Vannak amugy I2C alapu IO extenderek is, szokasos "arduino modul" formaban. Az meg egy lehetoseg.

A strange game. The only winning move is not to play. How about a nice game of chess?

( b10up | 2025. 07. 03., cs – 17:26 )

Eredeti a mega? Ismerősömnek sikerült egyszer bevásárolnia hamisítottból, és 3-50 óránként újraindult vagy megfagyott. Hetekig szívtunk vele, hogy az én vasaimon jó, és ugyanaz a kód az ő cuccaival lefagyogat. 

Ezen kívül a w5100-aknak javaslom, hogy a reset lábát vágd ki és kösd be egy szabad IO-ra, és ha nincs rajta forgalom, akkor szoftveresen reseteld ki alóla és begineld újra 2 másodperccel később. Rengeteg (70+) ilyen shielddel üzemeltetünk arduinokat, és hosszútávon nem megbízhatóak, ahol lehet, ott inkább w5500-as shieldeket használunk, azok lényegesen stabilabban működnek. Vagy pedig ezt a gusztustalan workaroundot. 
A másik, hogy ha alsó polcos w5100 shieldet veszel, lespórolják róla a reset chipet (4 lábú kis IC az egyik sarkán a panelnek), ezért vagy elindul amikor áramot kap, vagy nem. A fenti ezt is megoldja.

Még valami!

A W5100 shieldeknek van egy "gyári" hibája: az ethernet lezáró 50 ohmos ellenállások helyett 510 ohmot ültettek be (létra felirata 511). Ez pont elég ahhoz, hogy a link bizonytalan legyen.

 

https://www.google.com/search?client=opera&hs=4mg&sca_esv=c799b5a334c4a…

"Normális ember már nem kommentel sehol." (c) Poli

Ez a hiba nem az lesz, mert ping van.

De egyébként: Pff... Szerintem legalább 5 krimpeltem újra a kábelt anno, meg cseréltem is, mert nem jött fel a link sokszor.... És olyan is volt hogy emiatt cseréltem ethernet shieldet. Remek.

"Sose a gép a hülye."

A Ethernethez használt kábelek (Cat 5e, Cat 6 stb.) hullámimpedanciája 100 ohm, ehhez kell illeszkednie az Ethernet kártyának/adapternek. Általában 2 db 50 ohm körüli ellenállást kötnek sorba, a közös pontjukat pedig egy ellenálláson vagy kondenzátoron vagy párhuzamos RC-tagon keresztül lekötik GND-re. Ha 50 ohm helyett 500 ohm körüli értékeket használnak, az azt jelenti, hogy kvázi lezáratlanok, illesztetlenek lesz az érpárak, ami reflexiót és jeltorzulást fog okozni, aminek működésbeli problémák lesznek a következményei, TCP/IP-n csomagvesztések fognak jelentkezni. TCP esetén még orvosolható a dolog, de UDP-n nem (pl. ezért lehet olyan, hogy a shield nehezen, sokadik kérésre kap IP-t a DHCP-kiszolgálótól, esetleg nem is kap) . Elég nagy szívás, ha így kerülnek ki a gyártótól shieldek, nem mindenki van arra felkészülve, hogy orvosolja a problémát, ami amúgy nem olyan nagy feladat, de szerszám és gyakorlat nélkül nem fog menni.

( asch v | 2025. 07. 05., szo – 14:56 )

Nálam tapasztaltabbtól azt hallottam, hogy minden firmware-rel rendelkező dolgot úgy kell beépíteni, hogy hard resetet tudjon adni neki az áramkörünk. Ezekben szoftver is van, és néha még a soft reset sem elég nekik, hogy újra működő állapotba jöjjenek.

A rituális öngyilkosság lehet tervezett, amikor egy hardware-es állapotautomata végig tudja vinni ezt akkor, amikor már elkezdődik a reset. Ugyanakkor szerintem ő arra gondolhatott, hogy vannak önálló, intelligens perifériáid, s legyen arra lehetőség, hogy a rendszer működésének egészét irányító, tehát a fő processzor tudja ezeket a kis perifériákat hardware-esen is reset-elni.

Alapvetően jó ötletnek tartom, bár manapság felesleges, amennyiben jól csinálták meg az adott perifériát, nem egy RC-tag a reset áramkörük, hanem egy komoly infrastruktúra, valamint van, és használják a watchdog reset-et.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE