Nin ho in mente un progetto, ma mi chiedevo se l'utilizzo di interrupt e comunicazione Ethernet potessero non andare d'accordo.
Il mio dubbio più grande è il seguente:
Se durante un'invio di un dato tramite Ethernet (anche di qualche migliaia di byte), mi si generasse un interrupt, che tenesse occupato arduino per alcuni secondi, avrei una corruzione del dato inviato via rete? Dovrei quindi iniziare di nuovo l'invio?
un interrupt che ti tiene occupato per un paio di secondi è un errore di per sè. già superare 1ms è tanto
Mettiamo che l'interrupt serva per gestire un qualcosa ad altissima priorità e sia generato da un pulsante, nella funzione richiamata dall'interrupt dovrei avere almeno un ritardo di 10/20ms per filtrare gli spike del pulsante.
Però stavo parlando in linea teorica, mettiamo che qualche secondo di interrupt sia possibile, darebbe problemi alla comunicazione ethernet?
non usi i delay ma fai un bebounce non la milis, quasto anche perchè la delay NON funziona dentro ad un interrup, quindi il problema come vedi è risolto di base
cmq uno o due secondi son tanti, rischi di far saltare tutte le comunicazioni, non conosco il protocollo della ethernet quindi non saprei dirti se è in grado di reggere un delay simile (e la perdita di tutti i messaggi durante questo tempo di delay)
Ciao,
con quale protocollo invii i dati?
Se utilizzi TCP se invii i dati utilizzando il protocollo TCP non credo dovresti aver, in genere, problemi. TCP (Transmission Control Protocol), che si occupa del controllo della trasmissione dei dati (il protocollo IP e quelli di livello inferiore non lo fanno), e' pensato per garantire la trasmissione dei dati anche in presenza di problemi sulla rete.
I suoi timeout non sono fissi, ma sono variabili in funzione dello stato della rete ed i parametri di configurazione base.
In genere i timeout dei protocolli che sono sopra il TCP, ad esempio, HTTP sono piuttosto lunghi, per cui in genere non si hanno problemi.
Per quanto riguarda la trasmissione dei dati via SPI da ATmega a chip W5100 penso che non dovrebbero eserci problemi perche' finche' il pin /SS e' low si sara' in trasmissione dati.
Puoi fare dei test ad esempio utilizzando Wireshark (analizzatore di protocollo open source, un tempo denominato Ethereal) per monitorare il tutto.
Ciao,
Marco.
il problema non è la comunicazione ethernet shield -> internet, ma arduino -> ethernet shield.
anche perchè la gestione del protocollo TCP da parte del wiznet è completamente indipendente, quindi anche se arduino fosse blocato per 10 minuti (con keep-alive attivo) la connessione non cadrebbe
La comunicazione sarà di tipo TCP con protocollo HTTP.
A quanto mi pare di aver capito il modulo Ethernet lavora in maniera indipendente da arduino che però rimane in attesa di una conferma dallo wiznet del corretto invio, questa cosa me la immaginavo, quindi se occorresse un interruzione a seguito dell'invio delle istruzioni al wiznet, non succederebbe niente e in pratica avrei una specie di multitasking (arduino lavora sull'interrupt, lo wiznet sulla comunicazione http).
La parte critica quindi è il momento in cui i due comunicano per impostare la connessione.
Se occorresse un'interruzione in questo momento?
P.s. Nel compilatore di arduino ci sono i sorgenti della libreria Ethernet per vedere se in qualche punto le interruzioni vengono disattivate?
ti ho già spiegato perchè non può funzionare l'interrupt fatto in quel modo (non funzionano gli interrupt del timer, quindi la delay non funziona, e la millis rimane fissa), comuque credo che un softreset alla ethernet prima di usarla dovrebbe bastare
La delay e la millis non sono le uniche soluzioni con cui posso "perdere tempo", sarebbe sufficiente un for che incrementi un certo numero di volte una variabile, e a seconda della frequenza di funzionamento e dal ritardo che voglio ottenere cambio il valore fino al quale il for dovrebbe contare.
Ho già gestito cose del genere con i Pic Micro, e ho sempre filtrato gli spike di un pulsante con un ritardo di circa 10/20ms all'interno della funzione che l'interrupt richiamava, quindi non vedo problemi nell'interrupt.
Io stavo gentilmente chiedendo tutt'altro, cioè se un'interrupt (qualunque esso sia), e nel peggiore dei casi, possa dar fastidio alla comunicazione via Ethernet, e il punto nevralgico mi sembrava il momento in cui arduino istruisce lo wiznet sul da farsi...
fai come vuoi, come fastidio alla comunicazione ti dico molto probabilmente sì, ma puoi risolvere resettando ogni volta l'ethernet shield, che poi è una pratica consigliata se usi sia la shield che la su SD perchè ci sono casi in cui tende a bloccarsi