NETMF at \Build
There is a lot of news coming from Microsoft's \\Build conference going on this week. Much of this is around Windows 10, Office 365, HoloLens, and other large investments. In the IoT space, the focus is on the announcement of Windows IoT Core (code named Athens) which is the Windows core applied to embedded devices. Of special interest is IoTCore running on the Raspberry Pi. Although we are not the biggest news item at the show, NETMF does have a significant presence as part of the overall platform solution offerings for the Internet of Things. We decided to specifically showcase some of the new things that we are working on for 4.4. At the QuickStart labs, attendees can get hands on experience with a number of technologies. For the new Windows IoT Core, attendees can program a weather app and send data to Azure with a Raspberry Pi running IoT Core and a weather shield . IoT Core includes extensions to the WinRT (UAP*) namespaces for APIs that were not needed in Windows apps before (GPIO, I2C, PWM, SPI, Analog IO,...) With 4.4, NETMF is adding support for these same WinRT namespaces (and more as time goes on). So in the QuickStart labs, the attendees can also program a new Netduino 3 WiFi board with the same weather shield using the same APIs. Our goal for the labs was to use the exact same instructions for both and the only significant differences turned out to be the result of the NETMF lab using Wifi instead of Ethernet.
In addition to the labs, there is a NETMF demo in Steve Teixeira's IoT keynote on Window's IoT Core. Unfortunately, this demo, which had been solid all week, failed on stage. For some reason, the phone lost the Alljoyn connection. The way the demo did work is that he 'ask's' a Windows phone whether there are any NETMF devices present. When it relies that there are, he asks for the temperature in the room and it tells him the temperature. Finally he tells the NETMF device to send that data to the TV. The temperature shows up on the TV display. There are several interesting technologies in this demo. First, the communication is set up using Alljoyn. In 4.4, NETMF will have an implementation of the AllJoyn Thin Client. Microsoft is a member of the Allseen alliance and Alljoyn will be support in all of the Microsoft platforms. Alljoyn allows for devices to 'advertise' their presence and their 'type' and for other devices to find and consume the services that they offer. With Alljoyn supported on all the Microsoft platforms and a growing number of other devices like the LG TV we used, setting up flexible and dynamic connections between devices is really easy. This same demo that is in Steve's talk is in a booth dedicated to the Alljoyn story at Microsoft.
The other technology that I think is killer is the voice support in Windows 10. Steve made a call to not utilize the Cortana portion of the demo in his talk because there had been so much already shown on Cortana but I think this is something of particular interest in small devices. UI is often a challenge on these devices. You may decide to not have any UI on your device but that misses the opportunity to impact it's functioning externally or to query it. You could elect to put buttons and LEDs on it but that is an inflexible option and not that informative. You could opt to put a touch display on the device. This improves the flexibility of the interface but it is also expensive. Voice is extremely flexible and as easy to change as modifying the Voice Command Definition in XML. There is not any explicit support for voice or Cortana in NETMF yet but with the voice capabilities on a Windows phone and Alljoyn, it is easy to implement this kind of command and control where small devices are integrated with higher end platforms.
During Channel 9 interviews, Pete Brown and Steve Teixeira highlighted the work that GHI is doing to improve the Raspberry Pi connectivity to modules and the new Netduino boards.
What does all this add up to? For a number of years, the Microsoft platform story was fragmented. There was Windows, Mobile, Windows Compact Edition, and NETMF as separate platforms specific to their target devices. These platforms were even in different organizations inside Microsoft further fragmenting the messaging. Now all of these technologies are in the OSG group with the direct intention of creating a powerful IoT platform suite. With UAP (now UWP) and architectural work in Windows core, the current story is Windows Standard, Windows Mobile, Windows IoT Core, and NETMF- three of the platforms are built from the same code. In the NETMF team very focused at this point to making sure that our platform for the processors that can't run one of the full OS options is still highly compatible and well integrated with them. Our two goals going forward are convergence with the rest of Windows development experience and increasing the range of applications that Microsoft has solutions for in the MCU space by increasing our performance and decreasing our memory requirements. We continue to build the team to do all this with a larger investment than the platform has had in years.
Let us know what your thoughts are on all these changes. We're looking forward to an exciting year.
* I am using the UAP acronym because it is probably more familiar to everyone but with \\Build, this has been renamed to the Universal Windows Platform (UWP)
Comments
Anonymous
May 01, 2015
Thanks for the update! Do I understand it correctly that AllJoyn tries to address the same thing the DPWS stack does and is DPWS going to be deprecated in NETMF in favour of AllJoyn?Anonymous
May 01, 2015
So much great news for .NET Micro Framework from BUILD. Thanks for sharing this with us, Colin. And thanks to the whole team for continuing to make NETMF an amazing platform for microcontrollers and makers!Anonymous
May 01, 2015
Hi Jan, Alljoyn is the future direction. Is anyone concerned if we deprecate DPWS? I haven't heard much about that interface for a while.Anonymous
May 03, 2015
For us it is just too little too late... Even the today's news, albeit exciting, are still just more of the future plans whereas we need a platform that can be used in commercial applications today. Reliably! After having dealt with major network stability issues in NETMF we have abandoned the platform and moved on to Linux. It's a real shame, because we really wanted to use NETMF to leverage our knowledge of C#, Visual Studio and other familiar technologies. Alas, the product has to be used in the real world and rebooting the board 5-10 times per day due to a locked up network stack was just too much to bear. I hope that NETMF will rebound and turn into a solid platform and who knows, maybe we will give it another try sometime in the future, when that future is finally here. So long and good luck.Anonymous
May 03, 2015
Colin, are you aware that demo activities are expected to fail perhaps one time out of one hundred? It is considered to be normal in the regular computer (read too big to carry market). What happened should be considered a lesson in not trusting Murphy to keep his hands off of something.Anonymous
May 04, 2015
I would like to know why are you not fixing any of those bugs reported on codeplex? It looks like you have completely forgot about them. Could you please provide any comments?Anonymous
May 04, 2015
Hi Imn, We are fixing bugs and perhaps we should have made more noise about that at \build. The 4.4 beta that we put out a few months ago was the first set of fixes. It included addressing stability issues in the WiFi stack and performance and reliability in deployment and debugging. These were the two biggest issues we saw. We continue to work through the rest of the list. Are there any specific bugs that you are concerned with that you want to see addressed immediately?Anonymous
May 04, 2015
Hi Gregg, Yes, I know that demos are fraught with risk. No one wants so see features that have been available for some time so we tend to demo what we are working on. Still, you never want to see the demo fail to communicate the work we are doing.Anonymous
May 04, 2015
What about to improve the performance of NETMF. (Native compilation or JIT?). Without this it is too limited for real commercial use cases... If this is not a planned feature, then better you focus on Windows 10 Core IoT...Anonymous
May 04, 2015
Hi Alex, This is on the list of things we are looking at. No dates at this point. I agree that performance is a key opportunity for us. We want to make sure we have a solution for MCU class devices as well as devices that can run Windows.Anonymous
May 04, 2015
Colin, I think that community would really appreciate seeing bug list on codeplex being reduced. For example, you could sort bugs by received the most votes and go one-by-one fixing them. Personally, I would like to see #2179 and #2194 (can be merged with #2067 and #2066) addressed first.Anonymous
May 05, 2015
Good suggestion Imn. Our plan, as announced with the GitHub move, is to vet the issues and move them over to GitHub as we replicate them. We can certainly do this in order of the votes. I'll solicit any additional input.Anonymous
May 06, 2015
I have attended most of the Iot sessions at Ignite, disappointed to see lots of slides/talk about RTOS support on ARM as an Iot agent, not one slide or talk mentioned netmf, even when asking the presenters they seemed confused between the micro and compact framework.Anonymous
May 06, 2015
Hi Colin, I'm curious how NETMF relates to UWP. We've seen the new "device families", will the NETMF be part of one of them (e.g. the "(headless) IoT family")? Or will it stay a separate API, with only some aligned namespaces?Anonymous
May 06, 2015
Hi Colin, we know now that there will be something called "device families" for UWP apps, will NETMF be part of the "(headless) IoT family"? Will we be able to have one code-base for win10 UWP apps and NETMF, or will only some namespaces be aligned?Anonymous
May 14, 2015
I guess I have to agree with Alex O. After 30 years of embedded development I have heard this story many times before (I have even given similar talks and demos a few times). I guess I really don't see the business value of running a very proprietary piece of software (Windows 10 core) on a very proprietary piece of hardware (Raspberry Pi) just to turn on a light?. The only compelling idea I see coming out of this is the core running on embedded Linux, at least with that you have the power to tailor your custom hardware and not be dependent on MS to catch up. Raspberry PI is already yesterdays news, Raspberry Pi 2 is out with a much more powerful core ...but don't try to find any info on the SoC its proprietary too.