ENC28J60 - Arduino ethernet szívás

 ( airween | 2016. december 3., szombat - 23:45 )

Hello,

adott egy Arduino Nano (ATMega328), és egy ENC28J60-as ethernet vezérlő.
A cuccost alapjaiban sikerült összerakni, mármint van egy működő alap, ami HTTP kérésekre elküld egy minimális HTTP választ. Ezt a libet használom - kb ez a legjobban karbantartott (alig 2-3 éves :)),

Viszont ha a Hello World típusú válasznál kicsit bonyolultabb oldalt szeretnék elküldeni a válaszban, akkor már maga a kapcsolódás sem megy:

              client.write("HTTP/1.0 200 OK\r\n");
              client.write("Content-Type: text/html\r\n\r\n");
              client.write("<!DOCTYPE html>\r\n");
              client.write("<html>\r\n");
              client.write("<meta charset=\"UTF-8\">\r\n");
              client.write("<head>\r\n");
              client.write("<title>ABCDEF IP TESZT1</title>\r\n");
              client.write("<style type=\"text/css\">\r\n");
              client.write("html, body { width: 100%; height: 100%; margin: 0; padding: 0; }\r\n");
              client.write("body { background-color: #A0A0A0; color: #000000; font-family:\r\n");
              client.write(" Arial, Verdan\r\n");

Ha az utolsó sorban a "Verdan" helyett csak "Verda" van, akkor lehet kapcsolódni, és a fenti html-t küldi el a "szerver". Egyébként:
Trying 192.168.72.3...
telnet: Unable to connect to remote host: No route to host

A fenti válasz hossza (ha jól számolom) 320 byte - viszont semmi ilyesmi limitet nem találtam a lib-ben.

Van valakinek ötlete, mi lehet a gond?

Köszi,
a.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

tipp, nem 'verdana' kellene oda? és pontosvesszőt, kapcsos zárójel bezárt is hiányolom

"Van valakinek ötlete, mi lehet a gond?"
hogyne. arduino + ethernet-cullang -> instabil szar, ötletszerű működés/hibaképzés.

--
"a Hungarian Unix Portált [...] szakmai fórumként eszembe nem jut használni, mert a közönség mentalitása miatt nincs értelme.

Igazad van, sokat szívtam vele. Jó LIB-et használsz. Most stabil, kapcsolja a server a lámpáimat (HTTP kérésre 315MHz-es jelet küld, mint egy távirányító), de korábban az alábbi problémák voltak:
- client.write() után néha kell client.flush()
- kell bele néha egy kis várakozás (sleep/delayms)
- néha csak a client.close() után küldi el az adatokat.
- string műveletek (új string is az) bekeverik a belső heap memóriáját. Nekem napi újraindítás kell emiatt az esköznek (amit önmaga csinál meg a PIN2-es és a RESET láb megszakításával).
- konstans stringeket így használd: client.write("XY") helyett client.write(F("XY")), ez a PROGMEM részre rakja a stringet.

2KB SRAM-tól mégis mi a fenét várunk? Egy fullos Ethernet csomag mérete 1514 byte... Előre definiált méretű UDP csomagokra még talán alkalmasak ezek a cuccok, rendes TCP-re nemigen.

Amúgy meg manapság már $10-30 nagyságrendben lehet full Linuxot futtató, 100MB-okban mérhető memóriával ellátott Ethernetes ketyeréket venni, akkor minek ezzel szívni?

Például a fogyasztás miatt?

Mennyit is lehet ezzel spórolni? Fél Wattot? Egyet?

Ennél relevánsabb megjegyzés, hogy egy kis MCU megbízhatóság szempontjából kezelhetőbb, mint egy multiuser Linux, MMU-val, sallangokkal (viszont ha az MCU-t megbolondítom egy ilyen ENC chippel, akkor máris buktam a megbízhatóságot sw oldalról). Ergó ha valami low-level vezérlőt akarnék, akkor lenne benne MCU, meg egy soros vonalon őrá rákötött Linux, ami az Etherneten címezhető végpont lenne.

Abból indulsz ki, hogy folyamatosan megy a node. Ha mondjuk csak percenként ébred a node, mér egy hőmérsékletet (2-3 másodperc), majd visszaalszik, akkor sokkal többet nyerhetsz vele.

Ha megnézed, hogy mennyit fogyaszt egy Raspberry Pi (vagy tetszőleges "100MB-okban mérhető memóriával ellátott Ethernetes ketyere"), akkor alsó hangon 700 mA-el számolhatsz 5V mellett (3.5 watt). Ekkor még nem számoltad az esetleges külső tápegység veszteségét.

Ezzel szemben mondjuk egy Atmega328 + egy W5100 3.3V-on eszik nagyon maximum 150-200mA-t, ami 0.6 watt körül lenne, de ugye 1 órából csak 180 másodpercet tölt ébren, tehát ezt oszthatod 20-al. Ha olyan helyen vagy, ahol mondjuk korlátozott a tápellátás és elemről kell hajtanod a kütyüt, akkor nem mindegy, hogy óránként 3.5 wattot vagy annak kb. az 1%-át használod el.

Egyébként igen, a mikrovezérlőt megbízhatóbbnak tartom, ha normális komponensek vannak mellette. Az ENC28J60 nem feltétlen az. Viszont van itt mellettem egy Arduino Uno + W5100, kb. 4 éve felprogramoztam, azóta nem nyúltam hozzá és még nem áll le.

És igen, tervezem majd lecserélni egy saját boardra, mert mind az Arduino Uno-n, mind a W5100 shielden van elég sok felesleges sallang, amik a fizikai méretet és a fogyasztást is növelik.
A saját NYÁK tervezése főleg az NRF24L01 és az ESP8266 megjelenése miatt maradt még el.

Sub

Ahogy E-medve írta is: megbízhatóság és fogyasztás. Bár maga a fogyasztás az adott helyen nem releváns (legyen mondjuk 10W egy RPi fogyasztása mindennel), de a megbízhatóság fontosabb. Ez az eszköz egyébként arra hivatott, hogy más eszközöket be tudjunk kapcsolni távolról. A teljes áramfelvétele kb 160mA (12V-ról - a relék 12V-osak), így ez nincs 2W. Tényleg nem ez számít, hanem pl az, hogy a mellette levő RPi-ben 1 év alatt 2 SD kártyát cseréltünk már, és a 2. kártyára is 2x kellett már újratelepíteni a Linuxot. A kontrollerekkel ebből a szempontból jobb a tapasztalat.

Az hogy szívok vele - én ezt nem így fogom fel, de biztos ez valami sajátságos fétis :).

Az SD kártya megbízhatóságát szerintem jelentősen lehetne növelni, ha nem tudna a tápellátás elmúlni írás közben. Ergó kell valami megfelelő táplálás a bemenetre - vagy valami akksis cucc, vagy legalább egy marék kondi + a betáp elmúlását előre jelző és így szoftverből shutdownolást elindítani képes valami. De szerintem készen is árulnak RPi-hez ilyeneket, meg lennék lepve, ha ez másnak még nem jutott volna eszébe.

A helyszín, ahol ezek működnek, egy rádióamatőr állomás. Nagyfreki, nagy powerrel. Ettől függetlenül bírják a cuccok a környezetet, de pl nyáron volt egy szép villámcsapás az egyik toronyba, amit az RPi túlélt, az SD kártya is, a rajta levő Linux már nem (és nem a villany ment el...). (Ezen kívül amiben 2m-nél hosszabb UTP/egyéb jelkábel volt dugva, az kampeca.)
Most, hogy írtad a kell valami megfelelő ötletet, mondok még egy okot az MCU mellett: az ára. Ez az egész kijött kb 3-4e Ft-ból, ebben benne van a panel, az egyéb alkatrészek, relék ára (van, ami volt a fiókban :)). Az RPi-t is valaki a tagságból ajánlotta fel, ez így megy, de most egy szünetmentes/akksis táp kicsit drágább lenne.

Nem a Pi 2-nél volt olyan bug, hogy ha megvakuztad közelről, akkor újraindult? :-)

Valóban árulnak a Pi-hez mini UPS-ot, csak kb. a Pi árával egyenértékű.

arduino_uip/utility/uipethernet-conf.h-ban:
- kapcsold ki a IP_CONF_UDP-t (+5kb-od lesz)
- UIP_PERIODIC_TIMER-t vedd le 20-50-re, gyorsabban válaszol. Az Arduino TCP stack-je egy bugyuta valami.

Nekem ab.exe-vel (linux ab (apache csomag)) tesztelve most van egy eszköz, ami folyamatosan válaszol, akár 5-ös párhuzamosságal is. Menni fog valahogy...

Hello,

köszi a tippet - megnézem majd. Egyelőre működik, sikerült összehozni, de baromi kemény órák után.
A bufferkezelés valami borzalmas. Ha egy string (char buffer[BUFFSIZE]) globálisan van deklarálva, az még működik, de ha még egyet szeretnék használni, és mondjuk ilyet csinálni:

char buff1[BUFFSIZE];
char buff2[BUFFSIZE];
...

void loop() {
   ...
   char c;

   ...
      c = client.read();
      buff1[p1++] = c;
      buff2[p2++] = c;

pl már szintén azt eredményezi, hogy nem válaszol az eszköz. Ha a második értékadást kiszedem, azonnal elindul... És ez reprodukálható, egymás után többször... Ha az egyik string a loop()-on belül van deklarálva, akkor meg jó. Néha majdnem sírtam - de ez van, egyelőre így jó lesz. Lenne még mit fejleszteni rajta, majd a bejgli mellet :)

a.

Az ENC28J60 chip egy vicc (ahogy a legtöbb Microchip tervezésű IC). Még a Microchip saját stackjével sem tud normálisan működni, ne várd hogy Arduinoval megbízhatóan fog menni.
Ezt olvasd: http://ww1.microchip.com/downloads/en/DeviceDoc/80349c.pdf

Ennél még viccesebb az ENC424J600/624J600:
Module: AES
At room temperature, the AES module may compute valid results. However, across voltage, temperature, and ordinary part-to-part device variation, the AES engine will compute incorrect results or fail to finish computations.
Work around
Use a software implementation of AES.

És ezeket a chipeket még ma is nagy betűvel AES képesnek hirdetik!

When transmitting random data in 10Base-T
mode, the PHY transmit waveform slightly violates
the MAU eye diagram.
Work around
None

For 100Base-TX operation, the IEEE 802.3 specification
requires the rise and fall times of the MLT3
signal to match within 0.5 ns, measured over
10 different intervals. The actual rise/fall time
symmetry measurements may occasionally be
slightly above this level.
Work around
None.

Az általad írt ENC chip-ek annyira már nem hoznak lázba a 28J60 után :). Azt írták máshol is, hogy jobban járok a W5500-al, Kínából rendelve árban majdnem ugyanott vagyok (ok, kicsivel drágább, de tényleg "aprópénz"), és ezt dícsérték több helyen is.
Mindegy, egyelőre működik (bár volt egy lib, amivel eljutottam részeredményig, otthagytam éjszakára a cuccost, reggel pedig nem volt elérhető, csak reset után). Meglátjuk. Azért köszi az infókat.

Igen, a W5500 nem rossz, de érhet meglepetés: nem támogatja az auto MDI/MDIX-et.

Köszi, ezt megjegyzem :).

A W5100 viszont tud, bár emlékeim szerint picit drágább.

Köszi a tippet - Vaterán találtam hasonló árban, mint a W5500 :)

Én írtam a 424J600-hoz egy SPI-s drivert (ATXmega) néhány éve és egy UDP/ARP/DHCP stacket is. Jó móka volt, és alapvetően működött nekem az említett chip, igaz, AES-t meg sem próbáltam használni, illetve az MCU órajele miatt az átviteli sebesség is elég alacsony volt. Viszont napokig ment stabilan (100Mbps auto negotiation, full duplex).

Nem azt mondom, hogy nincs igazad, csak álljon itt egy olyan vélemény is, hogy lehet azért használni a 424J600-ot uC-es környezetben ;)

Szintén dobtam ezt a kombót korábbi projektjeimnél.
Túlmelegedés, instabil működés, lefagyás, restart minden volt.

Azóta ESP dev board-ot használok oda ahova csak lehet. Egy álom ehhez a kombóhoz képest.

Hátjah', viszont itt az árcédulán a string egy karakterrel hosszabb :).
Még a W5500-at ki akarom próbálni, az még az a kategória, mint az ENC28J60, és arról is jókat olvastam.

Köszi,

a.

Hol lehet ENC28J60-at kapni 20 centert? Annyiert talan megeri szivni vele ha sok kell.

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

Valószínűleg az ESP8266 helyett az ESP32-t nézte. :-)

Ha nem is annyiért, de... én ezt vettem, szoktam venni: https://www.aliexpress.com/item/Mini-ENC28J60-Webserver-module-Ethernet-Shield-board-for-for-Ar-Nano-v3-0/1859123003.html

1400Ft/db, NANO-val jól illeszkedik....

Hogy 20 centért hol lehet venni, azt nem tudom. Az ESP dev board-ra rákerestem, 40EUR volt (amin van ethernet is), ezért írtam a sztring hosszát :).
Amúgy kettesével adta a tag az ebay-en, és így volt 3300 HUF a két ENC28J60, ill szintén két darab Nano volt 1200 HUF kb.
Link

Szerintem amúgy nem éri meg a szívást - mondom azután, hogy több helyen olvastam a W5500-ról, ami nem sokkal drágább:
Link

Őőő... bocs, ezt nem értem: ez egy WiFI modul, én ethernetről írtam végig.

Lesz itt még bluetooth és gsm modul is ha vársz egy kicsit :)

:)

20 cent?? :)

Tessék ingyen, nem is kell eth chip :D
http://hackaday.com/2014/08/29/bit-banging-ethernet-on-an-attiny85/
https://www.youtube.com/watch?v=m4f4OzEyueg

75 cent Ali-n a chip és már a vezérlés is megvan
15 cent kb 20cm-es Cat5 kábeldarab ráforrasztva + nyomsz rá egy dugót + zsugorcsőbe rakod az egészet

Már csak a táplálást kell kitalálni és kész az 1 $-os Ethernet IO.

W5100-at SPI-n még mindig rakhat mellé.

Egyébként ennek a boardnak van egy kisebb kiadása, ha nem kell az összes kivezetés: Wemos D1 Mini.

Van WiFI a helységben, de - itt írtam - ez egy amatőr állomás, ahol elég nagy RF terhelés van. Lehet, hogy semmi nem történne, de ezzel nem nagyon akartunk kísérletezni. Egyébként csak érdekességképp, ott (és csak ott, abban a pár 10m^2 területen) a laptopomon (valami k+1 éves Samsung) nem hajlandóak működni a toucpad gombok, ha megy a végfok.

Mindegy, kaptam pár értékes ötletet a modellekre vonatkozóan, legközelebb igyekszem jobban összeválogatni az egyes komponenseket :).

Üdv!

Használhatsz más mikrokontrollert is UIPEthernet library-val.
Ha fontos a fogyasztás, akkor lehet arduino due, vagy valamilyen STM32.
Egy STM32F103CBT6-os Maple Mini (128K Flash/20K RAM) úgy 1 ropi EBAY-en.
A Due egy kicsit drágább.
Használhatsz ESP8266-ot is, igaz egy kicsit többet zabál.
ENC28j60-al együtt többszáz mA.

Ha kell a javított UIPEthernet library innen letöltheted:
https://github.com/UIPEthernet/UIPEthernet

Javítottam benne bugokat is, meg beleraktam 1-2 MCU támogatást, meg MBED fordító supportot.
Szerintem elég stabil.
Nekem egy 1-wire-es vezérlő cucc HTTP kliensként megy, közben meg syslogra küld adatokat.
Nálam már lassan egy éve ketyeg egy arduino pro mini-n.

A progit már teszteltem maple minin(STM32F103CBT6), ESP8266-on,
de még nem kelett egyéb funkcionalitás, ezért nem izzítottam be mást.

Szóval: Szerintem használhatók a mikrokontrollerek, csak el kell fogadni a korlátaikat.
Meg figyelni kell a programozásnál az erőforrásokra.

Ha úgy használod a client.write-ot, ahogy te:
client.write("szöveg")
akkor a RAM-ba fogja rakni a fordító a teljes szöveget.
Így hamar elfogy a 2K.
Helyette: clinet.write(F("szöveg"))
Így a flashbe kerül a szövég és csak a poinetere adódik át a függvénynek -> 2byte RAM használat.

Glóbális buffereket ne nagyon használj, csak ha tényleg nincs más megoldás.
Azok is a RAM-ot eszik, és tudjuk a 2K nem sok.
Az én progim nem eszik meg 1,5KB-ot, több mint 500 byte-ot hagy a heap-nek(stacknek).

Köszi mindent, a projekt nincs lezárva, szeretnék HTTP AUTH-ot, ehhez a fejléceket fel kell dolgozni, ehhez kellenek a bufferek - ok, valóban nem kell globális láthatóság, de gondoltam ez itt tök mindegy.
Megnézem a javított libet is.

Köszi mégegyszer.

Helló mindenkinek!

Új verzió (1.2.1) érhető el:https://github.com/UIPEthernet/UIPEthernet
Most már használható MBED fordítóval is.
Minden példa működik vele.

Üdv!

Köszi, hamarosan ránézek.