So the obvious first step was to get Android Things up and running. I had to load Android Studio which also adds the Android SDK and optionally the NDK (for use with native C/C++ development).

I already had the Android SDK installed with my Visual Studio 2017 setup as part of the Xamarin/Android support plug in. Microsoft seems to want to install the Android SDK under “C:\Program Files (x86)\Android\android-sdk” which I found out the hard way has issues under some scenarios. It seems a lot of the utilities and batch files still do not like the spaces in the path. So I let Android Studio install another copy of the SDK under C:\Android\sdk. The NDK installs under C:\Android\ndk. The SDK and NDK combined are quite large, several tens of gigabytes as a matter of fact, and having two copies chews up lots of disk space. I did find out later it is possible to “retarget” where Visual Studio looks for Android SDK so I can probably remove the MS installed version.

Having installed all the tools it was now time flash the factory image and try some sample programs. I am targeting my Raspberry Pi 3 hardware which I previously had Windows IoT core running on.

The Android Things samples include functions that exercise the standard inputs and outputs. Things like blinking an LED for GPIO output and reading a push button for GPIO input.

Of course these samples are written in Java as it is the most popular development language among Android developers. But as you move into the embedded space  you see more developers prefer C/C++ as its much more hardware friendly. I, myself, prefer C# as it provides the best of both worlds. It is object oriented and the syntax is very much “C” like.

.NET Embedding allows your existing .NET Code (C#, F#, and others) to be consumed from other programming languages and in various different environments.

This means that if you have a .NET library that you want to use from your existing iOS app, you can do that. Or if you want to link it with a native C++ library, you can also do that. Or consume .NET code from Java.

I will attempt to do the latter using Java running on an Android Things device. Stay tuned for part 3.

Seems like everyone is jumping onto the IoT bandwagon. Several months back Google announced “Android Things” as part of its foray into the IoT world. While at first glance it may look like they just rebranded Android to attract a wider audience, a deeper dive does reveal some unique characteristics. For example, Android Things supports “headless” operation (i.e. no local display), essential for IoT but pretty much unheard of for the standard Android deployments. Also, Things is supported on smaller, low cost platforms like the NXP i.MX6UL, an “Ultra Light” low cost platform and the ever popular Raspberry Pi.

Google is also supplying a hardware BSP (with updates) and an extensive development SDK. The SDK is a modification of the Android SDK so, for developers, it may be worth becoming familiar with the differences.  Here is a link to an overview of the differences between the Things SDK and the standard Android  framework.

Of course Google is, and will be, rolling out its cloud based backend support portfolio on a continuing basis. But for developers the default language of choice is still Java.

So what does all this have to do with .NET as the title suggests? Well this got me thinking about an interesting convergence of technologies. Microsoft and Xamarin recently announced .NET embedding which allows developers to code in C#, use the .NET framework and target consumer languages … like Android Java.

I have an interesting experiment in the works … stay tuned for part 2.

Without much fanfare Intel has discontinued three of its IoT development boards. See https://software.intel.com/en-us/iot/hardware/discontinued

These are:

The Galileo Board:

The Edison module:

and the Joule:

Windows IoT Core was available for all three platforms at one time or another. I believe the Galileo was one of, if not the first, platforms Microsoft targeted its Windows IoT Core initiative against. This platform was getting quite “long in the tooth” so it is understandable that this one was on the chopping block. As for the others, its not quite so clear. Having worked in this industry for over thirty years and having been burned by Intel on more than one occasion, I have come to this conclusion:

Don’t believe what the salesmen tells you about availability or long term support. There is only one absolute: “They will continue making it as long as they continue making money on it.”

One other note was the speed at which they shut down production. Just a few months from the announcement till EOL (End Of Life).

Obviously this must be a blow to Microsoft’s IoT strategy. The platform selection was already quite narrow with way too much emphasis put on the Raspberry Pi platform. Hope MS puts some more resources behind expanding the development platforms or IoT Core may go the way of the dinosaur also.

As some of you may know I am the developer of a free open source board support package for the popular BeagleBone development board. The BSP targets development with Windows Embedded Compact 7 and Windows Embedded Compact 2013. I hosted the source code on Codeplex. Unfortunately Codeplex was targeted for shutdown by Microsoft.

Thankfully, Codeplex provided some guidance on how to migrate a Codeplex hosted site to GitHub.  I migrated the source code and documentation to the new site here.

While the site might look a little thin it does have all the original source code as well as the documentation. I hope this helps and let me know if you spot any issues.

So this is my first blog post on the msmvp.com site.

As an embedded MVP for the last 10 years I will be posting mainly on embedded devices and experiences. Check back often for the latest commentary.

Welcome to Microsoft MVPs. This is your first post. Edit or delete it, then start blogging!