Board Arduino Ethernet si blocca sistematicamente!

Carissimi, è una settimana che cerco sui vari forum la soluzione ad un semplicissimo problema: la mia board "Arduino Ethernet" smette di comunicare tramite ethernet in maniera aleatoria ma sistematica.

L'unico modo per far tornare tutto a funzionare è quello di resettare la board con l'apposito tasto. Passa qualche ora, o qualche giorno, e nuovamente la Arduino Ethernet board smette di comunicare via Ethernet.

Ho capito, leggendo sui vari forum, che chi ha Arduino XXX + Ethernet Shield, armato di saldatore, può risolvere alla male e peggio questo problema che è causato, ahimé, dal controller ethernet WIZnet.

Quello che non ho capito è come faccio io che ho la "Arduino Ethernet" board a risolvere il problema...

Aggiungo che ritengo una grave deficienza che sul sito della "Arduino Ethernet" board non si faccia esplicita menzione a questo problema SISTEMATICO. In pratica la "Arduino Ethernet" board, così come è venduta, può essere usata solo per giocare per qualche ora...

Ringrazio chiunque sia in grado di fornirmi una soluzione definitiva al problema (magari da linkare sulla pagina che promuove la "Arduino Ethernet" board, così da non far impazzire sul web i poveracci che l'hanno acquistata).

Cordiali saluti, Vincenzo Suraci

Non ho capito di quale board/shield parli, è quella originale o una compatibile? Il w5100 lo hanno tutte taroccate e non. Io questo problema non ce l'ho con una originale, non hai considerato che potrebbe essere un problema software?

hai postato il programma che usi? hai postato il modello esatto?

Carissimo,
innanzitutto grazie per la risposta! Spero di poter aggiungere informazioni utili a risolvere questo problema che affligge la board Arduino Ethernet.

Non ho capito di quale board/shield parli, è quella originale o una compatibile? Il w5100 lo hanno tutte taroccate e non.

Uno dei problemi nel mondo Arduino è proprio la nomenclatura delle varie board. Sul sito di Arduino la board di cui parlo è chiamata “Arduino Ethernet Rev3 WITHOUT PoE”. Per evitare problemi di identificazione metto direttamente il link alla pagina: http://arduino.cc/en/Main/arduinoBoardEthernet

Ho acquistato la board direttamente dal sito di Arduino e il modello che ho in possesso è identico a quello mostrato nelle foto del link summenzionato.

Io questo problema non ce l’ho con una originale, non hai considerato che potrebbe essere un problema software?

Da quando ho la board, ho fatto centinaia di tentativi. E ogni sketch dava lo stesso problema. In maniera aleatoria, la ethernet smetteva di trasmettere pacchetti mentre il micro Arduino continuava a funzionare.

All’inizio pensavo fosse un problema di sensori. Poi ho pensato fosse un problema di memoria. Poi ho pensato fosse un problema di surriscaldamento. Ogni volta, dopo qualche giorno di funzionamento, la ethernet si blocca.

Alla fine mi sono messo su internet a scartabellare tutti i forum e ho trovato una montagna di thread che parlano del problema del chipset della WIZnet di Arduino (sia sulla shield ethernet che su Arduino Ethernet).

Finora l’unica soluzione chiara sembra essere quella di usare il saldatore: ad es. http://sandfly.net.nz/blog/2013/04/a-horrible-method-of-hardware-resetting-an-arduino/
Ma se così fosse, mi piacerebbe sapere prima di acquisire una arduino ethernet originale che è affetta da un grave malfunzionamento (hw o sw) del modulo WIZnet, tale per cui la scheda è destinata a smettere di trasmettere su ethernet.

hai postato il programma che usi?

Per limiti di spazio provvedo nel prossimo thread.

Grazie ancora dell’attenzione datami.

Saluti,
Vincenzo Suraci

/*
  Web Server v7
  
  Modalità d'uso
  - Connettere la board Arduino Ethernet direttamente tramite il programmatore USB (non c'è bisogno di alimentazione né in fase di programmazione, né in fase di test)
  - Connettere il cavo ethernet (in fase di test e/o durante la programmazione)
  
  Funzionalità:
  - Web Server
  - DHCP client
  - Sensore di luce
  - Sensore di temperatura e di umidità
  - Sensore di temperatura 
  
  v6 -> v7
  - la risposta HTTP è un file JSON
*/

#include <SPI.h>
#include <Ethernet.h>
#include <OneWire.h>
#include <DallasTemperature.h>

#define DHT11_PIN 0       // define the analog  port where the DHT11 sensor is connected (e.g. pin 0)
#define LIGHT_PIN A1      // define the analog  port where the LIGHT sensor is connected (e.g. pin 1)
#define DALLAS_PIN 6      // define the analog  port where the LIGHT sensor is connected (e.g. pin 1)

// Serial Debug
const boolean SERIAL_DEBUG = true;

// DCHP configuration
const boolean DHCP_ENABLED = false;   // true if you want to use the DHCP
const byte MAX_DCHP_TENTATIVES = 10;  // MAX number of DHCP tentatives to obtain a valid IP
const byte DCHP_WAITING = 1000;       // Milliseconds between a try and the other

// sensor variables
byte temp_integer = 0;    
byte temp_decimal = 0;
byte humid_integer = 0;
byte humid_decimal = 0;
int light_integer = 0;

// Setup a oneWire instance to communicate with any OneWire devices (not just Maxim/Dallas temperature ICs)
OneWire oneWire(DALLAS_PIN);

// Pass our oneWire reference to Dallas Temperature. 
DallasTemperature sensors(&oneWire);

// Enter a MAC address and IP address for your controller below.
// The IP address will be dependent on your local network:
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
IPAddress ip(192,168,1,251);

// Initialize the Ethernet server library
// with the IP address and port you want to use 
// (port 80 is default for HTTP):
EthernetServer server(80);

void setup()
{
  // start serial port:
  if (SERIAL_DEBUG) Serial.begin(9600);
  
  // Start up the library
  sensors.begin(); // IC Default 9 bit. If you have troubles consider upping it 12. Ups the delay giving the IC more time to process the temperature measurement
    
  // get an IP address  
  getIP();
  
  // start the server  
  server.begin();
}

void loop()
{  
  //if (SERIAL_DEBUG) Serial.println(getJson());
  //delay(1000);

  // webserver
  webserver();
}

void getIP()
{
  byte tentative = 1;
  boolean ip_address_assigned = false;
  
  // start the Ethernet connection. Try with DHCP
  while ( !ip_address_assigned && (tentative <= MAX_DCHP_TENTATIVES) && DHCP_ENABLED) 
  {
    if (SERIAL_DEBUG) Serial.print("Trying to get IP address by DHCP - Tentative #");    
    if (SERIAL_DEBUG) Serial.println(tentative, DEC);    
    if (Ethernet.begin(mac) == 0)
    {
      if (SERIAL_DEBUG) Serial.println("DHCP tantative failed!");    
      delay(DCHP_WAITING);
      tentative++;
    }
    else
    {
      if (SERIAL_DEBUG) Serial.println("DHCP tantative successful!");    
      ip_address_assigned = true;
    }    
  }
  
  // If DHCP failed, try manually
  if (!ip_address_assigned)
  {
    Ethernet.begin(mac, ip);
    if (SERIAL_DEBUG) Serial.println("IP setup manually!");
  }

  // Print the local IP address
  if (SERIAL_DEBUG) Serial.println(Ethernet.localIP());
}

void webserver()
{
  // listen for incoming clients
  EthernetClient client = server.available();
  if (client) 
  {
    // an http request ends with a blank line
    boolean currentLineIsBlank = true;
    while (client.connected()) 
    {
      if (client.available()) 
      {
        char c = client.read();
        // if you've gotten to the end of the line (received a newline
        // character) and the line is blank, the http request has ended,
        // so you can send a reply
        if (c == '\n' && currentLineIsBlank) 
        {
          // send a standard http response header
          client.println("HTTP/1.1 200 OK");
          client.println("Content-Type: application/json");
          client.println();
                    
          // output the value of temperature, humidity and light
          client.println(getJson());
          
          break;
        }
        if (c == '\n') 
        {
          // you're starting a new line
          currentLineIsBlank = true;
        } 
        else if (c != '\r') 
        {
          // you've gotten a character on the current line
          currentLineIsBlank = false;
        }
      }
    }
    
    // give the web browser time to receive the data
    delay(1);
    
    // close the connection:
    client.stop();
  } 
}

//---------------------------------------------------------------------------------
//
String getJson()
{
    String json = "";
    
    json += "{";
    json += "\"temperature\": \""+getTemperature()+"\", ";    
    json += "\"humidity\": \""+getHumidity()+"\", ";        
    json += "\"light\": \""+getLight()+"\"";
    json += "}";
    
    return json;
}

String getTemperature()
{
    // Send the command to get temperatures
    sensors.requestTemperatures();
    
    String temperature = "";
    char _buffer[10]; 
    temperature += dtostrf(sensors.getTempCByIndex(0),2,2,_buffer);
    // per stampare il carattere ° è necessario usare un escaping in valori ottali...
    // la codifica è di tipo UNICODE
    //temperature += "\260C";    
    
    return temperature;
}

String getHumidity()
{
    String humidity = "";
    
    if (update_dht11_data()==true)
    {
      humidity += humid_integer;
      humidity += ".";
      humidity += humid_decimal;
      //humidity += "%";
    }
    
    return humidity;  
}  

String getLight()
{
    // Send the command to update light data
    update_light_data();
    
    String light = "";    
    light += light_integer;    
    
    return light;    
}  

/*
- synch with the DHT11 sensor
- update the temp and humidity values
- returns true if checksum is fine, returns false otherwise
*/
boolean update_dht11_data()
{
  // temperature/humidity sensor setup
  DDRC |= _BV(DHT11_PIN);   //let analog port DHT11 be an output port 
  PORTC |= _BV(DHT11_PIN);  //let the initial value of this port be '1'
  
  byte dht11_dat[5];    
  byte dht11_in;
  byte i;// start condition
 
  PORTC &= ~_BV(DHT11_PIN);    // 1. pull-down the DHT11 pin for 18ms
  delay(18);
  
  PORTC |= _BV(DHT11_PIN);     // 2. pull-up the DHT11 pin for 40micros
  DDRC &= ~_BV(DHT11_PIN);     //let the DHT11 analog port be input port 
  delayMicroseconds(40);      
  
  dht11_in = PINC & _BV(DHT11_PIN);  // read only the DHT11 input port
  if(dht11_in)
  {
    delay(1000);
    return false;
  }
  
  delayMicroseconds(80);
  dht11_in = PINC & _BV(DHT11_PIN); //  
  if(!dht11_in)
  {    
    return false;
  }
  
  delayMicroseconds(80);// now ready for data reception
  for (i=0; i<5; i++)
  {  dht11_dat[i] = get_dht11_data(); }  //recieved 40 bits data. Details are described in datasheet
  
  DDRC |= _BV(DHT11_PIN);      //let analog port 0 be output port after all the data have been received
  PORTC |= _BV(DHT11_PIN);     //let the  value of this port be '1' after all the data have been received
  byte dht11_check_sum = dht11_dat[0]+dht11_dat[1]+dht11_dat[2]+dht11_dat[3];// check check_sum
  if(dht11_dat[4]!= dht11_check_sum)
  {
    return false;
  }
  temp_integer = dht11_dat[2];    
  temp_decimal = dht11_dat[3];
  humid_integer = dht11_dat[0];
  humid_decimal = dht11_dat[1];
  return true;
}

byte get_dht11_data()
{
  byte i = 0;
  byte result=0;
  for(i=0; i< 8; i++)
  {
    while(!(PINC & _BV(DHT11_PIN)))
    {};  // wait  forever until analog input port is '1'   (NOTICE: PINC reads all the analog input ports 
    //and  _BV(X) is the macro operation which pull up positon 'X'to '1' and the rest positions to '0'. it is equivalent to 1<<X.) 
    delayMicroseconds(30);
    if(PINC & _BV(DHT11_PIN))  //if analog input port 0 is still '1' after 30 us
      result |=(1<<(7-i));     //this position is 1
    while((PINC & _BV(DHT11_PIN)));  // wait '1' finish
    }
    return result;
}

void update_light_data()
{
      light_integer=analogRead(LIGHT_PIN);          //connect grayscale sensor to LIGHT_PIN Analog pin
}

Ciao, anch'io ho la tua stessa Ethernet Shield e la utilizzo per inviare dati ad una pagina php sul web.

Sin dall'inizio ho avuto continui ed inspiegabili interruzioni di comunicazione, sin quando nel forum ho letto di un paio di righe nel setup, che mi hanno risolto la questione. Nel mio caso, "alzare" i pin 4 e 10 ha eliminato completamente le interruzioni (funziona da mesi senza problemi).

Il tuo codice è troppo complicato per me, e se non le hai già inserite (e mi pare che non vi siano), mi auguro che queste poche righe possano fare la differenza nel tuo sistema come l'hanno fatto nel mio.

I più esperti potranno spiegarti il perchè dei pin 4 e 10, non ricordo la spiegazione che all'epoca (diversi mesi fa) avevo visto essere piuttosto "profonda".

void setup()
{
    pinMode(4,OUTPUT);
    digitalWrite(4,HIGH);

    pinMode(10,OUTPUT);
    digitalWrite(10,HIGH);


    // start the Ethernet and UDP:
    Ethernet.begin(mac, ip);
    Udp.begin(porta);

    ...
    ...

Spero d'esser stato d'aiuto.

Un saluto, Tredipunta.

È un problem di RAM esaurita. Usa la makro F() per risparmiare RAM in ogni ...print("testo") come per esempio: client.println(F("HTTP/1.1 200 OK")); Ciao Uwe

Gent.mi,
vi ringrazio per le risposte. Proverò le soluzioni che mi avete suggerito.

Quella di alzare i PIN 4 e 10 non l’ho implementata. Sembra una mossa da stregoni :), indagherò sul suo effetto e rignrazio per avermela fatta conoscere.

Quella di utilizzare la funzione F() per risparmiare memoria RAM è una idea interessante, messa così però sembra che ci sia un problema di un buffer di memoria finito che si riempe senza mai svuotarsi. Visto che io eseguo dei cicli, immagino che alla fine di un ciclo ( riportato nella funzione loop() ) la memoria RAM venga liberata. La ethernet si blocca dopo giorni, dopo aver eseguito centinaia di richieste e risposte HTTP. Farò comunque la prova per testare l’affidabilità di questa board.

Senza questa affidabilità, ritengo la Arduino Ethernet di poca utilità pratica.

Grazie mille!

Vincenzo Suraci

Gent.mi, almeno per il PIN 4 e il PIN 10 credo di aver capito perché siano stati tirati in ballo.

PIN 4 e PIN 10 sono menzionati nella descrizione della ETHERNET SHIELD. Il link alla pagina è il seguente: http://arduino.cc/en/Main/ArduinoEthernetShield

Riporto per comodità il pezzo: Note that because the W5100 and SD card share the SPI bus, only one can be active at a time. If you are using both peripherals in your program, this should be taken care of by the corresponding libraries. If you're not using one of the peripherals in your program, however, you'll need to explicitly deselect it. To do this with the SD card, set pin 4 as an output and write a high to it. For the W5100, set digital pin 10 as a high output.

La mia riflessione è la seguente: capisco che per disabilitare SD e W5100 si debba agire sui pin 4 e 10, ma ciò vale per una configurazione Arduino XXX con Ethernet Shield. Tale considerazione vale anche per una board Arduino Ethernet?

Vorrei ricordare infatti che tra i vari prodotti Arduino, esiste una board chiamata "Arduino Ethernet" che monta nativamente il chipset W5100 (link), mentre moltissimi usano la baord Arduino (ad es. Arduino UNO) in accoppiata con la shield Ethernet (link). Credo che tali due configurazioni, benché simili non siano esattamente identiche.

Nella descrizione della board Arduino Ethernet viene fatta questa descrizione: Pin 10 is reserved for the Wiznet interface, SS for the SD card is on Pin 4.

Farò delle prove per verificare che questa soluzione risolva il problema. Vi terrò aggiornati...

Vincenzo Suraci

La comunicazione SPI può effettuarsi solo con un dispositivo alla volta, quello che deve rispondere viene selezionato con il pin SS. Possono esserci più pin SS lato Arduino ma per ogni pin deve corrispondere solo un device. Ecco quindi che sull'Arduino Ethernet vengono separati già di suo, con il 10 per il Wiz ed il 4 per la SD.

Quella di utilizzare la funzione F() per risparmiare memoria RAM è una idea interessante, messa così però sembra che ci sia un problema di un buffer di memoria finito che si riempe senza mai svuotarsi. Visto che io eseguo dei cicli, immagino che alla fine di un ciclo ( riportato nella funzione loop() ) la memoria RAM venga liberata.

E' un discorso complesso, non è facile riassumerlo in poche righe. Nell'Arduino NON hai un sistema di garbage collector né un sistema di gestione automatica del garbage per cui la RAM, che è poca (solo 2K) si esaurisce velocemente se pensi che in essa, oltre alle variabili, vengono creati lo stack, l'heap, i buffer seriali, e copiate TUTTE le stringhe prima di essere utilizzate. Risparmiare anche 10 byte su questo genere di MCU può fare la differenza.

Io mi batto dal 2011 dall' IDE 0022 sul "difetto" della ethernet (difetto si fa per dire perchè una carenza software), argomento detto stradetto, trito e ritrito e in tutte queste parole non avete detto qual'è la vera ragione ... che è molto più semplice degli argomenti tirati in ballo fino ad ora :D ;D ;D

pablos: Io mi batto dal 2011 dall' IDE 0022 sul "difetto" della ethernet (difetto si fa per dire perchè una carenza software), argomento detto stradetto, trito e ritrito e in tutte queste parole non avete detto qual'è la vera ragione ... che è molto più semplice degli argomenti tirati in ballo fino ad ora :D ;D ;D

Gent.mo Pablos, la ringrazio per essere intervenuto.

Dalle sue parole emerge in forma più o meno esplicita il fatto che il "difetto" della ethernet (immagino si riferisca alla board Arduino Ethernet link) è dovuto ad una carenza software e non è un problema che deve essere risolto via hardware;

Quello che non sono riuscito a capire è se questo problema sia stato risolto DEFINITIVAMENTE oppure no.

Al meglio della mia conoscenza, non esiste alcuna IDE scaricabile dal sito ufficiale di Arduino che abbia risolto il problema software cui lei fa cenno. Nella descrizione della board in esame (link) non c'è alcun riferimento a tale problema software.

Chiedo venia se questo argomento sia "detto stradetto, trito e ritrito" ma, come giustamente scrivevo all'inizio di questa discussione, non sono riuscito a trovare una soluzione UFFICIALE e DEFINITIVA a questo arcinoto problema...

Pertanto arrivo alle domande: A) Esiste una soluzione al problema che ho menzionato all'inizio della discussione, per la board Arduino Ethernet? B) Ammesso che tale soluzione esista, posso chiedere la cortesia, a chi la conosce, di rispondermi allegando un link alla soluzione (in inglese o in italiano)?

Concludo quindi con un aggiornamento delle soluzioni proposte da alcuni di voi.

Dopo una settimana di prove l'aver resettato i PIN 4 e 10 via software risulta che: 1. La board Arduino Ethernet presenta ancora problemi di blocco. 2. L'accoppiata board Arduino Uno con Ethernet Shield sta funzionando in maniera continuativa da più di una settimana, battendo pertanto ogni record finora registrato.

In base a ciò posso concludere che l'aver resettato i PIN 4 e 10 via software NON ha risolto il problema sulla board Arduino Ethernet.

Cordiali saluti, Vincenzo Suraci

Nell'IDE 1.5.8 c'è la nuova libreria SPI con le API transaction che pongono fine ai problemi sulla gestione multipla di periferiche su bus SPI. (si spera!) Provatela!!

Verranno implementate anche sulla prossima 1.0.7 e sono retrocompatibili: l'ho provata con la libreria EtherCard per ENC28J60 e funziona.

Segui il consigli di Uwe..... usa la F().

P.S. Perchè non usi una libreria per il DHT11? L'uso diretto dei registri, sebbene molto più veloce, rende il codice non portabile su altri modelli di Arduino.

Ciao, mi auguravo che la questione fosse stata risolta con i PIN 4 e 10.

Giusto per chiarezza: Io utilizzo l'accoppiata Arduino UNO (in verità si tratta di un Atmega328 in Stand Alone a 8MHz) + Ethernet Shield, senza aver alcun problema.

Un saluto, Tredipunta.

La questione pin 10 e 4 è molto semplice e banale, l'ho scritto altre volte ma non trovo ora i post vecchi quindi proverò a riscriverlo sinteticamente.

L'SPI è un bus di comunicazione tra CPU e periferiferiche ed è uno soltanto nel nostro chip in questione, è come se ti parlassero 2-3 persone contemporaneamente ... tu che fai? dici, scusate parlate uno alla volta perchè se no qui esce un macello e nessuno capisce nessuno, il software si occupa appunto di ascoltare una periferica alla volta tramite interrupt. Quindi come lo fa? col pin 4 per "parlare" con l'SD e col pin 10 per "parlare" con il w5100.

Questi pin quando passano a LOW "dicono alla CPU ascolta me e voi tutti zitti" pertanto solo uno deve passare a 0 gli altri devono stare "muti" portandosi a 1, (intanto per cominciare in silenzio nel setup li mettiamo tutti "muti" in HIGH)

Premesso quanto sopra in modo molto grottesco: Quando si usa un pin qualsiasi andrebbe settato per correttezza perchè esso si trova per default in uno stato "appeso" o meglio flottante, esso può cambiare di stato per un innezia un disturbo, una variazione di tensione ... (senza impostazione) può capitare quindi che 2 periferiche per un istante "parlino" insieme oppure una "parli" quando la CPU non attende messaggi da essa ... [u]questa fatalità casuale genera il tuo crash inatteso[/u] e ti assicuro che prima o poi arriva.

Per questo è importante stabilire e settare correttamente quei pin in OUTPUT Le librerie non contengono le istruzioni pinMode(4,OUTPUT); pinMode(10,OUTPUT); si limitano solo a fare un digitalwrite (CS, 0 o 1) per mettere la periferica in comunicazione o per farla tacere, tutto questo per un semplice motivo, ci sono vari modelli di shield che usano vari pin di controllo CS enable/disable definite dal costruttore, quindi queste considerazioni devono essere fatte dall'utente previa configurazione l'hardware.

Bastava solo che da qualche parte ci fosse stato scritto "ricordati quando monti uno shield di dichiarare i pin CS e di portarli in HIGH nel setup", ciò non è stato fatto e ha creato non poca confusione.

Nella versione 1.5.7 le cose sono cambiate, almeno per quello che riguarda la DUE, tutti i pin sono già preimpostati in OUT e tutti in HIGH all'avvio, non ho verificato per gli AVR se tale versione fa altrettanto, comunque scrivere 2 righe in più nel setup nell'incertezza male non fa.

Siamo in un ambiente sperimentale di prototipazione, opensource e non sempre quello che troviamo è definitivo e tantomeno da considerarsi legge. L'errore che fanno in molti (me compreso nel 2011) è che comprano arduino pensando tanto trovo tutto funzionante in rete con la differenza che alcuni restano e lo studiano, altri si inca***no e abbandonano, dando la colpa a software o hardware malfatti.

Io non dico che l'impostazione di questi 2 pin è la soluzione ai problemi del mondo, ma intanto ne elimini metà, aproffitto per fare chiarezza a una tua espressione :)

Quella di alzare i PIN 4 e 10 non l'ho implementata. Sembra una mossa da stregoni

Ps. non ci dare del lei non è necessario, noi non faremo altrettanto ... :D

tredipunta: Ciao, mi auguravo che la questione fosse stata risolta con i PIN 4 e 10.

Giusto per chiarezza: Io utilizzo l'accoppiata Arduino UNO (in verità si tratta di un Atmega328 in Stand Alone a 8MHz) + Ethernet Shield, senza aver alcun problema.

Un saluto, Tredipunta.

Gent.mo Tredipunta, mi preme sottolineare che la sua soluzione mi è stata di aiuto eccome!

Ho implementato due diverse configurazioni di Arduino per poter misurare temperatura ed umidità in ambienti indoor.

Configurazione 1 - Arduino UNO - Ethernet Shield rev3

Configurazione 2 - Arduino Ethernet

Credo di poterle confermare che l'aver settato HIGH i PIN 4 e 10 in fase di setup() abbia in effetti reso stabile la configurazione 1.

Purtroppo tale soluzione non sembra aver risolto il problema nella configurazione 2.

Ieri sera ho resettato di nuovo la configurazione 2, ma con una variante. La board ethernet infatti montava una scheda SD che non utilizzavo. Ho provato a rimuoverla. Teoricamente questo non dovrebbe cambiare il risultato, in quanto il settaggio dei PIN 4 e 10 era proprio orientato ad escludere l'accesso aleatorio al bus SPI alla W5100 e alla SD.

In conclusione, la ringrazio per avermi subito messo sulla strada giusta!

Cordialità, Vincenzo Suraci

Gent.mo Vincenzo Suraci,

Il blocco del wiznet come viene da Lei rilevato?

Connettendosi e vedendo che il browser non risponde? Un istante prima di quella connessione Lei è certo che il chip fosse operativo e non in blocco? Quale browser usa per connettersi google chrome e/o un android? Ha un dispositivo ottico da osservare visivamente sempre prima di fare la connessione web?

perchè Le dico questo? In mesi di test che feci su questo benedetto chip dovetti a tutti i costi capire prima di tutto quale era la causa scatenante, quale era l'azione che io facevo prima di trovarlo in blocco, ero io o andava in blocco da solo?

Quindi piazzai un led lampeggiante che mi indicava l'attività regolare del chip e scoprii che ero sempre io a mandarlo in blocco appena tentavo una delle tante connessioni random, il led rimaneva acceso fisso o spento.

Ora restava da capire quale browser e quale dispositivo usavo per connettermi causava 1 volta su 10 il crash .....

Qualora Lei intendesse utilizzare quella scheda dovrebbe mettere in preventivo che ci vorrà molto tempo, posso quindi suggerirLe di: - Capire principalmente quale sia la causa scatenante; - Fare un un init del w5100 ogni tanto ad esempio al termine della connessione o anche ogno 2-3 minuti e di provare con quello; - Fornire un alimentazione stabile, adeguatamente filtrata e immune da disturbi che possono entrare nei chip; - Non utilizzare ne android ne google chrome per il momento;

nel caso si intendesse utilizzare chrome disabilitare le opzioni come descritto https://support.google.com/chrome/answer/1184722?hl=it non per ottimizzare il pc, ma per terminare la connessione continua che occupa i soket con continue richieste

Cordialità,

P.S. nemmeno al mio legale scrivo così :D

Avete provato ricompilando gli sketch con l’IDE 1.5.8?

PaoloP:
Avete provato ricompilando gli sketch con l’IDE 1.5.8?

Grazie per il suggerimento.

Stupidamente, seguendo le indicazioni riportate qui, avevo scaricato la IDE 1.0.6, pensando che fosse la migliore per la scheda Arduino Ethernet.

La IDE 1.0.6 sul mio win7 a 64 bit gira malissimo, e si blocca. Ho pertanto optato per la Arduino ERW 1.0.5, che va una meraviglia…

Farò tutte le prove pur di rendere operativa la Arduino Ethernet :slight_smile:

VS

Caro Pablos, grazie per la risposta e per gli spunti. Cercherò di essere il più preciso possibile, nonostante la mia ignoranza in materia.

Inizio col dire che dopo aver implementato la soluzione di PIN 4 e PIN 10 HIGH sulla configurazione hardware 1 (Arduino UNO + Ethernet Shield) e sulla configurazione hardware 2 (Arduino Ethernet) , a parità di script e di sensori installati, la configurazione 1 sta funzionando stabilmente da più di una settimana, mentre la configurazione 2 va in blocco continuamente e deve essere resettata (io stacco e riattacco l'alimentazione).

Non ho pensato a far blinkare led o ad acquistare LCD esterni. Sono arrivato ad ipotizzare il blocco della Wiznet dopo aver fatto una serie di test. Quello che maggiormente mi ha portato a indicare la wiznet come la causa del blocco è che la seriale della Arduino Ethernet rispondeva ai comandi anche dopo che la stessa Arduino Ethernet smetteva di dare segni di vita da rete.

Escludo che sia il browser a causare il problema. Io non interrogo la scheda usando un browser, ma usando uno script PHP che tramite chiamate CURL interroga Arduino con una GET HTTP. Tale interrogazione ha una frequenza di una chiamata al minuto. La configurazione 1 (Arduino UNO + Ethernet Shield), a parità di sensori e di sketch, risponde costantemente da più di una settimana (pari a più di 7*24*60 = 10.080 richieste GET HTTP). La configurazione 2 (Arduino Ethernet), a parità di sensori e di sketch, continua a bloccarsi in maniera aleatoria.

Mi ha interessato il suo suggerimento:

pablos: - Fare un un init del w5100 ogni tanto ad esempio al termine della connessione o anche ogno 2-3 minuti e di

Dal basso della mia totale ignoranza in materia avevo capito, leggendo altri thread, che il chipset W5100 non potesse essere resettato via software (leggevo di post in cui si resettava fisicamente tutta la scheda Arduino Ethernet...). Evidentemente mi sbagliavo.

Posso chiederle la cortesia di postarmi le righe di codice necessarie per far ciò?

Altra cosa che ho intuito dalla sua risposta è che lei sia riuscito a far funzionare la scheda Ethernet Shield in maniera continuativa semplicemente cambiando browser (evitando cioè di interrogare la scheda usando Chrome o il browser montato di default sui dispositivi Android). Questa cosa mi rende felice, ma non risolve il mio problema.

In effetti la configurazione 1 (Arduino UNO + Ethernet Shield) sembrerebbe funzionare correttamente, mentre la configurazione 2 (Arduino Ethernet) continua a manifestare problemi.

Per ora l'unica strada percorribile che abbia un senso è provare a compilare lo sketch con varie IDE fino a trovare quella che monta di default librerie funzionanti per questa configurazione.

Grazie per tutti i suggerimenti.

VS

P.S.: non mi offendo se mi si dà del tu. Io sono un newbie e mi piace portare rispetto a chi ha già passato ore a risolvere grane per nome e per conto di tutti!

PaoloP: Avete provato ricompilando gli sketch con l'IDE 1.5.8?

Io non ho più questo problema dal 2012 a prescindere dalla versione dell'IDE che era 0023 o 101 per questo dico che se è un problema della scheda si può risolvere, ma ci vuole tempo.