Controllo tapparelle con modulo Bluegiga WF121 e comando wifi tramite un apparecchio Android

Controllo tapparelle con modulo Bluegiga WF121 e comando WIFI tramite un apparecchio Android

Questa applicazione ha lo scopo di valutare la semplicità d’uso del modulo Bluegiga WF121, stimare le prestazioni e dare una personale valutazione.

Il modulo WF121 è provvisto di una radio 2.4GHz 802.11b/g/n integrata, uno stack TCP/IP e un micro controllore 32 bit.

Permette la realizzazione di applicazioni embedded utilizzando degli script molto simili a quelli utilizzati per la versione bluetooth BLE112. Le risorse interne sono più che sufficienti e permettono la realizzazione di molte applicazioni senza l’aggiunta di una CPU esterna, è realizzato per  ottimizzare costi e consumi, anche se è il progettista che deve fare attenzione all’uso oculato per condividere i canali di comunicazione e ridurre i consumi solo ai momenti indispensabili.

Le caratteristiche complete del prodotto si trovano sul sito https://www.bluegiga.com/en-US/products/wf121-wifi-module/. Quello che voglio verificare è l’efficacia degli script e poter valutare i consumi reali del modulo indipendentemente dal kit di valutazione in varie modalità lavoro.

L’applicazione

L'obiettivo è quello di pilotare delle uscite digitali tramite un collegamento wifi con server (WF121) e client TCP/IP (Tablet).

Per la realizzazione ho utilizzato il kit di valutazione Bluegiga DKWF121 fornito con tutto il necessario (cavi di connessione, modulo PICkit^tm3, modulo WF121 stand-alone), tutto il sw è scaricabile dal sito  https://wwwbluegiga.com dopo la registrazione e il login.

Oltre alla documentazione, al programma “wifigui.exe” che permette di creare il codice da scaricare nel modulo, sono forniti anche: il programma di editing “notepad++.exe” scaricabile gratuitamente e “PICkit3.exe” anch’esso scaricabile dal sito “bluegiga" per il download sul modulo “WF121”. Nel mio caso ho utilizzato come editor il programma “vs.exe” della “SlickEdit” (non è gratuito, ma è possibile avere un trial al sito https://www.slickedit.com ). Per il download utilizzo invece “ipe.jar” che è reperibile insieme a “mplab” della “microchip” da https://www.microchip.com.  

Ho diviso il lavoro in 3 fasi:

1. Prova del processo di creazione del programma da scaricare nel modulo.
2. Realizzazione dello script per la gestione dello stack IP e delle uscite digitali.
3. Realizzazione di un applicazione Android per il controllo del modulo wf121.

Il risultato mi ha soddisfatto perché, pur non avendo mai utilizzato gli strumenti Bluegiga sono riuscito, con la documentazione e gli esempi forniti a realizzare un applicazione con la quale poter studiare il modo migliore per gestire il modulo wifi allo scopo di ottenere il minor consumo possibile. Il costo, che si attesta intorno alle 15€ è accettabile se inserito nei giusti contesti di automazione (remote control, monitoring e supervisor).

Da sottolineare che il modulo oltre a operare in una rete WIFI già esistente è in grado di lavorare come access point, e come HTTP server anche se in modalità limitata. In pratica se non c'è una rete WIFI se ne può creare una, e volendo l'accesso può avvenire con un normale browser.
Questa è solo una delle applicazioni possibili del modulo, ma la mia curiosità è rivolta all'uso della connessioni WIFI nell'ambito dell'automazione.

Per la descrizione delle 3 fasi sopra elencati rimando ai relativi post.

Prova del processo di realizzazione di un’applicazione con script BLUEGIGA per WF121.

Dopo avere scaricato e installato tutto il sw dal sito https://www.bluegiga.com/en-US/products/wf121-wifi-module/ , utilizzo uno degli esempi forniti insieme al kit di valutazione, lo compilo e lo scarico nel modulo della scheda di valutazione in modo da verificare e capire il processo di realizzazione di un’applicazione.

1. Collego tramite il cavo USB la scheda di valutazione al computer. Individuo l’area contrassegnata con USB to UART CONVERTER e inserisco qui il connettore micro usb, assicurandomi che i 2 switch (UART1 e UART2) siano in posizione ON. La scheda è alimentata e il PC riconosce la presenza di un nuovo HW identificato come porta di comunicazione.

2. Avvio il programma wifigui.exe, nella pagina che compare clicco il pulsante “Refresch” in modo che siano visualizzate tutte le porte di comunicazione disponibili. Le immagini non sono leggibili, ma ho evidenziato la posizione dei comandi sullo schermo cerchiando le parole che in questo testo sono in grassetto.

Evitando la “COM1” scelgo a caso una delle porte aggiunte. Selezionandone una, compare il pulsante “Attach”, ciccandolo il pulsante diventa “Detach” e sulla barra superiore compare l’indicazione della porta selezionata con la sua velocità di connessione. Non utilizzando la comunicazione per la gestione del programma, la connessione USB serve solo per abilitare il compilatore dello script.

3. Dal menù “Firmware update” che si trova sulla sinistra dello schermo, seleziono il programma da caricare sulla scheda  DKWIFI121.
Clicco il pulsante “Open project” compare la finestra dove è possibile scorrere tra gli archivi del PC.
Avendo utilizzando un'installazione standard, nell’archivio “C:/BLuegiga/wf121-1.2.2-63/example/“ si trovano gli archivi di tutti gli  esempi. Scelgo “bgscript_leds” dove c’è il file "project.xml" da caricare. Adesso nei box: "Project file", "Hardware file", "Script file" sono comparsi i file relativi al progetto.

4. Clicco sul pulsante “Build” e lo script è compilato creando l'eseguibile "wifi.hex" nello stesso archivio del progetto.

5. Per caricare il file nella scheda di valutazione collego il “PICkit3” al connettore “J11” che si trova sulla sinistra della scheda di valutazione. 

Avvio il programma “ipe.jar” e compare la pagina dove è possibile scegliere il micro processore dal box “Device” in alto a sinistra (PIC32MX695F512H), clicco sul pulsante “Connect” che diventerà “Disconnect”. Carico il programma cliccando sul pulsante “Browse”, lato destro della pagina all’altezza del box “Source”. Anche in questo caso compare la pagina di navigazione che permette di selezionare il file “wifi.hex” dal path “C:/BLuegiga/wf121-1.2.2-63/example/bgscript_leds”. Nella finestra “Output” compaiono i risultati delle operazioni.

6. Clicco sul pulsante “Program” che avvia il processo di download verso la scheda, i vari passi del processo sono indicati sempre nella finestra “Output”. 

Al termine quando nella finestra "Output" compare la scritta “Programming complete”, l’applicazione si avvia automaticamente e i 4 leds della scheda lampeggiano. 

La procedura mi sembra molto semplice (solo 6 passaggi) e anche provando ad inserire degli errori nello script, il compilatore gli ha segnalati indicandoli in modo chiaro e semplice per la loro individuazione.

Lo script per WF121 la gestione dello stack IP e il controllo delle uscite digitali

Si tratta di uno script inserito nel modulo WF121 della bluagiga che si colloca in un sistema composto da un end-point di una rete WIFI, tipicamente una rete domestica utilizzata per la connessione ad internet e un applicazione su un apparecchio “android”, io ho utilizzato un NEXUS 7 con lollipop 5.0. Nel sistema il modulo “bluegiga WF121” ha la funzione di SERVER, mentre l’apparecchio android ha la funzione di CLIENT.

Partendo dal progetto di esempio “bgscript_leds” usato nel post "Prova del processo di realizzazione di un’applicazione con script BLUEGIGA per WF121" ho modificato il pilotaggio delle uscite in modo da poter gestire 2 carichi, in questo caso simulati dai leds che verranno attivati dai comandi dati attraverso il tablet.

I comandi sono 3: ALZA, ABBASSA, STOP, di cui alza e abbassa sono temporizzati in modo da dare alla tapparella il tempo di completare l’operazione. Il comando STOP ferma l’azione in corso se si desidera una parziale apertura o chiusura.

Il progetto BLUEGIGA

Per ogni progetto sono necessari 3 file: project, hardware e lo script. 

I primi 2 files sono scritti in linguaggio “.xml”, mentre il terzo è un file di testo con estensione “.bgs”. 

Per il mio script ho utilizzato gli stessi 2 file dell’esempio "bgscript_leds" descritto nel post precedente.

Per il nuovo progetto ho creato l’archivio “WiFi-Script-getCommand”.

Nel file “project.xml” ho rinominato il file di script “wifi.bgs” in “WiFiScriptGC.bgs” ho aggiunto il percorso dove si trovano le API per lo script con la riga api=“../../api/wifiapi.xml”, definito il software input file per il compilatore con la riga “../../api/wifiapi.xml”, il file di boot con la riga “../../fw/boot.juo” e rinominato anche i file di output “.dfu” e .”hex”.

Il file "project.xml" modificato

<?xml version="1.0" encoding="UTF-8" ?>
<project>
    <hardware in="hardware.xml" />    <scripting>
        <script in="WiFiScriptGC.bgs" api="../../api/wifiapi.xml" />    </scripting>
    <software>
        <binary in="../../fw/wifi.juo" />    </software>
<image out="WiFiScriptGC.dfu" out_hex="WiFfScriptGC.hex" /> <bootloader in="../../fw/boot.juo" /> </project>

Nel file “hradware.xml.” non ho dovuto cambiare niente.

<?xml version="1.0" encoding="UTF-8" ?>
<hardware>
  <port channel= "1" latch= "0x20" tristate= "0xFFFF"/>    <uart channel="0" baud="115200" api="false" andshake="false" />  <uart channel="1" baud="115200" api="false" andshake="false" /></hardware>

LO SCRIPT

In questo file ho aggiunto le API per la gestione dello stack IP, ho modificato la gestione del timer e la gestione delle porte di I/O . 

Per fare le modifiche è necessario utilizzare un programma di editing, “notepad++” è scaricabile dal sito "https://notepad-plus-plus.org" o da quello della Bluegiga, nel mio caso ho utilizzato “vs.exe” della "SlikEdit" e caricato lo script rinominato “WiFiScriptGC.bgs”. Lo script utilizza il carattere “#” per indicare i commenti mentre il linguaggio  mi ricorda molto il thiny basic.

In testa al file ci sono le dichiarazioni delle variabili e l’impostazione delle costanti. MODE_AP ha la funzione di indicare il ruolo del modulo all’interno della rete di comunicazione nel mio caso “STATION”

La prima funzione da utilizzare è “system_boot" che è di tipo evento e permette di aspettare che il modulo sia stato inizializzato completamente.

La funzione di seguito è chiamata dal firmware del modulo dopo che la connessione wifi è stata effettuata. Nella funzione ho connesso l’apparecchio alla rete indicata nel SSID buffer.

Se l’operazione precedente ha esito positivo il firmware chiama la funzione di seguito, dove ho segnalato lo stato di "connesso" nel flag “connected”, acceso un led di operazione conclusa e avviato il server IP. 

I due eventi successivi sono legati all’operatività dello stack ip. 
Il primo è riferito proprio alla funzione server, il secondo al canale di comunicazione che nello script è identificato come end-point. 
In entrambe le funzioni è restituito il primo valore come canale di connessione da utilizzare per la gestione della comunicazione. 

La ricezione di questi eventi indica che la connessione è attiva e quindi si accenderanno 2 leds per indicare lo stato dell’apparecchio.

L'evento generato dal timer interviene ogni secondo e qui è  utilizzato per determinare il tempo di accensione dei leds che sono i comandi per l’azionamento.

L’ultima funzione è quella che ricevuto un messaggio lo interpreta ed avvia il comando.

Download

La procedura da seguire è quella già vista nel post "Prova del processo di realizzazione di un’applicazione con script BLUEGIGA per WF121".  Una volta salvato il nuovo file, va compilato tramite il programma wifigui.exe, va scaricato nel modulo con il programma “pie.iar” e lo script si avvierà immediatamente con i leds che si accenderanno indicando gli stati dell’apparecchio. 
Per una prima prova ho utilizzato “Telnet” digitano dalla riga di comando “telnet 192.168.0.1 8080” , una vola ottenuta la connessione ho inviato i comandi “led1”, “led2” e “led5” per alzare, abbassare e fermare il tempo di accensione. ovviamente ad ogni led  è associato un relè che esegue materialmente la chiusura del contatto per il pilotaggio del motore della tapparella. Ogni comando ha una durata di 30” come indicato nello script, nel caso si voglia fermare l’operazione prima basta inviare il comando di stop.

Anche in questo caso non ho trovato particolari difficoltà, le API messe a disposizione dalla Bluagiga sono molte e forse il problema più grosso è quello di doversele studiare per individuare quelle più adatte alle necessità. Partendo da questo esempio dovrò individuare la modalità più economica per la gestione della connessione sfruttando moltissimo la possibilità di stand-by del modulo. I 400mA di picco durante la trasmissione, non sono un grosso problema se distribuiti nel tempo.