Ethernet, questo sconosciuto

si, come gia' scritto, ho preso la board dei poveri, che sarebbe anche quella usata nel primo tuo link del post

E' talmente cinese che ha delle gocce di stagno che fanno corto sul minimicrominuscolissimo chip :slight_smile:
devo vedere di toglierle perche' di rispedirla a sinsincity non se ne parla

ruoli coordinativi non ne voglio, ma appena chiudo sto rtc nella sua scatola apposita mi butto sull'ethernet

Testato:
si, come gia' scritto, ho preso la board dei poveri, che sarebbe anche quella usata nel primo tuo link del post

E' talmente cinese che ha delle gocce di stagno che fanno corto sul minimicrominuscolissimo chip :slight_smile:
devo vedere di toglierle perche' di rispedirla a sinsincity non se ne parla

ruoli coordinativi non ne voglio, ma appena chiudo sto rtc nella sua scatola apposita mi butto sull'ethernet

Come preferisci, l'importante è che mi dai una mano, facendo l'interfaccia tecnica, però fai con calma, ora non deve essere una questione di Stato, comincia a postare i primi risultati o problemi e vediamo di riuscire a svegliare qualche svogliatone che sa tutto e che non ne vuole di scrivere qualcosa :wink:

Ok, stasera ho finito la modifica al codice per rtc esterno, domani ultimo tocco per implementare 2 TASTI di selezione e si chiude.

Lavorerò su due direzioni

  • spedire dati verso patchube
  • ricevere comandi da internet

Testato:
Ok, stasera ho finito la modifica al codice per rtc esterno, domani ultimo tocco per implementare 2 TASTI di selezione e si chiude.

Lavorerò su due direzioni

  • spedire dati verso patchube
  • ricevere comandi da internet

OTTIMO XD quando hai tempo prova a vedere quei link che ho postato per vedere se riesci ad affrontare le problematiche esposte che, nel tempo, sono più o meno sempre le stesse, ecco perché mi dispero che nessuno voglia porre fine a questa cosa.

Testato:
E' talmente cinese che ha delle gocce di stagno che fanno corto sul minimicrominuscolissimo chip :slight_smile:
devo vedere di toglierle perche' di rispedirla a sinsincity non se ne parla

:cold_sweat:

leo72:

Testato:
E' talmente cinese che ha delle gocce di stagno che fanno corto sul minimicrominuscolissimo chip :slight_smile:
devo vedere di toglierle perche' di rispedirla a sinsincity non se ne parla

:cold_sweat:

basta un sano spazzolino rigido, credo siano "schizzi di stagno" non gocce di saldatura :slight_smile:

Testato:
E' talmente cinese che ha delle gocce di stagno che fanno corto sul minimicrominuscolissimo chip :slight_smile:
devo vedere di toglierle perche' di rispedirla a sinsincity non se ne parla

Se è sul cip Wiznet eviterei di metterci mano. Questo perchè anche sulla mia ETH Shield ci sono microcorti, ma probabilmente sono pilotati o comunque sulla stessa pista. Ne conto 8-9. Se proprio devi comunque consiglio la calzetta tipo sotto.

Wick.jpg

in quanto menniti mi ha cazziato dall'altra parte scrivo qui XD

io sto anche realizzando una cosa tipo pachube gratuita e senza limitazioni.

per l'occasione acquisto una macchina dedicata (eh già cose in grande XD ).

se volete posso dare una mano per quanto riguarda quella parte, però avrei bisogno di qualcuno che mi aiuti in quanto sono pieno di studio e il tempo scarseggia.

in linea di massima ora sto facendo il sito in PHP per gestire gli utenti, se skaxxo vuole potrei contribuire al suo progetto, poi hostiamo sulla mia macchina con anche applicazioni apposite per le API (così da non far girare tutto sulla porta 80 destinata all'HTTP) (se ti interessa contattami in privato perchè credo che una cosa simile sia più utile di quel che sembra)

riguardo al resto non ho una ETH shield XD quindi per ora sono tagliato fuori mi dispiace

superlol:
in quanto menniti mi ha cazziato dall'altra parte scrivo qui XD

uno stimolo, tutto qui :grin:

io sto anche realizzando una cosa tipo pachube gratuita e senza limitazioni.

per l'occasione acquisto una macchina dedicata (eh già cose in grande XD ).

se volete posso dare una mano per quanto riguarda quella parte, però avrei bisogno di qualcuno che mi aiuti in quanto sono pieno di studio e il tempo scarseggia.

in linea di massima ora sto facendo il sito in PHP per gestire gli utenti, se skaxxo vuole potrei contribuire al suo progetto, poi hostiamo sulla mia macchina con anche applicazioni apposite per le API (così da non far girare tutto sulla porta 80 destinata all'HTTP) (se ti interessa contattami in privato perchè credo che una cosa simile sia più utile di quel che sembra)

riguardo al resto non ho una ETH shield XD quindi per ora sono tagliato fuori mi dispiace

OK, nessun problema, non dobbiamo risolvere il problema della fame nel mondo, anche sarebbe bello :slight_smile:
L'intento per ora è realizzare uno strumento-Guida per tutti coloro che acquistano una ethernet shield e vogliono farci qualcosa; chiunque la usa e si sente di scrivere anche un solo argomento, lo faccia, poi ci penso io a mettere insieme tutto.
Grazie comunque per aver risposto. :slight_smile:

Io mi sento chiamato in causa visto che ho fatto vedere a tutti la mia scheda relè ma devo ammettere che non ci capisco una mazza in merito a linguaggi web; per scrivere una paginetta in php ci ho messo una settimana visto che sono dovuto partire da zero.
Non sono in grado di scrivere dei tutorial, mi dispiace ma se posso essere di aiuto anche solo per testare lo faccio volentieri.
Nel playground ho contribuito a scrivere l'articolo su come ricevere dei dati da pagine php ospitate su server, spero sia di aiuto a qualcuno Arduino Playground - HTMLclient.
Non avendo dimestichezza con linguaggi web quello che scriverei non sarebbe per niente ottimizzato, perciò credo che farei soltanto danni.
Ripeto, non è che non scrivo per mancanza di voglia ma perchè non ho le competenze necessarie; se fossi in grado lo facevo senza battere ciglio visto che sono sempre stato aiutato da tutti.
Se posso aiutare facendo dei test dò la mia totale disponibilità, ho l'ethernet shield ufficiale (prima versione) e quella con chip ENC28J60.
Ciao

Pelletta:
Io mi sento chiamato in causa visto che ho fatto vedere a tutti la mia scheda relè ma devo ammettere che non ci capisco una mazza in merito a linguaggi web; per scrivere una paginetta in php ci ho messo una settimana visto che sono dovuto partire da zero.
Non sono in grado di scrivere dei tutorial, mi dispiace ma se posso essere di aiuto anche solo per testare lo faccio volentieri.
Nel playground ho contribuito a scrivere l'articolo su come ricevere dei dati da pagine php ospitate su server, spero sia di aiuto a qualcuno Arduino Playground - HTMLclient.
Non avendo dimestichezza con linguaggi web quello che scriverei non sarebbe per niente ottimizzato, perciò credo che farei soltanto danni.
Ripeto, non è che non scrivo per mancanza di voglia ma perchè non ho le competenze necessarie; se fossi in grado lo facevo senza battere ciglio visto che sono sempre stato aiutato da tutti.
Se posso aiutare facendo dei test dò la mia totale disponibilità, ho l'ethernet shield ufficiale (prima versione) e quella con chip ENC28J60.
Ciao

Quello è già un bel lavoro, per capirci considera che sto promuovendo qualcosa di cui non capisco un accidente, è solo perché c'è tanta gente che ha sempre difficoltà; Testato si è impegnato ad iniziare delle prove, appena possibile, se gli servono riscontri sa che può contare su di te, ti pare poco? Spero che più di qualcuno che usa regolarmente questo shield si decida a scrivere qualcosa, anche solo come fare una prova iniziale qualsiasi.

è solo perché c'è tanta gente che ha sempre difficoltà

Il difficile secondo me non è far funzionare lo shield, ma quello che viene dopo: una volta collegato il cavo ethernet si dovrà creare un qualcosa per la comunicazione e qui se non si ha esperienza è una bella botta; con solo il linguaggio html si fa ben poco, occorre già pensare ad altri linguaggi di supporto tipo javascript oppure php, ajax ecc... e ovviamente più si vuole fare cose particolari più c'è da studiare... se serve un database occorre imparare anche come funzionano i comandi SQL, se si vuole una grafica più gradevole si può ricorrere all'actionScript di flash o imparare il nuovo html5 e via discorrendo.
Altra cosa importante, è che occorre anche avere un pò di nozioni sul funzionamento della connessione, come aprire le porte sul router, come far vedere lo shield dall'esterno della lan... la strada è in salita (ovviamente i soliti mostri diranno "ebbè che ci vuole" ma per un non addetto ai lavori ogni singola cosa diventa un bel problema da affrontare).

Pelletta:

è solo perché c'è tanta gente che ha sempre difficoltà

Il difficile secondo me non è far funzionare lo shield, ma quello che viene dopo: una volta collegato il cavo ethernet si dovrà creare un qualcosa per la comunicazione e qui se non si ha esperienza è una bella botta; con solo il linguaggio html si fa ben poco, occorre già pensare ad altri linguaggi di supporto tipo javascript oppure php, ajax ecc... e ovviamente più si vuole fare cose particolari più c'è da studiare... se serve un database occorre imparare anche come funzionano i comandi SQL, se si vuole una grafica più gradevole si può ricorrere all'actionScript di flash o imparare il nuovo html5 e via discorrendo.
Altra cosa importante, è che occorre anche avere un pò di nozioni sul funzionamento della connessione, come aprire le porte sul router, come far vedere lo shield dall'esterno della lan... la strada è in salita (ovviamente i soliti mostri diranno "ebbè che ci vuole" ma per un non addetto ai lavori ogni singola cosa diventa un bel problema da affrontare).

Bravo! E' proprio quello che io vorrei risolvere, la problematica iniziale, una volta che si mette in piedi questa allora si possono implementare tutti gli argomenti correlati, bastano esempi banali, ovviamente, poi chiaro che ognuno approfondirà di suo, ma almeno parte da qualcosa; ecco perché è fondamentale l'apporto dei soliti mostri, come li chiami tu :slight_smile:

partiamo con un poco di basi.

Tanto per cominciare, qualsiasi cosa abbia una scheda di rete può essere nominato come HOST.
Un host può essere un server, ovvero attendere pazientamene che qualcuno gli chieda di fare qualcosa per cui è stato programmato (offrire un servizio), oppure essere un client, cioè colui che richiede il servizio.
Esiste anche la terza possibilità, tipica dei sistemi p2p (peer to peer): ovvero essere contemporaneamente un server e un client. Sono reti parecchio complicate, di cui non discuteremo, e normalmente per entrare a farne parte bisogna conoscere almeno un appartenente attivo alla rete, si può cercare a caso, come ci si può collegare ad un server che mantenga un elenco di host attivi.

Il moderno internet come lo conosciamo, si basa su un sistema a "strati" per poter veder efficacemente inviati i dati. Ogni strato rappresenta uno standard: la scelta dello standard utilizzato varia in base alle proprie necessità. Questo standard di strati si chiama ISO/OSI OSI model - Wikipedia, e come possiamo vederlo è composto da ben 7 strati, dal livello fisico (cavo ethernet o antenna wifi) fino al livello applicazione(utente), e comprende decine di standard differenti.
Quindi un dato che parte dall'applicazione, entrerà nel livello sottostante gli verrà aggiunto un'header utile alla gestione della rete per quello specifico livello, e inviato nello strato sottostante, dove l'operazione si ripete fino arrivare al livello fisico, dove il dato viene inserito nella rete.

Un collegamento di computer, può essere definito LAN se ottenuto all'interno di una stanza o palazzo, MAN se ottenuto all'interno di una città, WAN se a livello mondiale. Esistono molte altre definizioni, ma queste sono le più utilizzate. Per esempio, collegare i PC di casa è una LAN, internet è una WAN
Esistono vari metodi pr collegare gli host, con un bus (un cavo che passa da PC a PC, passando per ogni HOST una sola volta), una rete ad anello (come il BUS solo che poi il cavo si colega a se stesso. spesso il cavo è doppio, e i dati "girano" in senso opposto), la tipologia "a stella" (un host centrale, di solito un router, è collegato ad ogni singolo host), infine il sistema mesh, in cui ogni host è collegato ad uno o più host in modo più o meno casuale.

Non è difficile immaginare la forza e debolezza di ogni sistema: la rete a bus, se perde un host, può dividersi in due reti separate. Una ad anello, se perde un host resta "fregata", a meno che non usi un doppio anello, nel qual caso funziona lo stesso con qualche rallentamento. se perde anche un secondo host potrebbe iniziare a dividersi in due sottoreti. Una rete a stella non ha problemi nel perdere un host, a meno che non sia l'host centrale, in quel caso cade tutta la rete. Infine la mesh, se ad esempio ogni host è collgato a tutti gli altri host, è virtualmente indistruttibile.

La nostra rete di casa (LAN) è molto differente dalla vera rete internet, di conseguenza abbiamo bisogno di un "traduttore", un qualcosa che srotoli uno o più livelli (anche tutti!) e li ricrei con le impostazione della nuova rete in cui vogliamo entrare.
Questo viene chiamato GATEWAY. Il nostro modem o router di casa fa da gateway, oltre che un altro paio di chicche che vedremo più avanti.
Una precisazione particolare vale per fastweb, che si tratta di una WAN (ovvero una LAN a livello mondiale, come internet, ma è distaccata da essa, e ci comunica attraverso, appunto i gateway)

Un gateway prende il nome dal livello ISO/OSI di rete in cui lavora:
livello 1 - hub o repeater
livello 2 - switch o bridge
livello 3 - router

Benissimo. Osserviamo ancora una volta l'ISO/OSI:

il livello 2, per funzionare, richiede che ogni host abbia un valore numerico differente: è il MAC adress (se non erro 16 byte). Dati e header, in questo livello, vengono chiamati frame.

il livello 3, per funzionare, richiede che ogni host abbia un secondo valore numerico, che al suo interno però contenga un'indicazione della posizione della rete (nulla a che vedere con la posizione geografica!): questo valore viene detto IP. Esiste una parte non modificabile, che appunto rappresenta la posizione della rete, e una modificabile, che rappresenta ogni singolo host (che poi a sua volta può nascondere più host, come vedremo più avanti). Per capire quale sia la parte modificabile e quella no si usa la maschera di rete.
Attualmente esistono 2 versioni di IP:
l'IPv4, che è quello più utilizzato, composto da 4 byte separati da un punto: es. 192.168.1.10. In questo caso la maschera di rete potrebe essere 255.255.255.0: ciò vuol dire che 192.168.1 rappresenta la posizione della rete, mentre il 10 può essere un numero che rappresenta l'host. Quindi in questo caso la maschera di rete ci limita a "soli" 255 host.

Purtroppo, gli IPv4, che sono solo 4.228.250.600, stanno finendo: quindi si è creato l'IPv6, che con 666.000.000.000.000.000.000.000 indirizzi non dovrebbe avere problemi a breve termine (per breve termine si intende mezzo universo colonizzato da host, e si spera anche qualche umano :slight_smile: ).
l'IPv6 fondamentalmente è come l'IPv4, solo che usa 16byte (e che sono separati dal : invece che dal . e rappresentati in esadecimale), per esempio: fe80::226:18ff:feba:8b6c, e stessa cosa vale per la maschera di rete.

Dati e header, a questo livello, si chiamano "datagrammi", e già inizia a contenere un TTL, ovvero il numero di rimbalzi massimi tra host che il pacchetto può fare prima di venire distrutto (e poi vi lamentate delle poste!). Nel caso, viene creato un messaggio di errore utilizzando il protocollo ICMP (diagnostica di rete), sempre sul livello 3

Ed infine abbiamo il 4 livello, ovvero quello a cui lavora la nostra ethernet SHIELD! i due standard più famosi a questo livello sono il TCP e l'UDP.
voi potrete scegliere quale dei due standard utilizzare, quindi vediamoli subito in dettaglio....
[continuo più tardi]

menniti:

Pelletta:

è solo perché c'è tanta gente che ha sempre difficoltà

Il difficile secondo me non è far funzionare lo shield, ma quello che viene dopo: una volta collegato il cavo ethernet si dovrà creare un qualcosa per la comunicazione e qui se non si ha esperienza è una bella botta; con solo il linguaggio html si fa ben poco, occorre già pensare ad altri linguaggi di supporto tipo javascript oppure php, ajax ecc... e ovviamente più si vuole fare cose particolari più c'è da studiare... se serve un database occorre imparare anche come funzionano i comandi SQL, se si vuole una grafica più gradevole si può ricorrere all'actionScript di flash o imparare il nuovo html5 e via discorrendo.
Altra cosa importante, è che occorre anche avere un pò di nozioni sul funzionamento della connessione, come aprire le porte sul router, come far vedere lo shield dall'esterno della lan... la strada è in salita (ovviamente i soliti mostri diranno "ebbè che ci vuole" ma per un non addetto ai lavori ogni singola cosa diventa un bel problema da affrontare).

Bravo! E' proprio quello che io vorrei risolvere, la problematica iniziale, una volta che si mette in piedi questa allora si possono implementare tutti gli argomenti correlati, bastano esempi banali, ovviamente, poi chiaro che ognuno approfondirà di suo, ma almeno parte da qualcosa; ecco perché è fondamentale l'apporto dei soliti mostri, come li chiami tu :slight_smile:

quando avrò finito capirete perchè è così difficile: l'ethernet implementa fino al 4 livello, voi volete utilizzare javascript e simili, che se fossero rappresentati nell'ISO/OSI rappresenterebbero qualcosa tipo il 10 livello.... ed ogni livello diviene via via più complesso, perchè deve mettere a disposizione funzioni sempre più complesse. Insomma, esiste un limite al nostro povero arduino, e anche alla voglia di un programmatore... Inutile fare una libreria PHP quando le stese cose le puoi fare direttamente in C(sempre usando le librerie, ma in C!)
Poi ve la immaginereste la gente che chiede come mai arduino va in time out quando cerca di creare una immagine dinamica o chissà cosa...

forse con la 2 sarete accontentati

Bellissimi interventi lesto! OK, non dobbiamo risolvere l'impossibile ma spiegare il possibile, ed il tuo intervento va nella giusta direzione, quando avremo sufficiente materiale metteremo in piedi un bel lavoro di gruppo per la Comunità. Grazie!

IL TCP e l'UDP

a questo livello i dati + header vengono chiamati pacchetti nel TCP e datagrammi nell'UDP.

benissimo, finora abbiamo visto come creare un collegamento tra due o più PC, per distinguere le comunicazioni possiamo usare l'IP, oppure un livello aggiuntivo implementato da noi. Ma che succede se uno stesso host vuole collegarsi più volte allo stesso server? in questo caso il nostro programma dovrà implementare un livello per distinguere le differenti connessioni. Ma che succede se il server offre due servizi differenti, ovvero i programmi lato server che accettano connessioni sono 2 o più? Se la distinzione fosse fatta a livello applicativo (ovvero del programma) un bel macello, dato che entrambi i programmi dovrebbero comunicarsi a vicenda per capire a CHI è diretto il messaggio in arrivo. In oltre ho accennato a come un datagramma, o un frame, potrebbe non raggiungere a destinazione, o arrivarci danneggiato, oppure arrivare in disordine: in reti complesse è possibile che i messaggi compiano strade (route) differenti per arrivare a destinazione, e quindi un messaggio inviato DOPO potrebbe arrivare prima del precedente.

Parte di queste problematiche sono già state risolte; a questo livello vengono implementate le porte. Esse sono semplicemente un numero da 0 a 65536: un host viene identificato a partire dal suo IP, la porta che utilizza per inviarci i messaggi, e la nostra porta a cui sono indirizzati i messaggi.

Viene anche implementato l'MTU: ovvero la dimensione massima di un pacchetto o datagramma. Un messaggio che superi questa dimensione, viene frammentato(ovvero suddiviso) in messaggi più piccoli. Questo crea qualche problema nell'uso dell'UDP nella ricostruzione del messaggio

Partiamo dall'UDP, essendo molto più grezzo rispetto al TCP
l'UDP non crea una connessione persistente, ovvero si dice connection-less. Ciò vuol dire che ogni pacchetto inviato è come se fosse una connessione a se. Ogni pacchetto viene inviato tramite una porta a caso su una ben specifica porta del ricevente.
Servono quindi 2 porte: una che viene usata per scrivere il messaggio (outbound) dal client, e una usata per leggerlo (inbound) dal server

Quindi per rispondere, l'ex-ricevente deve sapere la porta aperta nell'ex-trasmittente a cui inviare i dati. In totale servono 4 porte aperte, 2 per host.
Da notare che le porte outbound vengono aperte solo per il tempo necessario all'invio del messaggio, e poi vengono richiuse, mentre le inbound sono sempre aperte in ascolto di messaggi in arrivo.

Se osserviamo un firewall, questo si occupa proprio di bloccare le porte, di solito quelle inbound. Anche la NAT svolge indirettamente questa funzione e va settata, dicendo che i messaggi UDP in arrivo sulla determinata porta vanno ritrasmessi all'host che è in ascolto. Ma vedermo quesa NAT più in particolare dopo.

Vantaggi dell'UDP:
è leggero. Non implementa controlli nè header grossi, quindi occupa poca banda e i messaggi sono elaborati in fretta.
Svantaggi:
Non controlla che i messaggi arrivino a destinazione
Non è detto che controlli l'integrità del datagramma ricevuto, se lo fa e risulta il datagramma errato, viene eliminato come se non fosse mai arrivato a destinazione
Non controlla l'odine di arrivo dei messaggi, dato che essendo connection-less da per scontato che questo controllo non serva
Non fa il controllo di congestione, ovvero non cambia strada (route) se il percorso risulta lento o inaffidabile

Passiamo al TCP:
è molto differente, perchè crea una vera e propria comunicazione a due vie, ovvero una connessione.
Un host che si connette con porta outbound a un server, utilizzerà la porta oubound sia per inviare che per ricevere: ciò vuol dire che usando il TCP, il client per ricevere dati NON ha bisogno che venga toccato il firewall, o la NAT.
Quindi perchè entrambi gli host cominichino bastano 3 porte: una da parte del client per scrivere e ricevere, e 2 da parte del server, una inbound per ricevere e una oubopund per scrivere.

Vantaggi del TCP
Si accorge se un pacchetto è mancante o danneggiato
richiede la ri-trasmissione di un pacchetto se risulta mancante o danneggiato
ordina i pacchetti ricevuti per ordine di invio
Svantaggi del TCP
è pesante, tutti questi controlli, i timeout per le ricezioni dei pacchetti, la necessità di aspettare che un pacchetto precedente arrivi prima di rendere disponibili al socket anche quelli successivi, creano dei grossi ritardi, oltre che un peso aggiuntivo degli header (più del doppio dell'UDP), computazionale per i controlli, e della rete con tutti i messaggi di controllo.

[pausa cena]

Grande lesto!!! goditi la cena in pace, quanto stai scrivendo merita già di diventare subito la parte introduttiva teorica della guida, in pratica il Capitolo 1; quando finisci avvisami che mi metto al lavoro XD

Ottimo lesto, come sempre, pero' io direi di metterla come allegato alla fine, mettendolo come introduzione la gente si "appaura"

io sono piu' per partire con il caro blink, ma fatto online, in entrambe le direzioni.

Cioe' nel primo esempio spediamo a patchube il nostro bel segnale che blinckera' una bella onda quadra sul grafico.ù
Nel secondo esempio andiamo al contrario, e cioe' con un bel pc su internet facciamo accendere il nostro bel led13 in blink

Gia' questo che sembra banale affronta il tutto

Ora capite perchè ho scritto "mostri" :slight_smile:
Bravo lesto, davvero complimenti per cotanta saggezza