Minnowboard è una comunità dedicata alla ricerca di hardware aperto che utilizzi processori Intel.
Le schede progettate si rivolgono al il mercato embedded a basso costo e mantengono la vecchia compatibilità x86. Sostanzialmente promuovono l’architettura Atom.
Il progetto LABijk, per la complessità strutturale che lo caratterizza, richiede un’attenta riflessione sulle sue scelte di fondo: il microserver, l’architettura di questo, i microcontroller, lo standard verso attuatori e sensori, i bus di comunicazione, i protocolli di sicurezza, e molto altro.
In uno sviluppo aperto andremo a classificare in modo ordinato ogni punto citato ed altri ritenuti indispensabili.
Continuiamo il nostro dibattito soffermandoci a riflettere sul/i bus di comunicazione da adottare tra il microserver e i dispositivi i al primo livello .
E’ ovvio pensare ad ethernet, ma pesano le seguenti argomentazioni
Quindi ethernet è solo per usi specifici e vedrebbe Arduino fuori gioco, precludendo tutta la gestione dell’elettronica in stile Arduino.
I vecchi bus seriali tipo RS232 sono lenti soprattutto se il dispositivo centrale, in questo caso il micorserver, fa pooling tra i periferici. Ricordiamo che una gestione ad eventi che parta dalle periferiche è esclusa perchè si perde il controllo delle periferiche stesse.
Consideriamo il bus USB:
Linux permette il controllo preciso delle porte USB, test verso Arduino, attraverso USB, mediante programma compilato C++ in pooling mostrano il funzionamento ininterrotto in mesi.
Un aspetto delicato da capire per bene è l’adozione, da parte del gruppo di progettazione Arduino, del reset in caso di perdita di connessione del BUS USB. Aspetto che si rivela invece estremamente utile per il recupero eventuale di una periferica fuori controllo: basta chiudere e riaprire la porta USB.
I microcontroller i di primo livello, connessi al microserver centrale tipicamente mediante USB, devono comunicare con gli altri ij del secondo livello.
Le seguenti osservazioni portano alla migliore scelta per queste tratte:
Quindi la scelta è il bus RS485.
Le ultime considerazioni sono relativa all’ultima tratta ovvero dai dispositivi ij a quelli ijk, che sono sensori, attuatori ed elettronica varia:
Il progetto LABijk è ambizioso, ma fattibile. Le applicazioni nel mondo elettrico e non solo, per esempio nel condizionamento di ambienti, sono molteplici.
Il livello i è costituito dai microcontroller direttamente connessi al microserver.
Le connessioni previste sono USB od ethernet.
Una ARM board sarebbe nettamente migliore, ma
Mel caso di livello j allora non vi è dubbio che l’Arduino SMD sia l’unica soluzione:
Il progetto è ambizioso, fattibile e di qualità.
Estrapoliamo alcuni punti che rendano un certo profilo:
Segnaliiamo il suggestivo articolo per l’utilizzo di un router con Linux Embedded con CPU Cortex-A8 Allwinner A10 ad 1GHz, dotata di 1GB di DDR2 RAM e 2GB su SD.
I punti deboli sono l’assenza di storage, la fragilità del sistema operativo in SD, la mancaza di un vero e proprio archivio RDBMS, un framework molto articolato per un ARM A8, l’ottimo, ma produce una filiera forse lunga per l’Allwinner, Node.js per le app verso palmari …
Il progetto intende promuovere tecnologie open source ed open electronics.
Si supponga di voler gestire sensori ed attuatori.
Poniamo al centro un microserver, con sistema operativo Linux Server, eventualmente connesso ad internet ed a reti locali.
Questa macchina archivia un resoconto di tutto quello che viene fatto e comunica con tablet, telefoni ed altri sistemi anche attraverso internet. Abbiamo già dato alcune indicazioni sulle possibili scelte in articoli precedenti.
Distinguiamo tre livelli, per l’appunto i, j e k di aggregazione dispositivi.
Alla radice poniamo il microserver.
I primi nodi, di livello i, siano microcontroller Arduino SMD Uno o Ethernet, connessi al microserver via USB o ethernet. Le schede Arduino siano dotate dispositivi adattatori seriali RS485.
Il secondo livello, detto j, è costituito da dispositivi Arduino SMD UNO con shield Grove e connessi al padre mediante seriale.
Al terzo livello, detto k, poniamo attuatori e sensori connessi ai padre mediante cavi Grove, oppure cavi multipolari a 4 capi, schermati o non, telefonici o di rete. Lo standard Grove può essere convertito da adattatori nel formato RJ13 per cavi telefonici o RJ45 per usuali cavi ethernet.
Ogni dispositivo è individuato da coordinate i.0.0 oppure i.j.0 oppure i.j.k
I comandi sono del tipo i.j.k:<comando:valore,…>
Il microserver è dotato di servizio che interroga costantemente in pool i dispositivi di livello i, mediante USB. Un secondo servizio che è simile al precedente ma per i dispostivi connessi mediante rete.
I dispostivi Arduino di coordinate i sono in ascolto verso il microserver, quindi USB o socket, ed anche interrogano il pool dei figli connessi mediante seriale.
I dispositvi di livello j sono in ascolto verso i dispositivi padri ed eseguono l’interrogazione in pool dei sensori, o meglio le entrate, oppure cambiano lo stato delle uscite.
Nel microserver esiste un database “automazione” con le tabelle
Il microserver esegue un servizio che interroga in pool i dispositivi di livello i e riporta comandi e cambiamenti di stato nelle tabelle corrispondenti.
Un secondo servizio legge i cambiamenti di stato, consulta le tabelle di correlazione e scrive i comandi da eseguire nella tabella comandi.
Un terzo legge la tabella comandi e instrada il comando nel ramo corretto.
Tutto è riportato in tabelle e viene a costituire in sistema three-tier architecture, con pilastri di appoggio quali PostgreSQL, Apache, OpenSSH, Postfix, …
Precisiamo che
Consideriamo un semplice esempio.
Supponiamo di avere un sistema di dimensione 5.3.5 ovvero al microserver sono connessi 5 dispositivi con il ruolo di HUB RS485, ad ognuno di questi sono connessi al più 3 dispositivi di livello j con HUB Grove, ad ognuno di questi al più 5 sensori o attuatori.
I dispositivi di livello j sono dotati di firmware che permette di sapere e gestire perfettamente i sensori od attuatori ad essi connessi. Inoltre questi dispositivi sono in pool rispetto i sensori ed attuatori.
Consideriamo il dispositivo di livello j di coordinate 3.2.
Supponiamo che abbia 2 attuatori ed un sensore di coordinate 3.2.3.
Il sensore sia un interrutore bistabile (entrata a due stati).
Ora se l’interrutore viene azionato e cambia stato, il dispositvo 3.2.0 costruisce il cambio stato 3.2.3:on (ma meglio introdurre la notazione definitiva 3.2.1:1 ) ed instrada il cambio stato al padre, il quale lo riporta al microserver che lo scrive nella tabella cambio stato.
Il servizio predisposto, nel microserver, rielabora secondo tabelle di correlazione il cambio stato, che viene elaborato, ovvero chiuso e crea gli opportuni comandi.
Mel nostro esempio il comando è 3.2.1:on ma meglio 3.2.1:1
Quindi il servizio legge il comando e lo instada al dispositivo 3.0.0 che lo gira a 3.2.0
A questo punto il dispositivo 3.2.0 elabora il comando alzando il livello all’uscita corrispondente.
Il progetto infine prevede la creazione di una GUI che gestisce le tabelle nel RDBMS del microserver.
La GUI permette di descrivere l’intero impianto mediante griglie di correlazione.
Quindi il programma prevede l’opzione di creare al volo ed in modo completamente automatico il firmware per ogni Arduino ed aggiornarlo via USB.
Perciò ogni Arduino deve venire correttamente etichettato mediante le coordinate i.j.k e connesso mediante USB al computer con la GUI di gestione per il travaso del firmware. L’operazione precedente deve essere rifatta nel caso che cambino i figli.
Il progetto si conclude con la realizzazione di App per Ubuntu Phone e Tablet, Android e iPhone di gestione ordinaria. L’obiettivo più ambizioso vorrebbe creare piante dei sistemi SVG e sovrapporre dei widgets dinamici visuali che rendano visuale il comportamento del sistema.
L’applicazione più importante sarà il controllo del CED quindi di una stanza con molti server. L’obiettivo è di controllare la linea di rete, le temperature, i tasti di accensione, reset di ogni server strategico. Le App mostreranno visualmente lo stato di ogni server e permetteranno operazioni quali spegnimento ed accesione “fisica”. Verranno gestiti i tempi di sostegno degli UPS e lo stato dei gateway verso l’esterno.
Il progetto nasce con la finalità di allestire una stazione per cominciare a fare misure di inquinamento.
La prima versione utilizza una scheda Arduino Uno SMD con interfaccia Grove e sensori per misurare:
1. presenza di gas
2. presenza di polveri inquinanti
3. fumi
3. presenza di vapori d’alcool
3. rumore
4. elettrosmog
A complemento integreremo le misure con temperatura ed umidità
In questa fase invitiamo a valutare i collegamenti proposti.
Stiamo valutando le possibili modalità di espansione della piattaforma Arduino.
In breve ci sono due versanti: a monte, ovvero un host di appoggio, ed a valle, ovvero sensori ed attuatori.
Il secondo aspetto, quello verso i sensori ed attuatori, porta alla grande questione di non poter sempre saldare ogni componente: serve uno shield che dia uno standard minimo verso l’elettronica finale.
Abbiamo deciso di valutare la proposta Grove della http://www.seeedstudio.com, dinamica azienda cinese, per integrarla nella progettualità futura. Forse la proposta più ampia.
I test sono orientati soprattutto alle esigenze di installatori ed integratori anche di piccole dimensioni. Imprese che non possono fare enormi investimenti in risorse economiche ed umane per attività di sviluppo su microcontroller ed altra elettronica, ma possono creare spazi virtuosi componendo tasselli di varie provenienze.