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.