Hackster.io “Secure Everything” Hardware Box – Part Three: The MT3620 becomes an Arduino

If you haven’t read parts one and two of the series, I’d suggest reading them for some background. Long story short: I won a raffle and got a box of assorted hardware from Hackster.io in a contest from a Microsoft/AVnet collaboration. The deal was that over 20,000 people (including myself) received an AVnet Azure Sphere MT3620 development board to try to make something interesting with.

See the source image

And, well, sadly, my C/C++ programming skills in the embedded space are almost nonexistent (unless you count Arduino as C). I kept the board online for the 15 days to win the Raspberry Pi, and won the raffle though, so I have definitely got the better end of this deal.

After getting my hardware though, I noticed something quite interesting: This board has a Grove connector and two mikroBus slots. Previously, I didn’t have any devices which used Grove or mikroBus to test with. But now, with a Relay mikroBus Click Board and a whole box of Grove sensors, I wondered if there was, perhaps, a better way to program the MT3620.

It turned out, with some digging, that there was a better way to program it for my purposes. A programmer named Georgi Angelov (aka @Wiz-IO) released a mostly-complete port of PlatformIO to the MT3620. PlatformIO’s basic goal is to add support for multiple ecosystems (Arduino, ESP, Linux) to multiple boards (Arduino, Raspberry Pi, Adafruit Feather). There are obvious incompatibilities (your Arduino isn’t going to support the Linux ecosystem), but it is still a neat attempt at cross-platform embedded programming. By porting the AVnet board with the MT3620 to PlatformIO, it could be possible to write Arduino programs and run them on the dev board.

Of course, I was hooked and began digging through his code. It’s sadly not a complete PlatformIO port, and it hasn’t been updated in a while. Furthermore, it appears (please pardon me if I am mistaken) that English is a second language to Angelov, and so some of the documentation is difficult to understand and is not as clear as it could be. He also has no screenshots of the install process. That didn’t stop me from doing what I could with his code.

I started by installing PlatformIO into Visual Studio Code. It looks quite interesting, no matter what board you are using:

The Avnet MT3620 development board is sadly not one of the officially supported 700+ boards yet. That’s where Angelov’s port comes in. I had to install it manually into PlatformIO, but that was shockingly easy. PlatformIO just lets you paste in a GitHub URL, and it will automatically fetch the custom board information. (I wish all development tools could do stuff like this.) If you are following along, be aware that the original port requires some lines of code to be changed to work on the newer SDKs.

Once installed, you should see something like this:

If you click on the examples tab, you should see this:

Click “Import,” and PlatformIO will soon give you a path to a folder containing the code. Open that folder within Visual Studio Code, and open the src/main.cpp file. Admire it’s Arduino-like syntax:

However, we aren’t out of the woods yet. The SDK platform installs for Azure Sphere has significant issues with the AVnet development kit. This can be fixed according to the Install Notes (which are actually for 19.10 SDKs and higher, not just that particular SDK) with the following instructions:

  1. Close Visual Studio Code. It might overwrite files we’ve changed.
  2. Open the folder C:\Program Files (x86)\Microsoft Azure Sphere SDK\Tools in a File Explorer window.
  3. Open the folder C:\Users\YourUserName\.platformio\packages\tool-azure\azsphere in another File Explorer window.
  4. Select all items in the first folder with CTRL+A, and then drag the items into the PlatformIO folder, while holding down the CTRL key to Copy instead of Move. If File Explorer asks you what to do with duplicates, choose Replace.
  5. Close both windows.

The next step is to open the folder C:\Users\YourUsername\.platformio\platforms\azure\builder\frameworks in a File Explorer window. Open the file common.py and look for this block of code:

See the last lines of the highlighted area? Replace image with image-package and package-application with pack-application as the comments indicate. It should now look like this:

Save and close.

Open up Visual Studio Code again, click the PlatformIO Sidebar rail, and chose “Upload.” If all goes well, it should run the Blink sketch on your MT3620! Please be aware that even though Angelov lists Serial as supported (and has it working on video), I have not managed to get Serial communications to work on any COM port in Windows.

There are some immediate differences with this Blink sketch and the regular Arduino Blink sketch though. The first is the #include <Arduino.h> at the top of the file. Because Arduino is technically based on C and is a (very large) C library, we are importing that into our code. The second thing you may notice is that the code already knows what GREEN_LED, BLUE_LED, and RED_LED are. These are defined in the board variant file, which includes definitions for board-specific variables:

The third, and last thing to notice is that I am setting the LEDs that I want to turn on to LOW, and the LEDs I want to turn off to HIGH. What gives? Well, it’s a quirk with the onboard LEDs on the AVnet board itself. This doesn’t happen with external LEDs. For the board’s onboard LEDs, 0/LOW is on and 1/HIGH is off. This quirkiness is not unique to the Arduino on MT3620 components. This happens even in the Azure Sphere example sketch, which I’ve customized slightly to make the point:

Looking at my example derived from an official example, it would appear that this would turn the LED off for two seconds and on for one second in a loop. Nope. Because LOW is on and HIGH is off for those onboard LEDs, this actually turns the LED off for one second and on for two seconds. So, it’s not Arduino-specific, it’s just the onboard LEDs on the AVnet board in general. Weird. If anyone has any ideas why this is, let me know.

Back to the board though. Now that I had the RGB LEDs blinking on the board, I looked at my Relay Click board. How hard could it be to get running on the MT3620?

MikroE Miscellaneous Relay click front

This relay click board will snap perfectly into one of the two sockets on the MT3620. I opened up the relay’s product page and ran to the pinout diagram.

So, for the left side relay, I need to turn Pin 3 to high to activate the relay. For the right side relay, I need to activate Pin 16 to trigger the relay. But hold on: This is on the Relay board itself. The pins have completely different from the Arduino’s perspective: The pins certainly aren’t the same if you plug the board into, say, Socket #2 instead of Socket #1, or vice versa. How do you find the correct pins?

After some searching, I found the official datasheet for the AVnet MT3620 development board. And it’s right in there:

Looking back at the Click board, I need to activate Pin 3 / CS to activate the left side relay, and Pin 16 / PWM to activate the right side relay. The module name for the left side pin is GPIO34_CSA1_CTS1, and the module name for the right side pin I need is GPIO0_PWM0.

But, alas, I’m not done yet. Every Azure Sphere program has a app manifest, and this app manifest lists every capability your program (or in this case, sketch) has. It’s kind of like a permissions system for Android or iOS. It looks like this in your folder:

Right now, I have GPIO pins 8, 9, and 10 allowed, which are the three onboard LEDs. Using the module names, I know that I need to allow GPIO pins 34 and 0. You may notice the odd “PINX-GPIOY” format. I have no idea what the “PINX” value is for, and it’s not consistently changing with the GPIO value either. We want to match the GPIO value. This is where that avnet_aesms_mt3620.json file (also available here) comes into play. It includes a list of all possible permissions for the board.

For pin 34, I need to add AVNET_AESMS_PIN25_GPIO34 to my app manifest. For Pin 0, I need to add AVNET_AESMS_PIN5_GPIO0 to the manifest. My final manifest looks like this:

With all of that permissions work doing, it’s time to try controlling the Relay click board from the MT3620! Open up main.cpp and let’s add a bit of code to control our relays:

Upload, and with that, I’ve built a relay metronome!

Awesome as this is, there is one little bug: When a new pin is initialized with pinMode(), that pin is automatically set to HIGH, resulting in both relays being turned on until the code turns one off. I’m not sure quite why this is, but it means that the relay momentarily turns both relays on. I just follow up my pinMode() calls with a simple digitalWrite() call to take care of that.

So, what do I have so far? An MT3620 with the ability to package Arduino sketches to run on it, and a working Relay click shield. What about a Grove module? There’s a Grove connector just sitting there. And not just any Grove module with a single-wire signal: A Grove module which uses I2C.

I immediately reached for the best I2C Module in the Grove box: The RGB Backlit 16×2 LCD display. For that module, there is an Arduino library, which I extracted into a convenient libs folder in my sketch.

After this, I had one major problem: the build process couldn’t find Wire.h, which is a pretty common library. Odd. Just as an experiment, I tried downloading a new copy of Wire.h online and putting it in the libs, but it didn’t work. After some researching, I found that PlatformIO comes with a working Wire.h and Wire.cpp in the C:\Users\YOURUSERNAME\.platformio\packages\framework-azure\arduino\libraries\Wire\src folder. It is supposed to be included in the build path, but PlatformIO shows that it is in the build path already, so I am not sure what’s going on. I copied the wire files from there into the root directory of lib and my build succeeded!

I then got excited and immediately wrote some code to do an RGB blinking sequence on the LED, with the RGB onboard light and relay working together.

I uploaded it… and it didn’t work! After some thinking, I realized I forgot to add I2C permission to my app manifest.

With that out of the way, I clicked “Upload” and… well, the RGB Backlight was flashing, showing that I2C sensors were completely workable with Grove! Alas, I made one major oversight: The LCD module needs 5V, whereas the MT3620 provides only 3.3V (as most Grove sensors need only 3.3V, the LCD being the exception to the rule). As a result, even though the backlight works, the LCD could not display any text when I tried due to not enough power. I had a similar issue on the Edison board, so this isn’t a communications problem.

Ladies and Gentlemen, there you have it. An MT3620 development board running an Arduino sketch on a Linux-based OS from Microsoft, controlling a mikroElektronica Relay Click board and an I2C Grove LCD Display. Of course, the possibilities could go on a long way from here. There are definitely disadvantages to programming your MT3620 this way: It’s unfinished, some things like Serial don’t work, and you can’t accept or send many important system calls (i.e. your app can’t receive warnings of an incoming update or reboot, for example). Still, being able to program the MT3620 like an Arduino makes prototyping much easier than writing C++, and I can’t wait to see what I will use the MT3620 for in the future.

Hackster.io “Secure Everything” Hardware Box – Part Two

I finished off with getting both the Intel Edison, Grove Kit, and Ti Launchpad running quite good, but there were some rough edges and more things to discover.

Starting with the Intel Edison: I discovered that the Arduino IDE comes with a huge collection of Intel Edison sample sketches.

I immediately went to WiFi(Edison) > SimpleWebServerWifi. I entered my network info into the sketch and changed the LED from the default 9 to 13 (which is the onboard LED). I tried loading in the IP Address that was printed out in the Serial Monitor, but no connection. I went back to my research and found that the Edison contains an Edison configuration service that uses Port 80. I don’t know the full repercussions, but you’ve got to have some risk in life, and so I disabled that service:

systemctl stop edison_config
systemctl disable edison_config

And with that, I discovered that the Intel Edison is powered by systemd, all the way back in 2016 (when this last release was published, though it probably ran systemd since launch in 2014). It isn’t the happiest systemd though, reporting that it is running in a degraded state. The Edison also has PulseAudio, apparently.

So, with that out of the way, I restarted my sketch, and…

… it worked exactly as it should have, with the LED responding to my web server commands. The code for having the Arduino literally run a simple web server on the Edison is shockingly clean, because the Edison actually pretends to be the official Arduino WiFi Shield:

/*
  WiFi Web Server LED Blink
 
 A simple web server that lets you blink an LED via the web.
 This sketch will print the IP address of your WiFi Shield (once connected)
 to the Serial monitor. From there, you can open that address in a web browser
 to turn on and off the LED on pin 9.
 
 If the IP address of your shield is yourAddress:
 http://yourAddress/H turns the LED on
 http://yourAddress/L turns it off
 
 This example is written for a network using WPA encryption. For 
 WEP or WPA, change the Wifi.begin() call accordingly.
 
 Circuit:
 * WiFi shield attached
 * LED attached to pin 9
 
 created 25 Nov 2012
 by Tom Igoe
 */
#include <SPI.h>
#include <WiFi.h>

char ssid[] = "yourNetwork";      //  your network SSID (name) 
char pass[] = "secretPassword";   // your network password
int keyIndex = 0;                 // your network key Index number (needed only for WEP)

int status = WL_IDLE_STATUS;
WiFiServer server(80);

void setup() {
  Serial.begin(9600);      // initialize serial communication
  pinMode(9, OUTPUT);      // set the LED pin mode

  // check for the presence of the shield:
  if (WiFi.status() == WL_NO_SHIELD) {
    Serial.println("WiFi shield not present"); 
    while(true);        // don't continue
  } 

  String fv = WiFi.firmwareVersion();
  if( fv != "1.1.0" )
    Serial.println("Please upgrade the firmware");

  // attempt to connect to Wifi network:
  while ( status != WL_CONNECTED) { 
    Serial.print("Attempting to connect to Network named: ");
    Serial.println(ssid);                   // print the network name (SSID);

    // Connect to WPA/WPA2 network. Change this line if using open or WEP network:    
    status = WiFi.begin(ssid, pass);
    // wait 10 seconds for connection:
    delay(10000);
  } 
  server.begin();                           // start the web server on port 80
  printWifiStatus();                        // you're connected now, so print out the status
}


void loop() {
  WiFiClient client = server.available();   // listen for incoming clients

  if (client) {                             // if you get a client,
    Serial.println("new client");           // print a message out the serial port
    String currentLine = "";                // make a String to hold incoming data from the client
    while (client.connected()) {            // loop while the client's connected
      if (client.available()) {             // if there's bytes to read from the client,
        char c = client.read();             // read a byte, then
        Serial.write(c);                    // print it out the serial monitor
        if (c == '\n') {                    // if the byte is a newline character

          // if the current line is blank, you got two newline characters in a row.
          // that's the end of the client HTTP request, so send a response:
          if (currentLine.length() == 0) {  
            // HTTP headers always start with a response code (e.g. HTTP/1.1 200 OK)
            // and a content-type so the client knows what's coming, then a blank line:    
            client.println("HTTP/1.1 200 OK");
            client.println("Content-type:text/html");
            client.println();

            // the content of the HTTP response follows the header:
            client.print("Click <a href=\"/H\">here</a> turn the LED on pin 9 on<br>");
            client.print("Click <a href=\"/L\">here</a> turn the LED on pin 9 off<br>");

            // The HTTP response ends with another blank line:
            client.println();
            // break out of the while loop:
            break;         
          } 
          else {      // if you got a newline, then clear currentLine:
            currentLine = "";
          }
        }     
        else if (c != '\r') {    // if you got anything else but a carriage return character,
          currentLine += c;      // add it to the end of the currentLine
        }

        // Check to see if the client request was "GET /H" or "GET /L":
        if (currentLine.endsWith("GET /H")) {
          digitalWrite(9, HIGH);               // GET /H turns the LED on
        }
        if (currentLine.endsWith("GET /L")) {
          digitalWrite(9, LOW);                // GET /L turns the LED off
        }
      }
    }
    // close the connection:
    client.stop();
    Serial.println("client disonnected");
  }
}

void printWifiStatus() {
  // print the SSID of the network you're attached to:
  Serial.print("SSID: ");
  Serial.println(WiFi.SSID());

  // print your WiFi shield's IP address:
  IPAddress ip = WiFi.localIP();
  Serial.print("IP Address: ");
  Serial.println(ip);

  // print the received signal strength:
  long rssi = WiFi.RSSI();
  Serial.print("signal strength (RSSI):");
  Serial.print(rssi);
  Serial.println(" dBm");
  // print where to go in a browser:
  Serial.print("To see this page in action, open a browser to http://");
  Serial.println(ip);
}

Now for the second issue I’ve noticed when using the Edison. Let’s say you have automatic starting of the sketch (from Part 1) turned on. If you edit your sketch on the Arduino IDE and start it, the old auto-started sketch and the new sketch will end up running simultaneously, which will make things quite… interesting, but not exactly fun.

I haven’t figured out an elegant fix for this, but my solution so far is to use the Linux top command to find the process ID of the auto-started sketch, and then kill that process before uploading new code.

In this window, the sketch is process 241. I then just run kill 241 or whatever number in the command prompt to stop the auto-started sketch. I only need to do this when I plug in the Edison after a reboot to upload new code with the IDE. Maybe there’s something I’m missing?

This brings me to my biggest discovery. The Yocto Poky image for the Edison is old. 2016 old. Linux 3.10 old. Some engineers have created an auto-building branch system for much more up-to-date, unofficial images for the Edison at https://github.com/edison-fw/meta-intel-edison and https://edison-fw.github.io/meta-intel-edison/ . These images are, well, unofficial, not necessarily reliable, may break things between releases, and you have to build them yourself on a Linux machine or VM. However, considering the speedily disappearing information about the official release and the fact that the new firmware is 4 years newer, I can put up with that, but I don’t have a Linux dual-boot system at the moment, so I’m going to put that on hold for things to try someday. You may feel differently.

I then looked at the 3D Magnetic Sensor, TLE493D A2B6. Apparently, it has a Cortex M0 processor which could be theoretically programmed, but I don’t really know how this can be done, and the programming language would probably be quite difficult. This sensor works by measuring magnetic force in all three cardinal directions from a small, nearby object (the very small magnetic cube that comes in the box). There’s a neat 3D printed demo of this with a GUI for Windows to demonstrate this:

Neat as that is, I don’t really feel like 3D printing the parts for that demo, even though I have a Original Prusa Mini on the desk. It just doesn’t seem like the best use of plastic. Instead, I got digging and on page 27 of 30 on the sensor datasheet is the link to an Arduino library. I really don’t have any uses for the sensor at this time, but just knowing how to attach it to the Arduino or the Edison greatly improves my odds of using it in the future. (I’m noticing a pattern about how almost all of the equipment I’ve gotten in these boxes can be connected or turned into an Arduino one way or another.) They say that the sensor doesn’t work in “low-power mode” with that library, but I’m looking at the sensor and wondering how much power it would normally draw, especially considering it’s running on regular USB. The library also has convenient links to the datasheets and other sensor information.

In other news, it took a while, but I finally found the MOSFET datasheet. The model is IPT60R028G7. I initially didn’t know what to do with this device, but was stunned to see that it cost $15.80 each on Digi-key, so this was no average MOSFET. I contacted Hackster.io’s Jessica Tangeman to ask what it was for, and it turns out it is a very powerful MOSFET. She sent me a link to all of the amazing projects that could be built with it, and also mentioned some reasoning behind the part selection:

Check out some other projects with the MOSFET – it’s incredibly powerful. https://www.hackster.io/infineon/products/coolmos-c7-gold-sj-mosfet

And yes, it’s the old Intel Edison. They don’t sell them anymore and there are a lot of hardware collector fanatics out there so once the hardware boxes hit the $ value mark, we decided to throw in some extra things for fun.

https://www.hackster.io/contests/SecureEverything/discussion/posts/6448#comment-125080

And, there you have it. I’m still figuring out what I’ll probably build with it, but for now I’m keeping that MOSFET safe and don’t want to lose it!

Read the epic Part Three

Hackster.io “Secure Everything” Hardware Box

Several months ago, the Hackster.io “Secure Everything with Azure Sphere” contest concluded. I didn’t win any prizes, but unexpectedly, I received an email saying that I was one of 20 winners for a box filled with “miscellaneous hardware” worth up to $200. I did not remember signing up for this raffle (neither did other contestants), but I was happy to get the hardware. About a month and a half later, the box showed up at my doorstep with the following parts:

  • Intel Edison with Arduino Breakout Board
  • Grove Starter Kit: IoT Edition
  • Ti Launchpad MSP-ESP432E401Y
  • Avnet SmartEdge Agile with Brainium
  • 3D Magnetic Sensor 2Go TLE493D A2B6
  • mikroBus ClickShield with unsoldered headers
  • Adafruit extra-length Arduino Shield headers
  • MikroElektronika Relay Click Board
  • CoolMOS MOSFET

I had predicted that some of the parts would probably be stock clearance, and Googling some of the parts, it appears that this is somewhat the case. The Intel Edison was discontinued in 2017, the Ti Launchpad is still for-sale (but has a 2017 copyright date on the box), and the Grove IoT Edition was built for the Edison (more on that later). Other parts, like the SmartEdge Agile are new, and the 3D Magnetic Sensor appears quite recent. This blog post is going to be a long guide to everything I learned about these parts in about 24 hours to save you the research if you are using any of these parts in your kit.

Naturally, I first opened up the Edison and plugged the module into the Edison board. It looks like a really powerful Arduino (and indeed has Arduino-compatible headers).

After putting the hardware together, then it came time to research how to get it to do something. I didn’t know much about the Edison, so I got researching and found some useful general information:

  • The Intel Edison runs an Intel x86 processor, running at 500mhz, running an OS called Yocto Poky Linux.
  • The board can be programmed using the Arduino IDE, including the latest release, as an Arduino.
  • The board oddly requires two microUSB cables for programming and flashing. One impersonates a 750MB flash drive for some reason, while the other shows the debug and Serial interface.
  • The barrel jack is Arduino-compatible. I used a 12V 2.5A adapter from a wireless router until I discovered the included one.

My first initiative was to set up the board using Intel’s guide, which sadly is significantly out of date. The main problem is that Intel’s Easy Setup tool was broken due to broken download URLs, which makes the whole setup process unnecessarily difficult. Here’s a rough list of what I did, and all instructions for Windows 10 1909.

Firstly, download IntelEdisonDriverSetup1.2.1.exe and run. This will set up the USB Drivers, even if Intel’s Setup tool won’t recognize it (more on that later).

Secondly, we need to update the board’s firmware. The following instructions are a simplified version of Intel’s instructions. Download the latest Yocto Poky image for the Edison. Unzip to a folder. Next, go to this address and download dfu-util.exe and libusb-1.0.dll, and place them in the same folder as the unzipped Poky image.

Chose the “File” menu in File Explorer, then choose “Open in new PowerShell window.” Run the following commands:

cmd
flashall.bat

This will flash the latest firmware, which will take several minutes.

Example of running the flashall script
Image from https://software.intel.com/en-us/flashing-firmware-on-your-intel-edison-board-windows

Now that the board is updated, you need to download latest Edison Configuration tool and run. First, make sure the Edison is fully connected like the image below:

This installer is partially broken, as it will not detect the USB drivers you set up earlier. However, it will present a window which looks something like this:

Of course, on your window, the password won’t be set and the board won’t be online. Paradoxically, the installer will be able to set up your password, SSH, and networking for your Edison despite saying that it isn’t detected and doesn’t have USB drivers. ?‍♀️ So, obviously, set up your network, password, and enable SSH, then exit the installer.

Now, open the Windows Device Manager, and look under COM/LPT. You should see something like this:

Make a note of that COM numbers next to USB Serial Port and Intel Edison Virtual Com Port. In my case, it’s COM7 and COM4, but yours may vary. Close Device Manager.

Now, download and install PuTTY. This will allow us to login to the Yocto Poky OS installed on your board. Open PuTTY and make the main window look something like this:

Replace the Serial Line option with whatever number you found for USB Serial Port, which in my case should be COM7 (though I typed COM4 incorrectly in the screenshot). Click Open. You will see an empty black window, this is normal. Press ENTER and you will see a login prompt. Sign in with the username root and the password you set earlier. You will now have a Linux command prompt.

This will come in handy later. For now, we want to program this thing like an Arduino. Download and install the latest Arduino IDE, and open it. Go to Tools menu > Boards > Boards Manager, and install the Intel i686 Boards package.

Next, choose Tools menu > Boards > Intel Edison. Then, under port, choose the port that you wrote down for Intel Edison Virtual Com Port. This is not the same port as you used earlier! That was the USB Serial Device port, this is a different one. In my case, it should be COM4. Finally, choose File > Examples > Basics > Blink.

Choose Upload. If everything goes well, your Edison’s onboard LED will begin blinking. Happy to have made it this far?

From this point, you should check out the Edison examples underneath the File menu, as there are examples for Ethernet, microSD cards, and other unique Edison functionality. But I soon ran into a problem. Due to a glitch with the latest (and last) release, Arduino sketches don’t automatically run when you reboot the Edison! Time to fix that, using more thorough instructions based on Intel’s defunct guide.

Using the PuTTY window, enter in the following commands (except for the stuff in <>s):

cd /etc/init.d
vi automateSketch.sh
<PRESS the S key on your keyboard>
#!/bin/sh
exec /sketch/sketch.elf /dev/ttyGS0 /dev/ttyGS0
<Press the ESC key on your keyboard>
:wq <ENTER>
<You should be back at the prompt. If you made a typo, press ESC and type :quit! to exit without saving.>
chmod +x /etc/init.d/automateSketch.sh
update-rc.d automateSketch.sh defaults

With those commands, the sketch should automatically load on boot. One problem I have not solved is that the sketch, when running on power and not connected to the computer, will freeze after exactly 5 minutes or 300 seconds. There are some online forum postings about this (use Google), but I will update this page once I get that fixed myself.

With that, the Edison is fully set up and ready to be used like an Arduino. It’s time for the Grove Kit!

The Grove kit: IoT edition was actually designed for use with the Intel Edison using a program called the Intel XDK. The Intel XDK looked like an impressive piece of software when it was available: It let you easily write smartphone apps which could react to the sensors that were attached to the Edison. This was all built in, and if you browse around in the Edison PuTTY window, you can find evidence of this with the multitude of files with “xdk” in the name.

 Intel® XDK
Image from https://intel-xdk.en.softonic.com

Alas, Intel shuttered the XDK in 2017, and I actually could not find any copies of the XDK online. All I could find were a few dead XDK installers which didn’t work due to broken links. So, I had to make do without the XDK, and wondered how one could use the Grove kit with the Arduino IDE.

It turned out easier than I had anticipated. Grove is well supported within the Arduino ecosystem, and so I could control each sensor using just the IDE and some libraries, which the Arduino IDE can easily install.

After some browsing (it was surprisingly hard to find this page), but I found the SeeeD Wiki for the Base Shield V2. It contains the code and diagrams for wiring together a simple circuit which uses a buzzer and button. It’s an excellent read, and the only change needed to the guide is that instead of using the Seeeduino (a Chinese Arduino clone), just use the Edison!

enter image description here
Image from http://wiki.seeedstudio.com/Base_Shield_V2/

I was surprised that after you snap on the base shield, you can just directly access some simple sensors without using any library:

const int button = 2;       // connect a button
const int buzzer = 3;       // connect a buzzer
void setup()
{
    pinMode(button, INPUT); //set button as an INPUT device
    pinMode(buzzer, OUTPUT);   //set LED as an OUTPUT device
}
void loop()
{
    int btn = digitalRead(button); //read the status of the button
    digitalWrite(buzzer, btn);
    delay(10);
}

The button is in slot 2, the buzzer in slot 3. Despite all of the pins and complications of the Base Shield, there’s no library needed for these simple sensors. What about something fancier though, like the included LCD?

For that, a library is needed, and it’s really best to just look up the part exactly as named on the Seeed Wiki. For the LCD, that’s available here.

The are only two things I’d add to the wiki: The first is that the wiki shows how to download the code from GitHub and add it to the IDE. This works, but there’s a simpler way. Go to Sketch > Include Library > Library Manager, and then search for “Grove.” Simply find your sensor in the list (in this case, the Grove LCD library) and choose Install. After that, just copy-paste an example sketch and try it out.

The second thing I’d add is that the Base Shield V2 comes with a voltage switch for 3.3V or 5V, and is set to 3.3V by default. The LCD and some other sensors require 5V, and so the LCD is blank (even though the backlight is illuminated) if the switch is on 3.3V. That had me confused for a while.

So, overall, that’s the Intel Edison and Grove Kit. I haven’t got to the mikroBus shield yet or the Relay Click board, but I assume that if it’s for the Arduino Uno, there’s probably a good library for it.

Time to shift gears: What about the Texas Instruments Launchpad board? To be honest, I had no idea what to do with it. I first installed the MSP432 SDK, then the Code Composer SDK. I used the On-Demand installer, chose “Custom Install,” and installed only the MSP432 components.

After installing these essential components, I opened up Code Composer, and tried reading Texas Instruments’ guide to making a Hello World program, but… it’s a mess for a hobbyist. It’s like C++, and it’s really, really complex. If this was a professional system, it would be great, but it’s just absolute overkill for almost any hobbyist.

Image from https://processors.wiki.ti.com/index.php/File:CCSv4_IDE_Debug.jpg

Upset, I started looking for anything simpler and found out about Energia. Energia lets you program the Ti board like a really fancy Arduino, and I was instantly sold. I downloaded it and tried it, and… it didn’t work.

It turns out that my board, the Ti MSP432E401Y, isn’t really supported correctly by Energia without some hacking. Using a pile of forum posts, I’ve figured out what needs to be done.

First, download the latest Energia release for Windows. Open Energia, and then choose Tools > Board > Boards Manager. Install the MSP432E Ethernet Red Boards package and the Energia TivaC Boards package. Close the Boards Manager.

Next, open File Explorer and navigate to the following address:

C:\Users\YOURUSERNAME\AppData\Local\Energia15\packages\energia\hardware\msp432e\5.19.0

Edit platform.txt by replacing the contents with the code at my GitHub gist: https://gist.github.com/gjsman/83ef53f1c91d74989a5d403246021489

(I’ve also filed a Pull Request to fix support for the MSP-EXP432E401Y in Energia, but no telling when it will get merged.)

Finally, open Device Manager again, and find the COM port for your Ti Launchpad. The Launchpad oddly has two COM ports, one main and one auxiliary. Both, I believe, should work.

Going back to Energia, change the Board under the Tools menu to Launchpad /w MSP432E (120mhz), and the COM port to your Launchpad. Click the “Open” button, go to “Examples > 10.Multitasking > MultiBlink.”

Click Run, and if luck is on your side, the code will run on your Ti Launchpad. You will notice that three LEDs will be flashing on the Launchpad different rates. One will be flashing 5 times per second, one twice per second, and one once per second. This is a neat demo of the Launchpad’s abilities: It’s actually three separate sketches, each with the similar code to the standard Arduino Blink example, running simultaneously! Each tab in the sketch pile runs simultaneously with the other tabs. Awesome!

And after all of that, I think that is the end to this unnecessarily long blog post. I didn’t touch the Avnet Brainium system, or the Click Shield, or figure out what the MOSFET is for, or the Magnetic sensor, but I hope that this will help those who received the kit to get started and to make some great projects. 🙂

Read Part Two