Netduino

Open source nature and community for bringing .Net Micro Framework to a new life !

Yesterday, the biggest manufacturer of .Net Gadgeteer devices announced a bad news to the community: they won’t produce the boards based on it anymore.

To be precise, they won’t abandoned the entire .Net Micro Framework development but “only” all the boards known for the simplicity of developing prototypes avoiding soldering but using simple socket instead.

Of course, I’m speaking about the GHI Electronics.

I have some of their great boards used in a lot of demos and examples on .Net Micro Framework development for the Internet of Things during my sessions around Italy. Today, I can understand their decision: .Net Gadgeteer was created by Microsoft but today there isn’t so much effort on it and the community isn’t so huge for bringing the framework to the next level. In the last years, GHI Electronics was alone in order to support this framework and having it alive. From my point of view, it’s a pity because using .Net Gadgeteer boards, the ideas become reality in a very short time: from the advantage of using socket connection for the hardware to the application development with C# and .Net Micro Framework. The way to a final product is very long … but as starting point it was good.

To this bad news, we can add the silence by SecretLabs about another well-known board in the .Net Micro Framework world: the Netduino.

Netduino was my first love starting from its first version (without Ethernet) to the latest WiFi board. I played a lot with it, learning .Net Micro Framework development, even without the simplicity of hardware connections because I like “flying wires”. Even SecretLabs tried to do something like .Net Gadgeteer with Netduino Go without so much luck (they used a completely different “standard” for that).

The bad news and the silence let me start thinking about the future of the .Net Micro Framework.

Of course, to be precise, the framework life isn’t related to the future of the maker platforms provided by GHI Electronics and SecretLabs, because some companies are designing their own boards for running it.

It was born in the Microsoft research laboratories as the SPOT (Smart Personal Objects Technology) framework presented in the 2002. It became .Net Micro Framework and after some years Microsoft decided to provide it as open source without focusing so much on its development. Developers started to use it but only for hobbystic projects; only few companies decided to start developing real world products.

With the new IoT business, a couple of years ago Microsoft re-started to focus on it showing a lot of demos all around the world (at Build as well) based on .Net Micro Framework devices connected to Azure services (even before IoT Hub but using Service Bus and Event Hub). It seems that today this strong support is ended … Microsoft wants to provide better Cloud experience (the “I” in the IoT business) for all kind of devices without any difference on the running operating system or framework.

It seems to be another bad news for developers who believe in the .Net Micro Framework but fortunately … it’s always open source and the community can change its destiny.

As an open source developers (you know, I work for Red Hat … the company leader on open source) I believe in community projects : I started to write a lot of open sourced code for .Net Micro Framework a bunch of years ago and the community helped me to improve my libraries.

Today, Microsoft is providing few “human” resources to the .Net Micro Framework project hosted on GitHub in order to make the big changes on it and coordinate the community: I agree on that … now the community has the framework in its hands. At same time I know the Microsoft guys who are supporting it … they are great guys … trust me !

I know a lot of great guys who are working on .Net Micro Framework for their commercial products and for this reason I’m confident in the future. I know that the community around it isn’t so huge and it could be a problem for having a platform used as primary choice for embedded development. It’s also true that embedded world (yes ! embedded … not IoT !) is so much heterogeneous and each developer has its preferences: there is space for all of them, from ARM mbed platform to the .Net Micro Framework itself for example.

In the last months the interest about .Net Micro Framework was revamped by the new LILIUM project; to be precise it’s not the new version of the framework which has its own roadmap but a new way to develop in C# and UWP on embedded devices with the power of pre-compiled native code !

In order to define the right way for the community effort, two interesting discussions were opened on GitHub and all the main protagonists are arguing on the objectives and the roadmap: this is the essence of “to be a community”.

The first one is focused on the future of the .Net Micro Framework and its version 5 (today we are at 4.4) and the other one on the differences with LILIUM project; it’s worth for you to follow them both.

Let’s see … the IoT business opened a lot of scenarios … no doors are closed … can the open source nature and the community bring embedded C# development to a new life ?

A routing IoT gateway to the Cloud

Let’s start with an on-premise solution …

Imagine that you have an embedded solution (or if you like it … an IoT solution) with a bunch of tiny devices which are connected to an on-premise server which receives telemetry data from them and is able to execute some elaboration in order to show information in real time on a dashboard and control the devices.

Imagine that your solution is based on the AMQP protocol and perhaps your on-premise server is running a messaging broker for gathering data from devices as messages through the local network.

Imagine that, due to your very constrained devices, the security in the network is guaranteed only at data level by encrypting the body of every single AMQP message. It’s possible that due to their complexity and need of more resources (CPU and memory) you can’t use sophisticated algorithms (i.e. DES, 3DES, AES, …) on your devices but only simple ones (i.e. TEA, ..).

Your solution is just working great in your environment.

… but now we want to move it to the Cloud

Imagine that for some reasons you need to change the on-premise nature of your solution and you want to connect the devices directly to the cloud with a very strict rule : nothing to change on the devices. At least you can change some configuration parameter (i.e. server ip, …) but not the way and the protocol they are using for communication.

The first simple solution could be moving your messaging broker from the on-premise server on a IaaS in the Cloud; just changing connection parameters on your devices and all continue to work as before.

The big problem now is that your data are sent through the public network and your security is based on a simple encryption algorithm applied only on the payload of the messages. For this reason, you start to think about using SSL/TLS in order to have security at connection level on top of TCP/IP, data encryption and server authentication.

Start to think about it but then … wait … I can’t use SSL/TLS on my tiny devices … they don’t have the needed resources in terms of CPU and memory … and now ?

Fog computing and IoT gateway : the solution ?

You know about “fog computing” (the new buzz word after IoT ?) and that you can solve your problem using an IoT gateway. Having this gateway could mean to have an intelligent piece of software which is able to gather data from the local network, process them in some way and then send them to the Cloud. The gateway could give you more features like filtering on data (sending only part of them), offline handling (if the Cloud isn’t reachable) and complex local processing but … wait … you don’t want it … you just want that data arrives to the Cloud in the same way as before (to the on-premise server) and for now you don’t need other additional great features.

Could we have a very simple IoT gateway with only the two following features we need :

  • SSL/TLS protocol support on behalf of the tiny devices;
  • traffic routing from devices to the Cloud in a transparent way;

The answer is … yes ! You have such solution and it’s provided by the Qpid Dispatch Router project from the ASF (Apache Software Foundation).

I already wrote about it in some previous articles [1] [3] so let me just show how you can use the router in a way that solve your “porting” problem.

The router just needs the right configuration

In order to show in a very simple way how to configure the router for our objective, we can use the Azure IoT Hub as Cloud platform for the IoT. As all the Azure messaging services like Service Bus and Event Hub, the IoT Hub needs an encrypted connection based on the SSL/TLS protocol … so it’s the problem we want to solve for our non SSL capable devices.

For the sake of simplicity we can run the router on a Raspberry Pi using the Raspbian distribution as OS; you can read about installing the Qpid Dispatch Router on Linux and on the Raspberry Pi in these articles [2] [4].

The main point is the configuration needed for the router in order to connect to an IoT Hub and routing the traffic from devices to it.

First of all we have to consider all the addresses that at AMQP level are used in order to send telemetry data to the hub, receive commands and reply with feedback. All these information are deeply explained here [5] [6].

The routing mechanism used in this configuration is the “link routing” [3] which means that the router creates a sort of “tunneling” between devices and the IoT Hub; it opens the TCP/IP connection with the hub, establishing it with SSL/TLS on top, and then opens the AMQP connection. All the SSL/TLS stuff happens between router and IoT Hub and the devices aren’t aware about it. You can see what happens through the router trace :

pi@raspberrypi:~ $ PN_TRACE_FRM=1 qdrouterd --conf ex06_iothub.conf
Sat Jul 23 11:56:17 2016 SERVER (info) Container Name: Router.A
Sat Jul 23 11:56:17 2016 ROUTER (info) Router started in Standalone mode
Sat Jul 23 11:56:17 2016 ROUTER_CORE (info) Router Core thread running. 0/Router.A
Sat Jul 23 11:56:17 2016 ROUTER_CORE (info) In-process subscription M/$management
Sat Jul 23 11:56:18 2016 ROUTER_CORE (info) In-process subscription L/$management
Sat Jul 23 11:56:18 2016 AGENT (info) Activating management agent on $_management_internal
Sat Jul 23 11:56:18 2016 ROUTER_CORE (info) In-process subscription L/$_management_internal
Sat Jul 23 11:56:18 2016 DISPLAYNAME (info) Activating DisplayNameService on $displayname
Sat Jul 23 11:56:18 2016 ROUTER_CORE (info) In-process subscription L/$displayname
Sat Jul 23 11:56:18 2016 CONN_MGR (info) Configured Listener: 0.0.0.0:5672 proto=any role=normal
Listening on 0.0.0.0:5672
Sat Jul 23 11:56:18 2016 CONN_MGR (info) Configured Connector: ppatiernoiothub.azure-devices.net:5671 proto=any role=on-demand
Sat Jul 23 11:56:20 2016 POLICY (info) Policy configured maximumConnections: 0, policyFolder: '', access rules enabled: 'false'
Sat Jul 23 11:56:20 2016 SERVER (info) Operational, 4 Threads Running
Connected to ppatiernoiothub.azure-devices.net:5671
[0x19dc6c8]: -> SASL
[0x19dc6c8]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b"anonymous@raspberrypi"]
[0x19dc6c8]: -> AMQP
[0x19dc6c8]:0 -> @open(16) [container-id="Router.A", hostname="ppatiernoiothub.azure-devices.net", max-frame-size=65536, channel-max=32767, idle-time-out=60000, offered-capabilities=:"ANONYMOUS-RELAY", properties={:product="qpid-dispatch-router", :version="0.6.0"}]
[0x19dc6c8]: <- SASL
[0x19dc6c8]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:EXTERNAL, :MSSBCBS, :ANONYMOUS, :PLAIN]]
[0x19dc6c8]:0 <- @sasl-outcome(68) 
[0x19dc6c8]: <- AMQP
[0x19dc6c8]:0 <- @open(16) [container-id="DeviceGateway_1766cd14067b4c4b8008b15ba75f1fd6", hostname="10.0.0.56", max-frame-size=65536, channel-max=8191, idle-time-out=240000]

At this point, the devices can connect locally to the router and when they asked for all the AMQP links related to the IoT Hub addresses, they will be tunneled by the router : the AMQP “attach” performatives are routed to the IoT Hub through the connection with the router. The communication then continues on this link in terms of message transfers directly between IoT Hub and devices but all encrypted until the router through the SSL/TLS protocol.router_iothub

The router configuration is something like that :

listener {
 addr: 0.0.0.0
 port: 5672
 authenticatePeer: no
}

ssl-profile {
 name: azure-ssl-profile
 cert-db: /opt/qdrouterd/Equifax_Secure_Certificate_Authority.pem
}

connector {
 name: IOTHUB
 addr: <iotHub>.azure-devices.net
 port: 5671
 role: on-demand
 sasl-mechanisms: ANONYMOUS
 ssl-profile: azure-ssl-profile
 idleTimeoutSeconds: 120
}

# sending CBS token
linkRoute {
 prefix: $cbs/
 connection: IOTHUB
 dir: in
}

# receiving the status of CBS token request
linkRoute {
 prefix: $cbs/
 connection: IOTHUB
 dir: out
}

# sending telemetry path and command replies from device to hub on : devices/<DEVICE_ID>/messages/events
# ATTENTION ! Here we need CBS Token
linkRoute {
 prefix: devices/
 connection: IOTHUB
 dir: in
}

# receiving command on device from hub on : devices/<DEVICE_ID>/messages/deviceBound
# ATTENTION ! Here we need CBS Token
linkRoute {
 prefix: devices/
 connection: IOTHUB
 dir: out
}

The main points in the configuration are :

  • a listener entity which defines that the router accept incoming AMQP connections on port 5672 (not encrypted);
  • the ssl-profile entity in order to configure the parameter for SSL/TLS connection to the IoT Hub and specifically the CA certificate to use for server authentication;
  • the connector entity which defines the way the router connects to the IoT Hub (address and port) using the above SSL profile;

After above parameters there is a bunch of linkRoute entities which define what are the addresses that should be link routed by the router from devices to the hub (using the specified connector).

You can find the complete configuration file here.

The Netduino Plus 2 use case

In order to develop an application very quickly on device side I decided to use my knowledge about .Net Micro Framework using a board that hasn’t the SSL/TLS support : the Netduino Plus 2 board.

The simple application is able to send a message to the IoT Hub and receive a new one replying with a feedback. All the code is available here.

In the following pictures you can see the message sent by the board and the command received (with the related feedback) through the Device Explorer tool.

01

02

Conclusion

Of course, the Qpid Dispatch Router project has a greater object than I showed here that could be providing connection to messaging services at scale thanks a more complex router network, with a path redundancy feature to reach a broker or a simple receiver.

In this article, I just showed a different way to use it in order to give more power to tiny devices which aren’t able to connect to AMQP based services due to their limitation (in this case the lack of SSL/TLS support).

If you consider the starting point, the configuration change could be avoided because the router could have same IP address and AMQP listening port as the previous on-premise server .

It means that only adding the router configured for the Cloud connection solves the problem !

[1] Routing AMQP : the Qpid Dispatch Router project

[2] Qpid Dispatch Router installation on your Linux machine

[3] Routing mechanisms for AMQP protocol

[4] My Raspberry Pi runs the Qpid Dispatch Router

[5] Connecting to the Azure IoT Hub using an AMQP stack

[6] Azure IoT Hub : commands and feedback using AMQP .Net Lite

Internet of Things “wrap up” : eventi, slides, librerie e … demo con tanto codice !!

Nell’ultimo mese ho sviluppato molto ed ho avuto il piacere di essere speaker a tre eventi nazionali ed uno internazionale in California (ma da remoto).

Sono stato notevolmente impegnato nello scrivere codice e contenuti che ho deciso di riassumere qualora possano tornarvi utili.

DSC_0389 iotday

Con le slide ho cercato di descrivere al meglio l’Azure Service Bus focalizzandomi sull’Event Hubs e sul suo utilizzo nell’ambito della telemetria IoT :

A queste slide sono legate delle demo nelle quali ho utilizzato la mia ultima libreria Azure SB Lite, grazie alla quale è possibile accedere al Microsoft Azure Service Bus utilizzando le stesse API dell’SDK “originale” ma sulle piattaforme embedded come .Net Micro Framework e .Net Compact Framework oltre che su Mono (quindi Linux) e WinRT (quindi Windows 8.1 e Windows 10). Essa è basata sulla libreria AMQP .Net Lite di cui nasconde i concetti sul protocollo AMQP.

overall

Per quanto riguarda le demo :

  • BLE2Azure : concept di un IoT gateway da dispositive BLE verso Azure (Event Hubs) realizzato con il .Net Micro Framework e le board FEZ Spider e Netduino 3 Wi-Fi
  • Azure SB Lite Examples : esempi di utilizzo della libreria Azure SB Lite che mi hanno permesso (in quel di Venezia) di spiegare come funziona realmente l’accesso al Service Bus attraverso il protocollo AMQP e scoprire cosa ci sia al di sotto delle semplici APIs.

 Ovviamente non mi fermo qui nonostante il meritato riposo !

🙂

.Net Micro Framework e regular expressions … “out of range exception” !

Sviluppando la mia libreria per l’acesso al Microsoft Azure Service Bus (event hubs, queues, topics/subscriptions) basata su AMQP (e sulla libreria AMQP .Net Lite) mi sono imbattuto in un bug nel codice delle regular expression nel .Net Micro Framework.

Il bug si è verificato per puro caso, quando mi sono ritrovato con una “connection string” all’interno della quale c’era il campo “SharedAccessSignature” che va valorizzato nel caso in cui utilizziamo la connessione AMQP con CBS (Claim Based Security) ossia quando pubblichiamo su event hubs verso un “publisher” endpoint e con sicurezza basata su un SAS token.

In questo caso, il campo suddetto assume un valore abbastanza lungo, basta vedere la “connection string” nella quale mi sono imbattuto :

"Endpoint=sb://ppatiernoeventhubs.servicebus.windows.net/;SharedAccessSignature=SharedAccessSignature sr=http%3a%2f%2fppatiernoeventhubs.servicebus.windows.net%2fnetmftesteventhub%2fPublishers%2fdevice1&sig=FttwMBQt0T1e1hPQIk0TbRSfuPohbTXAi5L8dPSQzbA%3d&se=1306887634&skn=EventSendKeyName;EntityPath=ppatiernoeventhub;Publisher=device1;TransportType=0";

Per estrarre i campi, ho scritto le seguenti righe di codice :

Regex regex = new Regex("([^=;]+)=([^;]+)");

IDictionary connectionStringParams = new Hashtable();

MatchCollection matches = regex.Matches(connectionString);
foreach (Match match in matches)
{
	connectionStringParams[match.Groups[1].Value] = match.Groups[2].Value;
}

Alla seconda iterazione ossia in corrispondenza del campo “SharedAccessSignature” mi sono ritrovato di fronte ad una OutOfRangeException … dovuta a cosa ?

 regex_netmf

Dallo screenshot si evince che il campo “Length” del match riscontrato ha un valore negativo pari a -80. Come mai ?

Ebbene, il valore del campo “SharedAccessSignature” (il SAS token) ha una lunghezza pari a 208 e facendo una semplice sottrazione 128 – 208 è proprio pari a -80.

Probabilmente nel .Net Micro Framework viene utilizzata una variabile del tipo “signed byte” per contenere tale valore che determina un ovvio overflow; la lunghezza massima di un valore in un match è stata probabilmente fissata a 128.

Purtroppo, fino alla correzione del bug che ho provveduto a segnalare, vi consiglio di evitare matching con valori più lunghi di 128 caratteri !

🙂

Netduino : la nuova “terza” generazione anche con Wi-Fi integrato

Ed ora … posso finalmente scrivere qualcosa !! 🙂

Circa due settimane fa ho ricevuto un bel regalo dalla Secret Labs (grazie a Chris Walker) … la nuova scheda Netduino 3 Wi-Fi !

WP_20150429_22_18_19_ProWP_20150429_22_18_35_Pro

Personalmente, ho iniziato la mia “carriera” con il .Net Micro Framework utilizzando le board Netudino e Netduino Plus (prima e seconda generazione), divertendomi tantissimo nello sviluppo di driver gestiti per i componenti ad esse collegati. Con l’esplosione dell’Internet of Things, ho iniziato a sviluppare la mia libreria M2Mqtt ed a testarla sulla versione della board dotata di connessione Ethernet, ma per quanto riguarda il collegamento con i servizi Azure come il Service Bus (event hubs, queues e topics/subscription) mi sono dovuto fermare a causa di un grosso problema: il mancato supporto per il protocollo SSL/TLS ! (necessario per Azure).

Ufficialmente a partire da ieri (ma poche settimane fa per me) … non abbiamo questo limite ! La “terza” generazione delle board della famiglia Netduino supporta i protocolli sicuri come SSL/TLS e quindi fornisce la possibilità di connettersi a tutti i servizi Microsoft Azure ! 🙂

Per ora, solo la versione Wi-Fi è già disponibile su Amazon qui e la versione Ethernet sarà disponibile nel mese di giugno qui.

L’hardware

Parlando della Netduino 3 Wi-Fi, questa scheda ha un STM32 MCU (microcontrollore a 32 bit) Cortex-M4 a 168Mhz con 2 MB di Flash dual-bank e 256 KB di RAM. Naturalmente, a causa del .Net Micro Framework TinyCLR abbiamo fino a 1408 KB per il nostro codice applicativo (in Flash) e circa 164 KB di RAM disponibile. Per me, si tratta di enormi quantità di memoria per le applicazioni embedded complesse !

netduino3wifi

Abbiamo lo stesso pulsante ed il led come le schede precedenti e tutti i pin, 22 pin digitali e analogici come GPIO, che possono essere utilizzate con le seguenti caratteristiche specifiche :

  • Porte UART
  • Segnali PWM
  • Porte SPI
  • Porte I2C

La grande differenza con le schede precedenti è la presenza di 3 porte GoBus 2.0 e sembra che la Secret Labs stia sviluppando nuovi componenti da connettere ad essi. Se volete sapere che cosa è GoBus, potete approfondire con il seguente articolo : sembra essere una caratteristica simile a .Net Gadgeteer ma ha molteplici differenze.

Il modulo Wi-Fi è una grande caratteristica in più perché è completamente integrato sulla scheda senza la necessità di un dispositivo esterno. Il chip è un TI CC3100 (Texas Instruments), con tutte le certificazioni necessarie e supporta 802.11 b/g  n con SSL/TLS ed i tre livelli di sicurezza: aperto, WEP e WPA2.

Ultima caratteristica ma non meno importante è il connettore microSD (fino a 2 GB) per la memorizzazione dei dati.

Il software

Naturalmente le nuove schede Netduino sono tutti basate sulla più recente versione del .Net Micro Framework (4.3 QFE2-RTM) e tutto il codice è open source: si può trovare il porting per Netduino su GitHub.

Una grande differenza con il passato è il Netduino.IP: il nuovo stack TCP/IP per .Net Micro Framework. Come sappiamo, uno dei grandi problemi del .Net Micro Framework è lo stack di rete che non è molto affidabile. Per questo motivo, Secret Labs ha deciso di iniziare il nuovo progetto di cui sopra con lo sviluppo di uno stack TCP/IP completamente gestito ed avere il pieno controllo su di esso. Naturalmente, questo nuovo “nato” è ancora in Technical Preview e sotto test ogni giorno per migliorare le sue featues e prestazioni. La buona notizia è che ha supporta per le classi standard in System.Net  (Socket, HttpWebRequest, …) per garantire retrocompatibilità ed utilizza solo 4 KB di RAM. Come progetto open source, è disponibile su GitHub per due chip Ethernet: il solito Microchip ENC28J60 e Asix AX88796C.

Per quanto riguarda il supporto Wi-Fi, lo stack TCP/IP per il TI CC3100 è in un altro progetto (che sarà assimilato nel Netduino.IP) disponibile qui. In questo caso, abbiamo il pieno supporto per la classe SslStream per SSL/TLS 1.2. Questo progetto è in fase di sviluppo ed ha alcune alcune limitazioni relative al numero di socket aperte simultaneamente e buffer. Le prestazioni potrebbero essere superiori perché la versione corrente usa l’UART per comunicare con il chip ma il supporto SPI arriverà presto.

Dal punto di vista degli sviluppatori, abbiamo Visual Studio 2013 ma è già pronto il supporto per Visual Studio 2015.

Infinite possibilità

Con questa nuova terza generazione, ora abbiamo molte possibilità nell’ambito dell’Internet of Things con la famiglia delle board Netduino. Il grande vantaggio è l’accesso a tutti i servizi Microsoft Azure come Event Hubs (e tutti gli altri servizi del Service Bus) e di tutti i servizi on-line che hanno bisogno di supporto SSL (le Twitter APIs per esempio). Ho già provato la mia board nelle ultime due settimane ed ho avuto buoni risultati usando la libreria AMQP Net Lite per la connessione al Service Bus e con la mia libreria M2Mqtt con un broker MQTT nell’iinviare e ricevere molteplici messaggi. Tutti i miei test sono correlati al lato client dell’uso della board poichè non concordo nell’avere un server su un dispositivo embedded per motivi di sicurezza, quindi non ho approfondito le funzionalità disponibili per sviluppare un server HTTP(S) a bordo. La scheda con tutti i relativi stack software sembra essere affidabile ma la performance potrebbero essere migliorate. So che Chris lavorerà duramente nei prossimi mesi per fornire nuove funzionalità e miglioramenti per darci un prodotto migliore per collegare le “nostre” cose all’Internet degli oggetti in rete.

Una nuova casa per il .Net Micro Framework … GitHub !!

netmf_github

Il primo passo “visibile” del nuovo .Net Micro Framework è stato compiuto … finalmente il repository ufficiale delle future versioni è GitHub; viceversa le precedenti versioni del framework rimarrano su CodePlex così come il forum. Ogni bug/issue riportata su CodePlex verrà valutata ed inserita come “work item” in GitHub.

Ricordando la natura da “interprete” del runtime, il progetto è stato battezzato proprio “.Net Micro Framework Interpreter” ma contiene l’interprete, la BCL (Base Class Library) ed il codice nativo per il porting.

Dal punto di vista delle funzionalità, le principali novità della versione 4.4 (Beta) sono :

  • miglioramento della stack di rete con maggiore stabilità nelle connessioni;
  • miglioramenti nel deploy e nel debug (non passerà più un’eternità tra uno step e l’altro);

Per chi lo volesse provare, non è disponibile l’SDK pronto da scaricare ma è necessario ricompilare i sorgenti. Inoltre, non è nemmeno più necessario il Porting Kit (a parte) come nelle versioni precedenti.

Cosa si prospetta per il futuro ?

Si parla di supporto per Visual Studio 2015, introduzione delle API WinRT ed .. udite … udite … supporto per AllJoyn !!

IoT per sviluppatori Microsoft

IoTMicrosoftPodcast

Una delle più grandi iniziative del 2014 è stata sicuramente la nascita di DotNetPodcast, podcast completamente in italiano e dedicato alle tecnologie Microsoft. Gli ospiti sono sempre di altissimo livello e ad inizio anno, ho avuto l’onore di poter registrare una puntata, completamente dedicata all’Internet of Things ed allo sviluppo di soluzioni IoT attraverso il .Net Micro Framework. Ringrazio Roberto Albano, Antonio Giglio e Massimo Bonanni per la fiducia !!

Nel corso del podcast, ho cercato di descrivere in maniera semplice cosa sia un sistema embedded e come siamo abituati a convivere con oggetti di questo tipo quotidianamente. Dalle “cose” si arriva all’Internet delle cose ed alla relativa integrazione con i servizi nel cloud. Per poter permettere a tutti gli sviluppatori .Net un approccio “friendly” a questo mondo, Microsoft offre il .Net Micro Framework per il quale abbiamo a disposizioni numerose board di sviluppo : Netduino (Secret Labs) e le board della famiglia FEZ (GHI Electronics). Nel corso della puntata, ho analizzato l’architettura con relativi vantaggi e svantaggi di questo framework e come sia possibile iniziare a sviluppare (in maniera gratuita a meno dell’acquisto dell’hardware) le proprie “cose” da collegare alla rete.

Curiosi ? Non vi resta che ascoltarmi !  (se vi va)

🙂