Robustezza EtherShield per EN28J60

Buongiorno,

sto valutando le librerie disponibili per EN28J60 al fine di inserire lo stack TCP/IP ed i driver all'interno di vNet . La scelta è ricaduta su EtherShield, anche se non più ufficialmente supportata,perché risulta sufficientemente rapido il lavoro di integrazione.

L'integrazione comporterà diverse modifiche alla libreria stessa, mi interesserebbe quindi l'esperienza di chi ha utilizzato tale libreria, principalmente in relazione alla robustezza su funzionamenti per lunghi periodi. Ciò per evitare di iniziare un lavoro, scoprendo poi di dover spendere troppo tempo per ottenere del codice funzionante.

Grazie.

Saluti,
Dario

io l'ho tenuta sù per 3 mesi di fila una enc28j60 e non ha battuto mai ciglio con quella libreria.

BrainBooster:
io l'ho tenuta sù per 3 mesi di fila una enc28j60 e non ha battuto mai ciglio con quella libreria.

Ottimo.

legacy:
ciao Vaseo
ti posso dire che con lo stack rivisto e corretto di Microchip, sottoposto a vari interventi di source code analysis, sanity & purify, ho un nodo domotico con ENC28J60 acceso da 12 giorni, 24h al giorno, pesantemente torchiato da tool di analisi di rete, e non ho riscontrato fino ad oggi alcun problema.

Certo non ti saprei dire come si comporta lo stack tcp/ip originale, anche perche' ho dovuto modificarlo non poco per farlo entrare nel sottobosco drivers & protocols del kernel che gira sul nodo domotico, pero' ribadisco che l'hardware e' ottimo e a livello firmware, rispetto alla WIZ5100 dove hai le mani legate, la ENC28J60 ti offre la possibilita' di farti e rifarti tu lo stack tcp/ip a tuo piacimento, di cambiare le politiche di intervento in caso di problemi sulla rete, di congestione ad esempio, oppure di scegliere tu come gestire le tue finestre e i tuoi livelli di digest interno commisurati alla lunghezza dei tuoi buffer (che sono corti su Enc) ai tempi che vuoi garantire.

In realtà più che alla robustezza dell'integrato, mi interessava la robustezza dello staco TCP/IP utilizzato nella libreria EtherShield, che non è derivato dallo stack Microchip o se lo è ha subito profonde modifiche.

Il punto non è tanto quello di rifare il TCP, fondamentalmente superfluo, ma utilizzato al fine di avere una struttura di comunicazione facilmente replicabile su dispositivi comuni (ad esempio PC, Tablet, Smartphone) dove mi piacerebbe replicare il framework.

Grazie.

Saluti,
Dario.

Siamo un po tanto OT :relaxed:

legacy:
Per me la robustezza hw e' fondamentale dopo tutte le rogne che son venute fuori sul bus spi della wz5100 di cui ancora non si e' capito al nocciolo dove stia il problema quando SPI condivide il bus spi con la SD. Teoricamente ogni dispositivo SPI ha il suo CS per una mutua esclusione, se accadono problemi in concorrenza significa che c'e' qualcosa che non va da qualche parte, e non si puo' nemmeno intervenire nel firmware perche' e' embedded con il chip. Potrebbe essere una rogna delle lib di arduino, pero' ho avuto rogne anche con altri apparati NON arduino quindi per me la wiz3150 e la wi5100 sono un discorso del tutto chiuso.

Perche' a me non va bene non sapere cosa c'e' dentro al firmware non perche' sia fissato con l'opensource quando per il fatto che per questo lavoro non posso rendere piu' deterministica la fsm del tcp/ip, cosa che e' l'obbiettivo principale d itutto il lavoro.

Vabbé, ma questo non sposta di molto la bilancia, se hai un problema con l'SPI non puoi farci nulla, indipendentemente dal chip. Visto che il W5100 condivide il bus senza problemi con altri chip che richiestodono un'interfaccia SPI, non vorrei che il problema sia da imputare ad altre cause.
Però non ho seguito il problema, quindi non ne sono al corrente.

legacy:
Nel tuo caso, o ti adatti uno stack tcp/ip, oppure fai un paio di sessioni di test dove prendi il pezzo cosi' com e', fai integrazione blanda, e lo provi. Se soddisfa lo tieni, se non soddisfa lo rigetti.

Si, non voglio reinvetare la ruota, ed è pre questo motivo che mi interessava capire quali fossero le esperienza degli utenti con quella libreria, più che con il chip in se.
Se il chip non va, posso farci poco, se la libreria non va, ho qualche margine in più.

legacy:
Lo dico in modo mooooolto speculativo perche' non lo so come stanno le cose, pero' a naso secondo me lo stack usato nella Enc shield e' parente di quello Microchip dove avranno sicuramente alleggerito il tutto per consumare molte ma molte meno risorse.

Per come è fatto, direi di no. Però è sufficiente per le mie esigenze.

legacy:
Boh, facci sapere. Quanto ti posso dire e' che volendo al latoo kernel driver per linux la Enc ha supporto per SPI e una volta supportato il driver linux ha gia' il suo bravo stack tcp/ip, mentre nel caso di firmware per kernel embedded .... beh o te lo compri e poi comunque lo devi adattare, oppure te lo scrivi e ne approfitti per farlo su misura per la tua scheda di rete: non dovendolo astrarre ottieni molte meno righe, quindi molti meno bachi, e molte piu' prestazioni e flessibilita'.

Non si applica tanto al mio caso. I risultati saranno inclusi nelle prossime release di Souliss, non so se riuscirò già dalla prossima, prevista per fine Aprile, o se dalla successiva.

Saluti,
Dario.