Esperimenti con W5500

aggiornato il 7 Mar 2017- Finito !
Dopo aver progettato alcuni dispositivi con i modulini WiFi basati sul componente ESP8266, ho deciso di passare in modalità “wired”, perché mi hanno fatto notare che molte persone spengono la sezione WiFi del modem / router quando non serve loro per “navigare” e quindi gli eventuali dispositivi di domotica basati su wireless diventano inutilizzabili !

A questo punto, ho deciso di realizzare una versione dei miei dispositivi anche su wired LAN e ho quindi cercato un componente adatto. Ci sono diverse opzioni, ma dopo alcune considerazioni su costi e reperibilità ho deciso di puntare sul chip W5500.

Il sito del produttore mette a disposizione una vasta e accurata documentazione, sia per l’hardware che per il software. Ci sono librerie software aggiornate e molti esempi relativi alla gestione dei vari protocolli, ma (come sempre) io ho deciso di studiare il datasheet del componente e scrivere i miei programmi di test a partire da zero.

Per cominciare a fare delle prove pratiche, ho comprato on-line un modulino che ospita il componente, con il minimo essenziale di hardware per la connessione al microcontrollore esterno e alla rete LAN.

A destra il modulo collegato con un flat-cable al micro; a sinistra il dettaglio del pinout

Purtroppo, non ho potuto riutilizzare nulla del software scritto per i moduli ESP-01, ESP-07 eccetera, perché il W5500 ha un’architettura e una modalità di pilotaggio completamente diversi. Intanto, dal punto di vista hardware, la connessione avviene tramite SPI (quindi una seriale sincrona) e non tramite UART ; poi, lo stack TCP embedded richiede una programmazione a un livello più basso, una gestione dei “socket” un po’ più complessa.

Per questa prima parte dell’esperimento ho riciclato una mia vecchia scheda, basata sul microcontrollore Atmel ATmega88, che avevo realizzato in passato per pilotare il noto ENC28J60 della Microchip. Dato che anche quel chip si pilotava tramite SPI, ho rimosso l’integrato (che era in versione DIP e montato su zoccolo) e ho collegato i vari segnali della seriale sincrona al connettore del modulino W5500. Ho così potuto riutilizzare anche la parte di software che gestiva la comunicazione SPI. Il circuito di prova si presenta così :

Il primo prototipo: scheda con micro ATmega88, modulo W5500 e interfaccia USB-TTL per il debug del programma.

Lo schema elettrico della scheda a microcontrollore, modificato e semplificato dalla versione originale con il chip ENC28J60, è questo:

Per una visione più dettagliata, è possibile prelevare il file in formato PDF da questo link.

Come si vede dalla nota sullo schema, al momento attuale le linee di I/O del micro che non sono state utilizzate sono “floating”, in attesa di definire un hardware aggiuntivo, ma a progetto finito ogni linea non usata deve essere opportunamente collegata ad un riferimento. Tipicamente, dato che il micro al reset pone tutto l’I/O in condizioni di Input (alta impedenza), è possibile collegare tra loro tutti i pin inutilizzati ed usare una resistenza sola per collegarli tutti a GND. Ovviamente, nella fase di inizializzazione delle linee di I/O del firmware, bisogna tenere conto di questa soluzione circuitale.

Breve descrizione del componente

L’integrato mette a disposizione del progettista un completo stack TCP, con 8 sockets indipendenti e un’area di memoria RAM dedicata. Il controllo del funzionamento avviene scrivendo o leggendo alcuni registri e aree di memoria tramite interfaccia seriale sincrona SPI. I blocchi di memoria sono tre:

Common Register Block, dove troviamo i registri di controllo
Socket Register Block, dove troviamo i registri relativi agli 8 Sockets
Memory, dove troviamo i buffers di lettura / scrittura degli 8 Sockets

La seriale SPI può essere usata in modo da leggere / scrivere una quantità fissa (1,2,4 bytes – FDM) o variabile (n Bytes – VDM) di dati. Per utilizzare quest’ultima modalità, è necessario pilotare la linea /CS (Chip Select) per informare il chip dell’inizio e fine di uno stream di dati. Nel mio progetto ho usato esclusivamente questa modalità. Uno stream di scrittura / lettura è costituito da tre fasi: Address Phase, Control Phase, Data Phase.

Nella Address Phase vengono inviati 2 bytes che costituiscono l’indirizzo di offset rispetto all’origine del blocco di memoria selezionato ; nella Control Phase viene inviato un singolo byte che indica il blocco di memoria che si vuole selezionare, il modo RD / WR e la modalità FDM / VDM ;   infine, nella Data Phase vengono scritti o letti i dati (quindi, in caso di modo VDM questa fase ha un numero variabile di bytes).

Per poter effettuare una qualsiasi operazione è necessario inizializzare alcuni registri principali. Al reset il chip assegna dei valori di default ; molti di questi non avranno bisogno di essere modificati, perché sono i più adatti ad un funzionamento normale. Per esempio, i registri che determinano la quantità di memoria RAM assegnata agli 8 sockets vengono inizializzati con il valore di 2K Bytes. Così facendo, avremo lo spazio di memoria uniformemente distribuito tra gli 8 sockets, per un totale di 16K Bytes in scrittura e altrettanti in lettura. Naturalmente lo spazio di memoria può essere distribuito in modo differente, purché si rispetti la quantità massima di RAM disponibile che è, appunto, di 16K Bytes per i buffers di TX e 16K Bytes per quelli di RX.

L’accendiamo ? Sì, l’accendiamo !

Bene, il circuito c’è, partiamo con il primo step: colleghiamo il nostro dispositivo alla LAN e proviamo a vedere se risponde al “ping”. Come al solito, non ho utilizzato “librerie precotte”, ma ho scritto il programma a partire dallo studio di ciò che mi serve, riflettendo bene sul minimo indispensabile per raggiungere lo scopo. Non mi piace l’approccio che (purtroppo) ha preso piede negli ultimi anni, cioè quello di fare strutture di software immense e poi definirle “scalabili”. Questo “scalabile” spesso significa che se a me serve solo una minima parte, devo prendere un grosso blocco e poi togliere quello che è in eccesso. Nella mia lunga esperienza ho potuto appurare che si fa molto prima a scrivere da zero l’essenziale che non a togliere il 90% dell’inutile ; è come costruire una  tazzina da caffè partendo da un blocco di marmo di due metri di lato, con grande fatica di scalpello e martello. Io, preferisco usare una “stampante 3D” e creare ciò che mi serve usando solo il materiale necessario.

Il nostro dispositivo si collega ad una rete LAN, tipicamente fornita dal modem / router che ci connette al provider. Teniamo presente che il chip w5500 non ha protocolli già pronti, ma ci mette a disposizione alcuni sockets TCP / UDP e poi… il protocollo lo dobbiamo scrivere noi ! Dunque, non c’è un DHCP pronto all’uso e quindi programmeremo nei registri interni del chip un IP statico, che sarà quello che poi proveremo a “pingare”. Un altro importantissimo dato da scrivere nei registri è l’indirizzo fisico del nostro dispositivo, comunemente chiamato MAC address. Il MAC address è costituito da 6 bytes; i primi tre identificano il produttore dell’hardware ed i secondi tre sono a discrezione del produttore, che li codifica nel modo che più gli aggrada, mantenendo però l’univocità della terzina. Particolarmente importante è il primo byte della prima terzina e in particolare, di questo, il secondo bit meno significativo. Questo bit, infatti, determina se il MAC address è OUI (Organizationally Unique Identifier) oppure se è “locally administered”. In pratica, se il primo byte del MAC è xxxxxx1x, il dispositivo non appartiene ad una delle industrie registrate come produttori, ma è amministrato localmente. L’ultimo bit (il meno significativo) del primo byte determina se la connessione è multicast o unicast. Noi useremo solo unicast e quindi questo bit sarà sempre a zero.

Un trucco per creare un indirizzo fisico OUI, che ho visto usare nei tablets cinesi “very cheap” di prima generazione (nel 2011), è quello di utilizzare come MAC del tablet quello del router a cui ci si collega, modificando l’ultimo byte di +1 o -1. Ingegnoso, ma non si dovrebbe fare ! Se volete sapere qual è il MAC del vostro router e usare lo stesso trucco, potete usare il comando ARP da finestra DOS di Windows.

Questo comando chiede al sistema di restituire il MAC address (attraverso il protocollo ARP) del dispositivo che ha IP 192.168.1.1 (tipicamente il router di casa). Gli altri due dati essenziali da programmare nei registri del W5500 saranno l’IP del Gateway (il nostro modem / router) e la Network Mask. Tutti questi dati risiedono nella memoria flash del micro ATmega88, allocati in modo statico con questa assegnazione:

Come si vede in figura, alla locazione 0x0EC0 troviamo 64 bytes di memoria flash riservati ai dati per la personalizzazione del dispositivo. Si noti che c’è un solo byte definito nel sorgente in ‘C‘ ! Questo serve unicamente a far generare dal compilatore una linea nel file di uscita raslan.hex con il riferimento all’indirizzo 0x0EC0. Poi, sarà un’applicazione su PC ad aggiungere al file .hex i dati personalizzati. Ecco come si presenta la schermata iniziale di tale applicazione:

Nella finestra in alto a destra potremo scrivere, un dato per riga, i valori corretti per personalizzare il nostro dispositivo in funzione della rete a cui dovremo collegarlo. Il programma, quando si clicca il pulsante [ Modify HEX file ], genera un nuovo file chiamato raslan-mf.hex che contiene, nell’area flash dedicata, i parametri personalizzati. A questo punto potremo usare tale file per effettuare la programmazione del microcontrollore.

In questa prima versione di programma, il micro invia su porta seriale (9600, N,8,1) i parametri letti dalla propria memoria flash. Dopo aver trasmesso ogni messaggio,  il micro scrive i medesimi dati nei relativi registri del w5500 e quindi resta in attesa di comandi da seriale o di richieste ICMP Ping.

Come si vede nel listato, la prima operazione che viene effettuata sui registri è la lettura della versione del chip. Il w5500 risponde con il valore 04. Questa lettura è utile anche per verificare che le routines di lettura/scrittura tramite SPI siano efficaci. Di seguito, troviamo la scrittura dei vari parametri di cui abbiamo parlato.

Colleghiamo ora un convertitore USB-Seriale al circuito e lanciamo un programma di terminale seriale. Nel file zip messo a disposizione per il download troverete anche un mio piccolo programma di terminale, che potrete utilizzare per visualizzare l’output del micro e per inviare comandi. In questa primissima release del software, l’unico comando accettato da seriale è il carattere ‘+’ che provoca un reset da watchdog del micro, facendo quindi ripetere la procedura di inizializzazione. Ecco cosa leggiamo sulla finestra del terminale:

A questo punto vedremo il led rosso del circuito mandare un piccolo lampeggio ogni 3 secondi, segno che tutto gira regolarmente. Dall’immagine precedente vediamo che il Device IP è settato a 192.168.0.123 e quindi proviamo a fare un ping da un computer collegato sulla stessa sottorete. Il risultato sarà questo:

BENE ! Il circuito risponde al Ping ! Il primo passo è fatto ! I registri sono stati inizializzati correttamente. Possiamo ora, per prova, lanciare di nuovo il programma w5500prog.exe per modificare i parametri e riprogrammare il micro con un altro Device IP. Quindi, possiamo provare a “pingare” il nuovo IP e vedere se ci risponde (lo farà).

Nota importante: quando si programma la memoria flash del micro, si devono anche settare i “fuses” secondo questa configurazione: Hfuse: 0xCD Lfuse: 0xFC Efuse: 0xF9.

Nel file w5500-v1.zip messo a disposizione per il download troverete questi elementi:
miterm.exe – il terminale seriale
raslan.hex – il file hex di base, senza parametri
raslan-mf.hex – il file hex con i parametri, da usare per programmare il micro
w5500prog.exe – l’applicazione per modificare i parametri

La prova del Socket

Finita questa primissima prova, cominciamo la seconda e ultima parte dell’esperimento: la prova di un “socket” TCP. Per dare un po’ di flessibilità al programma, ho aggiunto una serie di comandi che possono essere inviati da porta seriale. Il primo di questi permette di inserire un IP al quale ci si vuole collegare. Da seriale scriveremo ” i ” e comparirà un ” ? “, quindi scriveremo l’ IP che ci interessa. Dato che ancora non abbiamo programmato un client DNS sul micro, useremo un terminale cmd di Windows e il comando nslookup per ottenere l’ IP del server a cui collegarci. Ecco un esempio:

Con questo nslookup chiediamo al server DNS 8.8.8.8 (quello di Google) l’attuale IP del sito robotop.eu5.org, che è un mio sito di test ospitato su uno spazio web gratuito.

Un altro comando da seriale permette di settare la Porta a cui ci si vuole collegare. Sul terminale seriale scriveremo ” p ” e verrà mostrato il carattere ” ? ” e quindi inseriremo il numero della Porta, in questo caso 80 perché vogliamo collegarci a un server web che ci restituirà una pagina HTML.

Vediamo ora il comando che ci permette di selezionare il percorso della pagina a cui vogliamo accedere, sul sito di cui abbiamo ottenuto l’ IP . Sul terminale seriale scriveremo ” s ” e riceveremo il solito ” ? ” e a questo punto scriveremo il percorso, ad esempio: /php/ipget.php. La lunghezza massima accettata per la stringa, come in tutti gli altri comandi, è di 31 caratteri.

Ora abbiamo il comando per inserire l’URL del sito. Scriveremo da terminale seriale ” u ” e ci verrà mostrato il solito ” ? ” ; a questo punto, inseriremo la stringa, per esempio robotop.eu5.org. Qualcuno si chiederà perché inseriamo l’URL del sito, dato che ne abbiamo già ricavato l’IP con nslookup. La ragione è che lo stesso host contiene molti siti (è un hosting gratuito) e quindi nella richiesta GET HTTP che faremo, dovremo aggiungere il campo “Host: ” che specificherà a quale sito vogliamo accedere, sul server che gira a quell’indirizzo IP.

L’ultimo comando che possiamo dare da seriale è: ” g “. Questo comando avvia una richiesta GET HTTP con i parametri impostati da seriale e quelli programmati nella flash. I dati ricevuti (se la richiesta va a buon fine) sono limitati a 255 bytes. Gli eventuali dati in eccesso vengono troncati.

Vediamo un esempio sul terminale seriale:

Ho utilizzato il comando ctrl-r del terminale seriale per registrare tutta la procedura, a partire dal reset del circuito effettuato inviando il carattere ” + “. Eccolo di seguito:

> Boot
> Chip version: 04
> Device MAC: 02-00-00-00-00-01
> Device IP: 192.168.0.100
> Gateway IP: 192.168.0.1
> Network Mask: 255.255.255.0

> i ? 5.9.82.16 err: editing not allowed !
> i ? 5.9.82.18
> Destination IP: 5.9.82.18
> p ? 80
> Destination PORT: 80
> s ? /php/ipget.php
> Server's path: /php/ipget.php
> u ? robotop.eu5.org
> Server's URL: robotop.eu5.org
> g
# socket open; src port:1326
# socket initialized OK
# connect socket to server...
# [3] status=15
# socket connected
# sending data...
# data received on socket - bytes:00AD
HTTP/1.1 200 OK
Date: Tue, 07 Mar 2017 16:33:20 GMT
Server: Apache
X-Powered-By: PHP/5.4.17
Content-Length: 11
Connection: close
Content-Type: text/html

5.170.76.79
# closing socket...
# closed
>

Ecco cosa abbiamo fatto: ci siamo connessi a http://robotop.eu5.org/php/ipget.php ed abbiamo ricevuto una risposta. La risposta è… il nostro IP pubblico, quello con il quale il nostro router viene visto dalla rete. Il contenuto del file ipget.php è veramente minimale.. eccolo qui: <?php echo $_SERVER[REMOTE_ADDR]; ?> .

L’esperimento è concluso. Nel nuovo file w5500-v2.zip troverete i programmi aggiornati.

Nel prossimo articolo descriverò un’applicazione pratica di quanto sperimentato fin qui. Sarà un relè che potremo accendere / spegnere via Internet, usando come comando remoto un qualsiasi dispositivo mobile provvisto di connessione ad internet (con il browser di serie). Non dovremo abilitare particolari porte sul modem / router e potremo usare anche un router 3G/4G (come quello che sto usando adesso) che non ha un IP pubblico (fa parte di una sottorete del provider). Noi riusciremo ugualmente a comandare il nostro relè (con qualche minuto di latenza), grazie a un paio di scripts PHP che scriveremo su un hosting gratuito qualsiasi, dopo aver fatto la nostra registrazione.

Provare per credere ! Arrivederci…

Clausola di non assunzione di responsabilità:
Il programma o software descritto, liberamente prelevabile dal sito, è da considerarsi una “demo” gratuita e pertanto l’autore Emilio P.G. Ficara non fornirà alcun supporto, né si assumerà alcuna responsabilità per ogni eventuale problema, danno o conseguenza che dovesse presentarsi nel download o nell’esecuzione dell’applicazione.
Cliccando questo link per effettuare il download del file implicitamente dichiarate di aver letto e capito la clausola di non assunzione di responsabilità e di accettarla.

Verificate il checksum MD5 del file w5500-v2.zip scaricato ! Questo deve essere: E71F4C2707932F8A2EBCC8C5815D109B ; se è diverso, il file è corrotto o non è quello originale. In questo caso, non scompattatelo e buttatelo via ! Se invece è tutto ok, potete scompattarlo (è richiesta una password che è: eficara). Potete usare i programmi anche su una chiavetta di memoria USB, in quanto non hanno bisogno di installazione, essendo eseguibili puri.