Articolo su Ethernet shield client

ah ecco :slight_smile: mi sebrava un pò strano...

asamlink:
Semplicemente lo scopo e' quello di connettere nella rete la macchina del cliente che puo' essere controllata.

OK capito
Un telecontrollo insomma.
Con l'aggiunta di un dispositivo che esegue dei log quando non si e' connessi

Ho clienti che su alcune macchine datate e dotate solo di seriale usano sistemi di interconnessione su Ethernet per caricarci i file di lavoro e per fare controlli
Pensavo fosse una cosa del genere

brunol949:

asamlink:
Semplicemente lo scopo e' quello di connettere nella rete la macchina del cliente che puo' essere controllata.

OK capito
Un telecontrollo insomma.
Con l'aggiunta di un dispositivo che esegue dei log quando non si e' connessi

Ho clienti che su alcune macchine datate e dotate solo di seriale usano sistemi di interconnessione su Ethernet per caricarci i file di lavoro e per fare controlli
Pensavo fosse una cosa del genere

Si tratta proprio di un telecontrollo, con ormai la parte server (arduino) pressoche' completata! Mi sa che i convertiro' all'enc.

:slight_smile: ma fai prima un pò di test, magari in quell'ambito funziona perfettamente.
Per passare all'altro shield devi stravolgere (e non di poco) il codice originale.

Massi prova, ti confermo l'uptime di otto mesi con la eth ufficiale wiz, senza problemi, con un protocollo e un utenza simili.

Ho appena provato

ping -f 192.168.1.177
PING 192.168.1.177 (192.168.1.177) 56(84) bytes of data.
.
^C--- 192.168.1.177 ping statistics ---
1163664 packets transmitted, 1163663 received, 0% packet loss, time 91197ms
rtt min/avg/max/mdev = 0.055/0.060/4.680/0.009 ms, ipg/ewma 0.078/0.060 ms

con lo schetch d'esempio ChatServer caricato sull'arduino e non ci sono stati problemi, anzi durante la prova mi sono connesso al server chat da due macchine diverse e ha funzionato tutto.
Devo dire che l'ho fatto attraverso uno switch managed decente.

@legacy
ho usato solo la wiz, non mi serviva la SD, e non ho usato nessuna tecnica di reset, lo schetch non è mai stato riavviato.

Alberto

Bo c'è scritto sopra
Wiznet
Ethernet 5100
P8752-010
1042

Inizio ad intuire allora che il problema non sia la wiz da sola ma la wiz che condivide il bus spi con la SD, noto infatti che chi lamenta difetti li lamenta quando utilizza anche la sd e non una volta ogni tanto ma diverse volte

condivido. Qualche volta si ingrippa nella gestione delle porte 4 e 10, probabilmente qualche delay di pochi ms nel posto giusto sulle librerie potrebbe risolvere.

@legacy
Che minchia hai detto qui sopra? :slight_smile:

XD ha scritto che forse funziona uguale sotto pingflood. Magari lo switch gli ha salvato il cuxxo.
Il prossimo test sarebbe quello di vedere come reagisce ai pacchetti che costringono ad una frammentazione eccessiva superando la finestra dell'mtu, magari provare a pingare mandando pacchetti giganteschi o anche che eccedano di poco l'mtu ]:smiley:
...è sempre e solo per curiosità.

pablos:
condivido. Qualche volta si ingrippa nella gestione delle porte 4 e 10, probabilmente qualche delay di pochi ms nel posto giusto sulle librerie potrebbe risolvere.

Io vorrei dare una conferma pratica a questa teoria

Nel mio "coso" fotovoltaico , la pagina html che si vede e' in realta' un collage di piu' file intercalati con i valori
Per cui leggo , invio , invio dato , leggo , invio , invio dato ....... invio chiusura file
Ho dovuto inserire del delay 10 perche' altrimenti ogni tanto si inceppava
Ciao

legacy:
hai usato solo la wiz o hai usato anche la sd card ?
hai usato la tecnica del reset ogni x secondi ?

Ho usato sia Wiz (W5100) che la SD (per il log).
Fino ad ora non ho riscontrato problemi, ma sono ancora in test. La tecnica del reset non l'ho ancora usata per un semplice motivo: se esiste il problema deve essere rivelato. Nello specifico del mio caso, procedo alla sua rivelazione e se riscontro l'anomalia, riprendo i test con il reset.
Comunque in alternativa ho pensato gia' alla soluzione ENC + SD, che forse e' meglio e piu' sicura. Ripeto non ho bisogno di super velocita', tanto il dato e' aggiornato a 9600 su rs485.
Il log per ora funziona scrivendo quando non invia; l'unico punto dove avvengono entrambe le operazioni e' al momento della richiesta di un file di log. Procedura assai rara, e in questo contesto l'arduino e' impegnato solo a fare questa cosa.

Ma Wiznet, dati questi presupposti, non ha ancora sistemato il W5100 o ha prodotto un chip sostitutivo?

Di nuovo grazie.

Scusate un attimo,

Io con il chip W5100 avevo notato un problema di blocco con la eth e mi toccava resettare l'arduino (si piantava proprio, pingava soltanto)
Pero' girando e provando ho visto che con:

pinMode(10, OUTPUT);                       // set the SS pin as an output (necessary!) (53 anziche' 10 per il MEGA)
digitalWrite(10, HIGH);                      // but turn off the W5100 chip!

card.init(SPI_HALF_SPEED, chipSelect)

E da allora le noie non sono piu' tornate. Pero' attualmente il card.init non lo uso.

Devo dire che convertendo tutto da 0022 in 1.0 smanettando un po' con il setup di questo tipo (code qui sotto)

  • togliendo alimentazione e rialimentando parte tutto senza reset
  • al termine dell'upload sketch la ethernet parte senza reset
  • mentre il browser gira a cercare l'ip e alimento arduino si connette

Tre problemi che avevo prima sembrano essere svaniti, sono a dir poco Esterre_fatto!!! :slight_smile:
L'incubo del RESET è finito!!!!

resta da verificare cosa accade nel tempo ........ sperem

#include <SPI.h>
#include <Ethernet.h>
#include <Flash.h>
#include <SD.h>

void setup() 
{
  delay(1000);
  Serial.begin(9600);
  delay(100);
 
  pinMode(SS_PIN, OUTPUT);	// set the SS pin as an output(necessary to keep the board as master and not SPI slave)
  digitalWrite(SS_PIN, HIGH);	// and ensure SS is high
  // Ensure we are in a consistent state after power-up or a reset
  // button These pins are standard for the Arduino w5100 Rev 3
  // ethernet board They may need to be re-jigged for different boards
  pinMode(ETHER_CS, OUTPUT); 	// Set the CS pin as an output
  digitalWrite(ETHER_CS, HIGH); // Turn off the W5100 chip! (wait for configuration)
  pinMode(SD_CS, OUTPUT);       // Set the SDcard CS pin as an output
  digitalWrite(SD_CS, HIGH); 	// Turn off the SD card! (wait for configuration)

  // initialize the SD card.
   card.init(SPI_FULL_SPEED, SD_CS);
    delay(10);
   volume.init(&card);
    delay(10);
   root.openRoot(&volume);
    delay(10);
 
  // Initialize the Ethernet.
  Ethernet.begin(mac, ip);
  delay(100);
    
  //Start UDP client 
  Udp.begin(localPort);
  delay(100);
}

ciao

@bigjohnson se hai voglia e tempo prova a lanciare quasto comando:" ping -s 512 -c 400 -f -n ipdelloshield" sono curioso di vedere come reagisce a questo tipo di sollecitazione (non sulla rete aziendale! meglio con cavo incrociato diretto)
edit:
poi cambia il 512 in 3000 e riprova

Legacy tutta la roba che hai scritto centra poco con quello che volevo capire :slight_smile:
Io ero curioso di vedere come reagiva ai pacchetti fraggati creati da dati di dimensioni superiori all'mtu ethernet classico.
Non volevo tentare di saturare la banda , chiaramente, anche se con quel comando uccidi una isdn perun pò :smiley:
La parte udp sarebbe stata la prossima dello stresstest, ma se hai una via rapida per provarla in condizioni hardcore, mostacela (chiaramente senza fare uso di qualcosa di particolare :wink: hw/sw )
P.S. oh capito che lavori nel campo.... guarda che bel giocattolino http://www.spirent.com/Solutions-Directory/Avalanche

legacy:
Tu pensa a progetti come quello di Vaseo (domotica con arduino, rete di arduino) che sono basati su wiznet per avere tcp/ip in hw e che la Enc, per quanto esente dai difetti della wiz5100, queste cose non le fa, e che richiede un sacco di risorse che erano proprio uno dei criteri per i quali Vaseo si e' messo all'opera facendo le scelte implementative che ha fatto: mi sa che come minimo sara' intristito anche lui.

Oppure usera' anche lui il reset (appena compare sul forum glielo chiedo), al limite un cane da guardia NE555 o piu' avanzato, e tirera' avanti anche lui cosi', convivendo col baco fino a che non comparira' un chippettino in cui hanno spruzzato abbondantemente del DDT per debellare tutti quei bugarospi che ci alloggiano.

Ciao,

io uso delle librerie derivate da quelle standard, ma diverse nella gestione complessiva delle socket e parzialmente del chip, superata la fase di debug non ho mai riscontrato i problemi descritti qui. Però non ho mai provato l'interazione con SD.

Saluti,
Dario.

bigjohnson:
Se si vuole fare della domotica decente arduino può essere configurato come server ma deve rispondere ad un solo client che gira su un pc e che coordina tutte le utenze e serve le pagine web di controllo.
Con questa configurazione a stella si possono gestire anche centinaia di arduini e anche molti utenti simultanei.

In realtà, ci sono due considerazioni che permettono di ovviare alle limitate socket del W5100:

  • Completata la trasmissione dati, la socket può essere chiusa;
  • Le trasmissioni non sono contemporanee

In questo modo, anche utilizzando una sola socket, si ottengono connessioni multiple. Tali concetti si prestano ancora meglio se si implementa una connessione P2P e la trasmissione dati è basata su eventi.

Saluti,
Dario.

Ciao

Purtroppo ho visto questo thread solo ora... posso chiedervi di farmi una sintesi del problema e vedere come possiamo aiutarvi?

Per quanto riguarda lo shield le ultime 2 versioni sono molto stabili e le abbiamo in produzione da un tot. Sulla scheda ci sono un paio di cosine che aggirano dei problemi del Wiznet. credo ce ne siano in giro tra le 50 e le 80 mila schede di questo tipo...

m

Tra i bug-fix all'IDE di Arduino proposti su github, ho trovato una patch che sembra risolvere o perlomeno migliorare il comportamento del chip Wiznet. Tra le situazioni in cui il chip sembra freezarsi e una delle cause potrebbe essere che quando si trova nella condizione di lasciare una connessione, si mette nello stato di CLOSE_WAIT, quindi sta lì ad aspettate una risposta che di fatto non riceve perchè qualcosa è andato storto nella trasmissione precedente.

Questa cosa è tra quelle che succedono più frequentemente la patch proposta mira ad aggiungere alle condizioni per cui chiudere la connessione anche quella lo stato di CLOSE_WAIT. Quindi, come citavate qualche post fa, sembra essere l'implementazione di un workaround che migliora parecchio la situazione di freeze della Ethernet Shield.

Il lavoro da fare per applicare questa patch è davvero minimo perchè basta aprire il file EthernetClient.cpp che trovate nella directory della libreria Ethernet e nel metodo int EthernetClient::connect(IPAddress ip, uint16_t port) aggiungere la condizione || s == SnSR::CLOSE_WAIT all'interno del dell' if (s == SnSR::CLOSED || s == SnSR::FIN_WAIT)
quindi viene fuori così:

if (s == SnSR::CLOSED || s == SnSR::FIN_WAIT || s == SnSR::CLOSE_WAIT)

Se riceverà un buon numero di feedback positivi, questa patch verrà introdotta nella prossima release dell'IDE. A voi testarla, secondo me funziona!