BeagleBone and Windows IoT core?

Some of you may know that I am the author of the Windows Embedded Board Support Package for the BeagleBone development board.

This board comes with a Texas Instruments AM335x Arm Cortex-A8 processor. I developed the BSP as an open source project with all the source code available online. I have had hundreds of downloads when the site was hosted on Codeplex. And now that I moved it to GitHub I continue to receive regular hits (see my previous post).

This made me wonder if it would possible to port Windows Embedded Core to the BeagleBone platform? It seems Microsoft prefers to work with the silicon vendors themselves with this type of endeavor, and obviously so, as who else knows the chips innards better than the creator. Undaunted, I decided to do a bit of research on my own. Here is what I found.

Documentation: The AM335x technical reference manual for the CPU chip is readily available from Texas Instrument’s download site. Be prepared, it over 3000 pages of nitty-gritty detail on every subsystem available on the chip. While doing the Windows Embedded Compact (WEC) BSP port, I found this information to be invaluable.

The Windows IoT Core documentation is another story. Microsoft publishes a lot of really good information on building IoT core images with its IoT Core manufacturing guide. This is good information for customizing images and doing things like adding or removing drivers etc. but it assumes and already developed base BSP. There are a few established BSP’s for the other, already supported, IoT Core platforms and these can be valuable templates to get started. BSP’s of note are the Raspberry Pi, Intel Joule and the Qualcomm DragonBoard 401C. The Joule is not an ARM platform so that leaves it out. The source for DragonBoard’s BSP was not available at the time I was looking. Maybe if you sign an NDA with Qualcomm …but good luck with that. Be aware some BSP’s are only available in compiled form. This means you can uses add and remove drivers but you don’t have access to the actual driver source code. Be warned, most vendors are quite protective of this information and if you ask for it, they will usually give you the runaround. I don’t know how many times I have asked the vendor for BSP information and they will say you have to go to Microsoft. If you ask Microsoft they will say you have to go to the vendor. There is a nasty term for this but I wont use it here. The one BSP that is a good reference and is available in source is the Raspberry Pi. The code is available here.

Boot Code: Windows IoT Core requires EFI start up code. EFI is kind of a universal start up code. You can describe it like a next generation version of U-Boot. UEFI as it is generally known is an open source project, started by Intel to support booting its x86 based products. It was originally designed as a replacement for BIOS which dates back to the original PC days. UEFI is also available for ARM and this is what is used to boot Raspberry Pi. The Raspberry Pi start up code is unique because the ARM A53 core is actually a slave processor of the video core processor. This leads to some weird start up code for the BMC2835 chip. The later generations based on the BMC2839 chip may have changed this a bit.

Can the BeagleBone use UEFI? Absolutely, but I don’t know if anyone has actually done a port. I know the original BeagleBoard (AM3730) does have a UFEI port, and a mater of fact, it is used as one of the reference platform showing how UEFI runs on ARM. Virtually all Linux/Android BeagleBone OS’s boot with U-Boot so you don’t see much interest in a UEFI port.\

Gotcha: So here is the blocker. The TI AM335x interrupt core is a TI design. TI did not use the standard ARM based Intellectual Property (IP) core for the interrupt controller, they decided to do the design themselves. This is not unusual, many vendors that have purchased the full ARM architectural license go their own way for one reason or another. They may have some special peripheral they need to interface to, maybe they felt they could just do it better, maybe the interrupt IP from ARM was not available at the time, or maybe they just did not want to purchase it. Who knows?

But here is the bottom line: Windows IoT Core’s interrupt processing is baked into the core OS code and it assumes the standard ARM’s IP for the interrupt controller. There is no way around this fact that I have found. It would require some fundamental rewiring of the Windows kernel to get this to work and only Microsoft would have the resources needed to do such a port. I see no desire on MS’s part to support a part that is already past its prime in light of the fact there are so many newer, more powerful, parts coming on the market every day.

If anyone knows how to overcome this hurtle please let me know.

In the mean time I am looking another platform as a possible candidate…..stay tuned.

 

 

Connecting AndroidThings to Azure IoT part 2

In the previous post I showed how to develop a simple AndroidThings project and deploy it to a Raspberry Pi device. The project sends temperature and humidity sensor reading up to the Azure cloud.

In this post I will show how to consume sensor data in the cloud and publish it to a Power BI dashboard for real-time visual representation. I will start by going back to our Connect The Dots example IoT project. I will add another Azure Streaming Analytics resource to our Connect The Dots resource group. An Azure Streaming Analytics (ASA) job allows for near real-time analysis on “hot” streaming data from a variety of IoT devices. In our case we will be taking input data from our IoTHubStream  (originating from our Connect the Dots IoT hub) and splitting off sensor data and feeding it to the Power BI service as an output (Power BI service being the destination endpoint). Provisioning input and output streams is actually quite easy as Azure is already aware of the existing IoT hub from the resource group and many of the services and selections are just point and click. Here we just show one input, the IoTHubStream and one output, the Power BI service. Of course we could add more …like adding a database as an output sink but lets keep it simple for now.

ASA allows for a “SQL like” query language to condition the data streams. I will use a simple script to direct the sensor data to the output sink.

ASA has additional features that allow you to exercise your query with “test” data. You can actually upload a test json data file or capture a segment of data from the live stream.

If all is set you can start the service and client and hopefully you will see the input and output monitoring graph update as shown above.

The final step is to import the streaming data into a Power BI dashboard. When we set the output in ASA we associated it with our Power BI online account so after logging in and opening the Power BI web service we should see our dataset prepopulated:

From here we can create a new streaming dashboard and populate it with “tiles” that dynamically update.

Fantastic! A streaming dashboard that shows, in real-time, temperature and humidity as originating from an AndroidThings device!

Connecting AndroidThings to Azure IoT part 1

I decided to take a minor detour on my path to using .NET embedding on an AndroidThings device.  As a “get familiar” exercise I decided to connect my Raspberry Pi AndroidThings device to the cloud by using the IoT features of Microsoft Azure. I had previously set up the Connect the Dots  IoT project as another learning exercise so most of the backend Azure stuff has already been provisioned. I added another client device to the Connect The Dots IoT hub named “MyAndroidThingsDevice”.

I then created an empty AndroidThings Android Studio project. I used bits and pieces from the sample IO projects as a starting point. I made sure I had a working “things” Java project that toggled a LED on and off every second running on my Raspberry Pi device. From here I added more Java code from the Microsoft Azure Java IoT SDK  device sample. The SDK has several sample projects that illustrate various aspects of connecting and provisioning an Android client device to the Azure cloud. Merging the two samples allowed me to construct an IoT message for a simulated temperature and humidity sensors which reported to the IoT hub every second. This was also the LED toggle rate so I had a visual indication every time the message was sent.

Here is the code for the start up activity class:

package com.example.davidvescovi.myapplication;

import android.app.Activity;
import android.os.Bundle;

import com.microsoft.azure.sdk.iot.device.*;

import com.google.android.things.contrib.driver.button.Button;
import com.google.android.things.contrib.driver.button.ButtonInputDriver;
import com.google.android.things.pio.Gpio;
import com.google.android.things.pio.PeripheralManagerService;

import android.os.Handler;
import android.util.Log;
import android.view.KeyEvent;

import java.io.IOException;
import java.net.URISyntaxException;
import java.util.ArrayList;
import java.util.List;

public class MainActivity extends Activity {
    private static final String TAG = MainActivity.class.getSimpleName();
    private static final int INTERVAL_BETWEEN_BLINKS_MS = 1000;
    private static final String CONNECTION_STRING = "";
    private static final String deviceId = "MyAndroidThingsDevice";
    private  static final int D2C_MESSAGE_TIMEOUT = 2000; // 2 seconds
    private  static List failedMessageListOnClose = new ArrayList(); // List of messages that failed on close

    private Handler mHandler = new Handler();
    EventCallback callback = new EventCallback();
    private Gpio mLedGpio;
    private boolean mLedState = false;
    private DeviceClient client;
    double temperature = 0.0;
    double humidity = 0.0;
    int id = 0;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        Log.i(TAG, "Starting BlinkActivity");

        PeripheralManagerService service = new PeripheralManagerService();
        try {
            String pinName = BoardDefaults.getGPIOForLED();
            mLedGpio = service.openGpio(pinName);
            mLedGpio.setDirection(Gpio.DIRECTION_OUT_INITIALLY_LOW);
            Log.i(TAG, "Start blinking LED GPIO pin");
            // Post a Runnable that continuously switch the state of the GPIO, blinking the
            // corresponding LED
            mHandler.post(mBlinkRunnable);
        } catch (IOException e) {
            Log.e(TAG, "Error on PeripheralIO API", e);
        }

        try {
            client = new DeviceClient(CONNECTION_STRING, IotHubClientProtocol.MQTT);
            client.open();
        } catch (Exception e) {
            Log.e(TAG, "Error on Azure API", e);
        }

    }

    @Override
    protected void onDestroy() {
        super.onDestroy();
        // Remove pending blink Runnable from the handler.
        mHandler.removeCallbacks(mBlinkRunnable);
        // Close the Gpio pin.
        Log.i(TAG, "Closing LED GPIO pin");
        try {
            mLedGpio.close();
        } catch (IOException e) {
            Log.e(TAG, "Error on PeripheralIO API", e);
        } finally {
            mLedGpio = null;
        }
        // Close the Azure connection.
        Log.i(TAG, "Closing Azure hub connection");
        try {
            client.closeNow();
        } catch (Exception e) {
            Log.e(TAG, "Error on Azure API", e);
        } finally {
            client = null;
        }


    }

    private Runnable mBlinkRunnable = new Runnable() {
        @Override
        public void run() {
            // Exit Runnable if the GPIO is already closed
            if (mLedGpio == null) {
                return;
            }
            try {
                // Toggle the GPIO state
                mLedState = !mLedState;
                mLedGpio.setValue(mLedState);
                Log.d(TAG, "State set to " + mLedState);

                if (client != null)
                {
                    id++;
                    temperature = 20 + Math.random() * 10;
                    humidity = 30 + Math.random() * 20;

                    String msgStr = "{\"deviceId\":\"" + deviceId +"\",\"messageId\":" + id + ",\"temperature\":"+ temperature +",\"humidity\":"+ humidity +"}";
                    Message msg = new Message(msgStr);
                    msg.setProperty("temperatureAlert", temperature > 28 ? "true" : "false");
                    msg.setMessageId(java.util.UUID.randomUUID().toString());
                    msg.setExpiryTime(D2C_MESSAGE_TIMEOUT);
                    client.sendEventAsync(msg, callback, msg);
                }

                // Reschedule the same runnable in {#INTERVAL_BETWEEN_BLINKS_MS} milliseconds
                mHandler.postDelayed(mBlinkRunnable, INTERVAL_BETWEEN_BLINKS_MS);
            } catch (Exception e) {
                e.printStackTrace(); // Trace the exception
            }
        }
    };

    protected static class EventCallback implements IotHubEventCallback
    {
        public void execute(IotHubStatusCode status, Object context)
        {
            Message msg = (Message) context;

            System.out.println("IoT Hub responded to message "+ msg.getMessageId()  + " with status " + status.name());

            if (status==IotHubStatusCode.MESSAGE_CANCELLED_ONCLOSE)
            {
                failedMessageListOnClose.add(msg.getMessageId());
            }
        }
    }
}
<span id="mce_marker" data-mce-type="bookmark" data-mce-fragment="1">​</span>

If you use the code be sure to substitute your connection string.

If everything compiles and runs you should see the LED blinking. You can use the “Device Explorer Twin” utility to monitor messages going back and fourth between the device and Azure. You should see something like this on the MONITORING tab:

In my next post I will show how to use Azure Streaming Analytics and Power BI to visualize the AndroidThings temperature and humidity data.

 

Android Things with .NET embedding part 2

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.

 

Android Things with .NET embedding Part 1

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.

 

 

Intel discontinues maker development boards

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.

 

 

Codeplex WEC BSP migrated to GitHub

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.

 

First Post

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.

Hello world!

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