NETMFBLE : Una libreria .NET Micro Framework per Bluetooth 4.0 

Posted by Lorenzo Maiorfi Tuesday, August 19, 2014 8:24:00 AM
Rate this Content 0 Votes

A distanza di quasi sei mesi dalle prime righe di codice scritte, ho pubblicato in questi giorni una prima "beta" del progetto "BLE for NETMF" su Codeplex, all'indirizzo netmfble.codeplex.com.

L'obiettivo del progetto è quello di fornire ad applicazioni embedded sviluppate con .NET Micro Framework una libreria "driver" in grado di astrarre la complessità del protocollo Bluetooth Low Energy (il documento di specifiche, di cui potete scaricare un PDF all'indirizzo http://1drv.ms/1rQS6oH, è lungo circa 2700 pagine e questo spiega perché già in questa prima beta il progetto contenga più di 100 file .cs, test e sample esclusi!) esponendo delle API di alto livello (quale quella nota come GATT, nelle "declinazioni" sia server che client) pur senza impedire, grazie ad un modello a "layer", un accesso più a basso livello, fino ad arrivare al layer più basso sul quale la libreria si appoggia, ossia quello delle API HCI (Hardware Controller Interface).

Con NETMFBLE potrete dotare le vostre applicazioni embedded per .NET Micro Framework delle funzionalità che gli consentiranno, con il profilo "central", di collegarsi (anche con più sessioni aperte contemporaneamente) a periferiche BLE quali iBeacon, sensori (quali quelli dei kit KeyFob e SensorTag della Texas Instruments, tanto per fare un esempio), attuatori (come le lampade RGB Yeelight Blue), smartphone (è stato da poco annunciato il supporto "peripheral" nello stack BLE di Android L) e più in generale a tutti quei dispositivi censiti nel database della bluetooth.org, mentre tramite il profilo "peripheral" potrete realizzare dei firmware in grado di rendere "visibile" il vostro dispositivo embedded come GATT server, in grado ossia di esporre servizi e "caratteristiche" (proprietà leggibili, scrivibili e notificabili arricchite da metadati) compatibili con lo standard GATT (e quindi ad esempio a Smartphone BLE-compliant quali tutti quelli basati sulle versioni più recenti di iOS o quelli basati su Android 4.3+ che includano un controller BLE, come quelli della famiglia Samsung Galaxy), o anche soltanto come dispositivo che "espone" dati utili tramite "advertising", esattamente come fa un iBeacon (magari pubblicando dati più interessanti e meno statici di un semplice identificativo Wink).

Sebbene il modello di API HCI sia di fatto reperibile per tutti i controller BLE disponibili sul mercato, ciascun vendor fornisce una implementazione in parte proprietaria e questo di conseguenza limita la portabilità del progetto ai soli chip BLE per i quali è stata fornita un'implementazione: in questo momento l'unica implementazione disponibile in NETMFBLE è quella per il chip della Texas Instruments CC2540/CC2541, probabilmente il più diffuso ed economico nel suo genere. Tale chip è di fatto un microcontrollore  a 8 bit (programmabile tramite una qualsiasi toolchain per core 8051 e apposito SDK fornito dal produttore) che integra al suo interno un modulo radio dedicato alle funzioni BLE. L'interfaccia HCI è implementata da un apposito firmware i cui sorgenti sono parte del Bluetooth SDK 1.4 della Texas Instruments. Date le "modeste" capacità (in termini di flash e ram) del chip CC254x tale firmware deve essere compilato con differenti configurazioni a seconda del profilo BLE desiderato (central o peripheral, ossia quelli che nel "vecchio" Bluetooth venivano chiamati rispettivamente master e slave) e del pinout imposto dalla scheda sottostante.

Per semplificare l'utilizzo di NETMFBLE ho disegnato uno specifico modulo hardware, attualmente in fase di produzione, a breve disponibile gratuitamente per chi ne farà richiesta (tramite il Forum), al solo costo di una "recensione", fino all'esaurimento del primo lotto di 20 pezzi. Poiché la programmazione del chip CC254x richiede un apposito debugger hardware (il TI CC debugger), il modulo per NETMFBLE sarà disponibile pre-programmato nelle due versioni con profilo "central" e "peripheral", sebbene non escludo che in futuro si possa prevedere l'utilizzo di un bootloader per lo switch a runtime delle due funzioni.

Allora, avete già in mente una killer-application per NETMFBLE?

Better Embedded 2014 : la mia sessione sull’Internet of Things 

Posted by Paolo Patierno Tuesday, August 12, 2014 4:58:24 PM
Rate this Content 0 Votes

Il 4 e 5 Luglio sono stato a Firenze per l’evento Better Embedded 2014, la prima conferenza italiana dedicata al mondo embedded.

Ho avuto la fortuna e l’onore di essere speaker con una sessione sull’Internet of Things, intitolata “Internet of Things : protocols war !”. L’evento è stato seguito da molte persone come ogni anno ed ha mantenuto le sue aspettative e spero di poter rivivere questa esperienza anche l’anno prossimo.

10502174_10202541224956011_7172979389273929892_n

10488180_10202543474652252_1308244259809629282_n

Per quanto riguarda la mia sessione, potete trovare le slide disponibili su SlideShare.

Windows for IoT : “cannot open include file arduino.h” ? Verifica la connessione ad Internet, hai bisogno del package Galileo C++ SDK su Nuget ! 

Posted by Paolo Patierno Wednesday, July 23, 2014 1:25:35 PM
Rate this Content 0 Votes

Ieri ho ricevuto il mio kit con la board Intel Galileo con la versione di “Windows for IoT” ed ovviamente, come un bambino che ha tra le mani il suo nuovo giocattolo, ho iniziato a giocare !

La cosa più semplice è quella di seguire la documentazione online, raggiungibile dal sito ufficiale Windows On Devices, che descrive passo passo come essere “up and running” in pochi minuti. La mia voglia di fare mi ha portato a commettere un “errore” che non mi ha permesso di concludere la procedura nel modo corretto. Cosa è successo ?

Dopo aver acceso la Galileo, averla collegata al PC e navigato tra le cartelle (sia con una sessione telnet che come “network shared”), ho deciso di sviluppare il primo esempio relativo al blinking del led. Apro Visual Studio 2013 e seleziono il template di progetto C++ relativo a Windows for IoT, avvio la compilazione ed …. ecco l’errore !!

arduino_header_error

Non trova il file arduino.h ? Come mai ? Non viene installato insieme all’SDK che dobbiamo scaricare dal sito Microsoft Connect ? La risposta è no !

Tutti gli headers file con relativa implementazione sono nel Galileo C++ SDK che trovate su Nuget. Per questo motivo, ho dovuto manualmente scaricare tale package e referenziarlo nel mio progetto. A quel punto, tutto ha funzionato correttamente !

A quanto pare, però, sono stato l’unico ad avere questo problema e mi sono chiesto come mai ! Tutte le altre persone che hanno il kit hanno compilato il progetto di esempio senza alcun problema ma soprattutto senza dover scaricare manualmente il package Galileo C++ SDK da Nuget.

Ebbene non è proprio così ! Quel package è necessario ma il wizard lo scarica automaticamente al momento della generazione del progetto ed a quanto pare, in quel momento, il mio PC non era connesso ad Internet !!!

Se il PC non è connesso ad Internet, il wizard crea il file package.config vuoto :

   1: <?xml version=”1.0encoding=”utf-8”?>
   2: <packages>
   3: </packages>

Viceversa, esso contiene un riferimento al Galileo C++ SDK (Microsoft.IoT.Galileo.Arduino 1.0.0.0) nel momento in cui c’è connessione.

   1: <?xml version=”1.0encoding=”utf-8”?>
   2: <packages>
   3:     <package id="Microsoft.IoT.Galileo.Arduino" version="1.0.0.0" targetFramework="Native" />
   4: </packages>

E’ ovvio che tale package è necessario se avete intenzione di sviluppare applicazioni Arduino-like (infatti il wizard specifica “Galileo Wiring app”) ma non nel caso di applicazioni Win32 standard.

Insomma … prima di partire con il Windows Developer Program for IoT assicuratevi di avere il PC connesso alla grande rete !

IoT, Arduino, REST e Cloud … su HTML.it 

Posted by Paolo Patierno Friday, July 18, 2014 7:53:51 PM
Rate this Content 0 Votes

0871_Cattura_6DB192D2

Giunti al nono capitolo della guida introduttiva su Arduino, possiamo finalmente toccare con mano la nuvola !

In particolare, si parte dalla realizzazione di un semplice client HTTP REST su Arduino attraverso il quale poter trasmettere nel Cloud i valori di temperatura rilevati dal relativo sensore e letti attraverso il driver sviluppato nei capitoli precedenti. La nuvola che ospita il servizio di acquisizione dati è ovviamente Azure attraverso una semplice applicazione ASP.NET MVC4 Web API.

M2Mqtt 3.5 : .Net MQTT client con un miglior supporto SSL/TLS, altri miglioramenti e licenza Apache 2.0 ! 

Posted by Paolo Patierno Friday, July 18, 2014 1:03:04 PM
Rate this Content 0 Votes

Questa volta la libreria M2Mqtt ha subito alcune modifiche “importanti” sia in termini di nuove funzionalità che di bug fixing. Devo ammettere che i miglioramenti sono dovuti soprattutto alle persone che la utilizzano in maniera assidua e mi segnalano nuove funzionalità da aggiungere o bug da risolvere. Oltre ad alcuni problemi segnalati su CodePlex, questa volta anche Clemens Vasters, PM su Microsoft Azure, mi ha sottoposto alcuni miglioramenti da applicare nell’ambito dell’autenticazione SSL/TLS. Infatti, come già twittato molte settimane fa, Clemens ha usato la mia libreria per eseguire i test sul progetto Reykjavik (Device Gateway) presentato a Build 2014 ed io non posso che esserne onorato.

Autenticazione SSL/TLS

In questo caso, il miglioramento è strettamente legato alla versione per .Net Framework, poiché è l’unica versione a supportare quanto è stato aggiunto. In particolare, la classe MqttClient mette disposizione altri costruttori ai quali è possibile fornire le seguenti callback :

  • RemoteCertificateValidationCallback : permette all’utente di effettuare ulteriori controlli sulla validazione del certificato ricevuto dal server oltre a quelli già eseguiti dal sistema. Utile nel caso di debugging e di utilizzo di certificati self-signed, in modo da accettare a prescindere la connessione con il server;
  • LocalCertificateSelectionCallback : permette all’utente di selezionare in maniera opportuna il certificato client da trasferire al server in caso di mutua autenticazione durante l’handshake SSL. Il certificato può essere selezionato da un pool di certificati locali oppure creato “a volo” direttamente nella callback;

Per maggiori informazioni, è possibile fare riferimento alla documentazione MSDN ufficiale.

Nel caso del costruttore più complesso (con entrambe le callback), un esempio di applicazione può essere il seguente :

   1: MqttClient client = new MqttClient("<server_name>", 8883, true, ValidateServerCertificate, SelectClientCertificate);
   2: ...
   3: ...
   4:  
   5: bool ValidateServerCertificate(object sender, 
   6:                         X509Certificate certificate, 
   7:                         X509Chain chain, 
   8:                         SslPolicyErrors sslpolicyerrors)
   9: {
  10:     bool valid;
  11:     // check sslpolicyerrors and execute your certificate validation
  12:     ...
  13:     ...
  14:     return valid;
  15: }
  16:  
  17: X509Certificate SelectClientCertificate(
  18:                       Object sender,
  19:                       string targetHost,
  20:                       X509CertificateCollection localCertificates,
  21:                       X509Certificate remoteCertificate,
  22:                       string[] acceptableIssuers)
  23: {
  24:     X509Certificate cert;
  25:  
  26:     // choose client certificate from local store or creating new one
  27:     ...
  28:     ...
  29:     return cert;
  30: }

Costruttori obsoleti e tracing

Per cercare di semplificare la creazione dell’oggetto client, i costruttori che ricevono in ingresso un IPAddress sono stati “marcati” con l’attributo Obsolete. Infatti, tutti gli altri costruttori permettono di specificare in ingresso un indirizzo IP o un host name in formato stringa; sarò carico del costruttore verificare di che tipo si tratta e nel caso di host name effettuare una conversione ad indirizzo IP attraverso DNS.

Per quanto riguarda il tracing, alcune persone hanno segnalato che nella versione Nuget questa funzionalità non visualizzava il contenuto di ciascuno messaggio scambiato ma il tipo del messaggio; ciò era dovuto al fatto che la libreria Nuget è compilata in modalità Release ma i messaggi di trace erano attivi in Debug. La versione attuale fornisce il tracing sia in debug che release in quanto è legata al simbolo TRACE (e non più al simbolo DEBUG) che è definito in entrambe le configurazioni. Ovviamente, il tracing è sempre legato alla definizione di un TraceListener da parte dell’utilizzatore.

Bug fixing

I principali bug risolti sono stati segnalati sul sito CodePlex da alcuni utenti e di seguito riporto i riferimenti :

Conclusioni

La libreria è in continua evoluzione grazie alla community e molto presto includerà il supporto per MQTT 3.1.1 che tra poche settimane sarà standard OASIS. L’ulteriore passo è la licenza passata da L-GPL ad Apache 2.0 !

Come sempre potete trovare la versione aggiornata su CodePlex, Nuget e Microsoft Code Gallery. Infine, è stato ovviamente aggiornato anche il broker GnatMQ alla versione 0.9.1.0 ed il progetto M2Mqtt4CE.

Page 1 of 43 1 2 3 4 5 6 7 8 9 10 20 40 > >>