oggi ho speso qualche ora a guardare la nuova WiFi shield ufficiale, personalmente non ne sono particolarmente interessato, ma servirebbe ad un amico.
Guardando il codice lato Arduino e lato AVR sulla shield, mi è sembrato che le possibilità offerte siano nettamente inferiori a quelle delle schede basate su W5100. A prima vista sembra non essere possibile gestire connessioni UDP lato Arduino, anche se lo stack sulla shield processa UDP per DHCP, ne si può impostare l'indirizzo IP in modo statico.
A meno della delusione per ciò, la mia domanda è, questa scheda riesce a gestire informazioni in broadcast. Per sua natura, TCP non può lavorare in broadcast, dovendo stabilire a priori una connessione, ma dal codice non sono riuscito a capire se esista una back-door per far arrivare i messaggi in broadcast fino al 328.
Il mio timore è che vengano processati dall'AVR della shield senza essere inviati all'Arduino.
Personalmente sono sempre stato un sostenitore dello stack in hardware, perché le risorse del 328 sono limitate ed avendo implementato uIP per l'ENC28J60 nel progetto Souliss, so bene che ci sono enormi differenze. Purtroppo, a differenza della versione Ethernet cablata basata su W5100 e con stack in hardware, questa nuova shield offre davvero poco.
Solo mettendo le mani nel firmware dell'AVR sulla shield si può pensare di farla rendere per quanto costa, ma il tempo da impiegare unito al costo non certo contenuto, fa pendere a mio parere l'ago della bilancia verso controller che offrono solo il livello MAC come quelli di Olimex.
Spero migliori nel tempo, nel frattempo, se qualcuno ha avuto una visione più lucida del codice oppure ha provato il broadcast, potrebbe sciogliere il mio dubbio?
Lo shield wifi è progettato per prendersi carico di tutto il lavoro e fare in modo che la libreria lato arduino sia molto leggera.
W5100 ha una serie di bachi per i quali la libreria deve mettere delle toppe. E visto che il fw è in hardware proprietario te li tieni cosi.
(incluso il baco hw sul chip select e il surriscaldamento etc) per questo non capisco come fa un processore chiuso e bacato ad essere migliore
Mettere tutto il FW in un processore aperto aggiunge molte possibilità al sistema. Nell'implementare il FW abbiamo scelto di metterci le funzioni più usate lasciando spazio alla comunità di creare le applicazioni più custom.
Sui controller che forniscono solo il MAC non devi comunque scrivere del codice??
Mi permetto di non essere daccordo sul fatto che questa scheda offra poco: offre una buona implementazione di wifi con WEP,WPA e tutto il resto fornendo tutto il sorgente aperto e modificabile. Gli altri ti danno allo stesso prezzo un modulo pre-programmato del quale non sai nulla e non può modificare nulla.
Fatti mandare il sorgente del modulo microchip se ci riesci e fai il confronto
temevo che mi avresti risposto Assumo che la risposta alla gestione del broadcast sia no.
La mia vuole essere una critica costruttiva, perché la shield ha sicuramente un elevato potenziale, ma attualmente in termini di funzionalità è molto più chiusa delle alternative. Sono sicuro che con il tempo la situazione sarà completamente ribaltata.
La shield così come è oggi si presta poco ad uscire dal recinto degli esempi già forniti, nel mio caso, volevo realizzare un banale server JSON con funzione di autodiscovery (per renderlo plug&play verso un applicazione mobile), ma se non si può gestire il broadcast ne una connessione diretta, il tutto diventa non fattibile. Inoltre essendo disponibile solo l’indirizzamento con DHCP, si realizzano server di cui non si conosce e non si può conoscere l’indirizzo a meno di accedere alla console seriale o giochicchiare con le assegnazioni DHCP fisse del router.
Sicuramente è un prodotto che nasce per soluzioni semplici e veloci da realizzare, ma in questo caso, la scelta di realizzare tutto open-source e non affidarsi ad un controller hardware, ha indirizzato lo sviluppo chiudendo alle reali potenzialità.
Il confronto che faccio è solo in termini di funzionalità, tempo e costo, perché un modulo che offre solo il livello MAC con lo stack uIP al contorno, richiede meno tempo. Poi come già detto, non sono un estimatore dello stack sul 328.
La differenza con il W5100, è che accedendo direttamente al controller ethernet ci sono le API per gestire le connessioni come si preferisce, quindi anche UDP, IP RAW e MAC RAW. Quando si entra nei dettagli di realizzazione, queste funzionalità diventano importanti.
