Revisione 0.05.

La prima famiglia di controller che consideriamo è la AVR Arduino per la popolarità acquisita.

Le schede con microcontroller AVR della famiglia Arduino non solo sono dotate delle interfacce adeguate per gestire sensori ed attuatori  con software ed hardware pronto all’uso, ma hanno una documentazione approfondita e facilmente apprendibile anche per addentrarsi nell’elettronica necessaria. Inoltre sono stati sviluppati vari standard per shield, sensori ed attuatori che permettono di realizzare facilmente interfacce verso un ampio parco di elettronica.

Questi dispositivi sono caratterizzati dal consumo basso, non scaldano, hanno dimensioni minime e sono molto stabili. Le librerie per realizzare firmware in C/C++, sono ampie e di facile utilizzo.

I servizi nel processore prevedono i comandi compila ed upload firmware in una scheda Arduino correttamente riconosciuta dal Sistema.

In questo contesto il collegamento previsto tra processore e controller è USB perchè è uno standard diffuso e robusto.

Il processore, dotato di Sistema Operativo Linux, permette la gestione Plug&Play dei dispositivi USB,

Il processore ha un servizio compilato  C++/Qt ed eseguito mediante Linux kernel cron al minuto per riconoscere ed aggiornare nelle tabelle Dati del Sistema i dispositivi presenti.

Pertanto se un nuovo controller viene collegato ad una porta USB del processore, con la frequenza del minuto, viene riconosciuto ed le relative informazioni vengono inserite nella base dati.

L’esperienza porta a massimizzare la velocità del canale USB ma senza perdere affidabilità. Molti test portano ad utilizzare la velocità di 115200 baud. Si ottiene così un poll molto reattivo sull’ordine del centesimo di secondo.

Il linguaggio che viene a definirsi prevede molte istruzioni relative alle gestioni I.o.T. che chiameremo comandi per ricordare che la struttura della comunicazione è del tipo richiesta / risposta. Ma soprattutto perché la struttura del Sistema prevede la gestione separata di comandi e non di programmi. Singoli comandi possono essere intesi come macro, ovvero aggregato di più comandi considerati elementari. I comandi giacciono in tabelle e parsing ed esecuzione sono delegati a dispositivi o servizi diversi.

I comandi sono tali da essere leggibili dall’uomo per facilitare il debug.

Alcuni comandi introdotti sono:

• “ver|version”
• “board”
• “config port 0..53 type unused|IN|OUT|PWM|LCD|I2C|SPI|SERIAL”
• “set|write port <n> value 0|low|1|high”
• “get|read port <n>”
• “lcd on|enable|off|disable”
• “lcd clear”
• “lcd clear row 1|2”
• “lcd print row 1|2 <string>”
• “request_response on|off”

I comandi e le risposte sono stringhe terminate con a capo  \r\n e \n  automatico.

Il processore contiene il servizio iot_service_controller in C++/Qt in esecuzione dal riconoscimento del nuovo controller connesso fino alla disconnessione dello stesso.

Il servizio iot_service_controller realizza il poll con il controller a lui dedicato tramite connessione USB.

Per gestire anche gli eventi dal controller si amplia la struttura del comando con il parametro repeat_delay, che se nullo comporta la singola esecuzione, altrimenti l’esecuzione ogni repeat_delay cicli di poll.

Il firmware è realizzato rispettando le seguenti linee guida:

• è prevista la creazione automatica della sorgente del firmware in C/C++ mediante un generatore di codice sorgente, eseguito nel processore, dai dati contenuti dalla base dati del Sistema I.o.T.
• il firmware è unico, non ci sono varianti che obblighino a tenere allineate più sorgenti
• per facilitare il debug è possibile inviare manualmente i comandi da console seriale dell’IDE Arduino
• è prevista l’inclusione dinamica delle librerie necessarie per ottenere la massima compattezza del compilato; così infatti se non viene utilizzato il display LCD la relativa libreria non viene caricata
• all’avvio il firmware legge il tipo di scheda che lo esegue, per esempio Uno o Mega o Teensy, e tiene conto in fase di esecuzione del numero di porte disponibili; è previsto il comando board che rende il tipo scheda riconosciuto
• prevede la configurazione dinamica dei pin del controller: OUT digital out, IN digital in, AD, DA, PWM, serial, I2C, SPI , LCD, …; se per esempio si attiva il display LCD vengono riservati i pin necessari alla gestione, e se nell’escuzione si invia ad uno di questi un comando di assegnazione porta digitale in uscita al livello alto, il controller rende il messaggio di errore 
  
• sono gestiti comandi che diano al controller la gestione di variabili e file, che sono nella realtà riportare nel database del sistema
• il servizio esegue un parsing duplice:
  • dei comandi ad esso diretto, per esempio modifica delay nel poll principale
    
  • delle macro da decomporre in comandi semplici verso il controller; quindi il firmware viene allegerito dall’esecuzione di codice complesso, che viene demandato al servizio in esecuzione nel controller, ovvero in un contesto ben più dotato di risorse
• la gestione LCD è demandata al controller e, se non RGB,  vengono utilizzati i pin 4,5,6,7,8,9 con la libreria LiquidCrystal
• è prevista la gestione del watch dog hardware AVR con la libreria avr/wdt
• le gestioni serial, I2C e SPI sono demandate al controller
• il firmware gestisce in autonomia, ma attivato da comandi specifici, eventi quali una porta digitale in entrata è stata al livello alto o basso, oppure una porta da analogico a digitale a superato una data soglia da sopra o da sotto; in questo modo si rendono autonome dal poll, con delega completa al controller, gestioni quali bottoni monostabili o termostati

Per informazioni.