Microcontrollers and IoT

Menu

Arduino

In a previous blog post I was describing an example of how a Spark Core can be used to read weather sensors. The setup was really no different from any simple Arduino Uno setup. It only demonstrated how easy it is to port Arduino Sketches to a Spark Core.
With the integrated WLAN I was interested to connect the Spark Core to the internet cloud. One of the simplest ways I found, was using Google’s Spreadsheet service. I stumbled over this idea in this Spark forum post.
Here is how it works: a Google Script is periodically reading data from the Spark Core via the RESTful Spark API and then appends the data to a Spreadsheet. The code below is a minimalistic Spark code to test the such a setup:

However when I setup a time trigger to run the script in regular intervals I found the setup to be very unreliable. This is discussed and documented by several Spark Users and as of this writing I have not seen a fix for this problem.
One thing to note is, that this approach is pulling data from the Spark Core rather than the core pushing them to the cloud. This has a significant flaw as we cannot put the core into standby between the measurement intervals. Therefore this solution is anyway not a good choice for low power applications.
So stay tuned, I am experimenting with a better solution that I will blog about in my next post.

In my previous blog post I described my first encounter with the Spark Core. Today I want to demonstrate a first simple code example. For this I connected the Spark Core to a Weather Shield from Sparkfun. The shield offers sensors for light, humidity, temperature and pressure. It can even be extended with rain and wind sensors as well as GPS.
.The shield comes with a nice set of libraries and examples that I used as a starting point. To keep things really simple, I combine the entire Weather Shield source with the sensor library functions and the setup() and loop() into a single file. This did not take long and compiled quickly. I also removed the wind and rain related functionality as I did not plan to use those. The source code below takes measurements every second and writes the them to the USB serial port.

For debugging I used the Serial Communication link over USB. Windows users have to install a COM driver. However, MAC and Linux support the Spark Core USB functionality out of the box.
I was really pleased to see how well the Spark Core supports Arduino libraries and well written legacy code. With only a few code modifications I had the sensors up and running.
The setup is now streaming values over a USB cable to a PC. There I captured the values with Tera Term and created a Weather Graph from the comma separated values (CVS). The example below shows the pressure curve of a Bay Area Storm passing by at end of February 2014.This setup is a somewhat trivial example that a basic Arduino can also do. The project really does not take advantage of the Spak Core’s connectivity to the internet. So stay tuned for my next blog post where I will add internet connectivity to the setup.

I have tested several IoT platforms over the last couple of weeks. So I was not too keen to checkout yet another one. However, when I got the annoucement that the Spark Core is shipping I could not resist and ordered one. It arrive in the mail today so I thought I will take it for a spin.
The Spark Core comes in a very stylish little box.
Figure1: Spark Box
To my surprise the box did even includes a breadboard:
Figure 2: Open Spark Core Box
Overall, the box contains the Spark Core board, a breadboard, a micro-USB cable and Spark sticker.
Figure 3: Box Content
It is amazingly simple to get the board up and running. By following these few simple steps:

Download the Spark App for iPhone or Android

Setup an account by register at spark.io

Power up the Spark Core over the USB cable

Start Spark App and log into your wireless network

If everything works well you will get rewarded with the RGB-LED on the Spark board flashing in rainbow colors. Once the Spark Core is connected to you WiFi and paired with the Spark cloud, it took me only a few minutes to get an on-board blue LED blinking.
It very quickly becomes obvious that the Spark team has done a great job setting up an entire end-to-end IoT solution consisting of:

Spark Hardware

Cloud based IDE

Arduino compatible API

Free for life cloud back-end service with a RESTful API

All the Spark Core software is open source. The board uses a CC3000 WiFi Module from TI combined with a 32-bit ARM Cortex-M3 powered STM32F103 from ST Microelectronics. The Spark team has come up with a nice integration of this hardware and the cloud server back end. It is based on the CoAP protocol specification and allows for an easy and energy efficient integrated IoT solution.
The cloud API offers over-the-air (OTA) firmware updating where the input can either be c/c++ source code or binaries. For those that don’t want to use Spark Builder, their cloud based IDE the web site also promises support for desktop IDEs like Eclipse.
So much for today, I will cover more details in future blogs.

There are a lot of WiFi solutions for Makers out there. However many are either expensive, big or outdated. So it is refreshing to look at the technical data of the little known WiFi module available by the name of RTX4100 from RTX Telecom. You may never have heard of RTX Telecom but this Danish design service company specialized in wireless has been around for many years. The module is hardly bigger than a Bluetooth module.
Figure1: on the left a simple Bluetooth HC-5 module and on the right the RTX4100 WiFi Module.
The RTX41xx uses latest WiFi System in a Package (SiP) technology. It features a Nordic Semiconductors 32-bit ARM Cortex-M3 based low power microcontroller. The WiFi is based on a AR41xx SiP from one of the leading WiFi chip manufacturer Qualcomm – Atheros.
The 32-bit application processor is responsible for all the WiFi driver related duties. But an API allows to program custom application into the module. RTX calls the custom programs Co-Located Application or CoLA. Besides the RTX4100 that offers 24 kBytes flash memory and 3 kBytes RAM for custom applications. RTX also offers a pin compatible RTX4140 that provides much more programmable memory for CoLA applications, 512 kBytes flash and 64 kBytes RAM.
The SDK can be downloaded from RTX’s web site together with a comprehensive set of documents and CoLA examples.
On the Hardware side the module offers 30 solder pins that support a variety of I/O functionality:

ADC ports, DAC ports

GPIO ports

UART, SPI, I2C

Timers

RTX has also teamed up with some cloud services. The currently supported cloud partners are: 2lemetry, Exosite, Nabto and Sensinode.
For simple applications like WiFi sensors or actors that require a limited set of IOs and CPU/Memory resources RTX41xx modules can be used stand alone. They are also a great choice for embedded projects based on Arduino that need WiFi. Similar to some of the popular Bluetooth modules you only need a spare UART or SPI interface to talk to the RTX4100.
Unlike Electric Imp that offers you a fully integrated platform form the module all the way up to the cloud, RTX is a much more open and flexible platform where you retain control. However this control also comes at the price that you have to do more software work. The good news is that you don’t have to start from scratch, RTX supports you with quite a bit of Software.

The Galileo is a great single board computer. However one thing that makes the board even more attractive is the simple support for WiFi. This blog outlines the steps necessary to get Galileo with WiFi working.
According to post in the Intel forum Galileo will work with the Intel Centrino N135 and N6205. However after reading the great post from Sergy I could not resist the temptation and got a Intel® Centrino® Advanced-N 6235 card from a local computer store. I then also had to get a pair of antennas and the half mPCI card extender.
Here are a few things you need before you start:

A computer with the Arduino IDE for Galileo installed

A network router with a DHCP server running

An Ethernet cable to connect the Galileo board to your network

An empty SD card or USB thumb drive

As my WiFi card is not supported out of the box I had to add the driver and firmware support. Here are the steps to do this:
(Note: instead of booting from a microSD card, you can also use a USB thumb drive and a USB-to-microUSB OTG-adapter cable). This is not advertised widely, but see Galileo forum post for details

While searching for some STM32 related data I cam across the Cortino board by Bugblat.
Like my Olimex featured in an earlier blog post this board uses a STM32F103 based 32-bit ARM Cortex-M3 CPU. The Cortino board looks like a nicely done Arduino variant. It even includes a FTDI chip. Although Bugblat does not provide support for the Arduino IDE software their product page offers a good overview of available 3rd Party IDEs.
Like for the Olimex, it should not be too difficult to adopt the Maple IDE from Leaflabs. However the Mable IDE is now getting a bit dated. A more current Arduino 1.5.5 IDE can be created by using the instructions on Makerlab.me’s web page . Note unless you are fluent in Chinese you have to use Goggle Translate. However the code is documented in English and available from Github. For those that want to learn more about the details of supporting a new board there is a good document available on Arduino.cc Arduino IDE 1.5 3rd party Hardware specification. Another alternative for Mac users is the OS X native Xcode IDE as offered by embedXcode.

I am interested is to compare Galileo and other DIY single board computers. In this post I want to analyze the Galileo board against the popular Rasberry PI. The first thing to note is that the Rasberry PI is not an Arduino compatible platform. However, there are now extension boards available that allow to use Arduino shields with Raspberry PI. Here are to examples: The first is the AlaMode for Raspberry Pi the second is the GertDuino: Add-On Board for Raspberry PI . Both boards are priced in the range of a Rasberry PI. So the combination of a Raspberry PI with an Arduino shield extension puts this solution right where the Galileo board is.
Have a look at the table below. It compares the two single board computer’s hardware. The technical data for the Raspberry PI are taken from WikiPedia.

Rasberry PI Model A

Rasberry PI Model B

Intel Galileo

Target price:

US$ 25

US$ 35

US$69

SoC:

Broadcom BCM2835 (CPU, GPU, DSP, SDRAM, and single USB port)

Intel Quark X1000

CPU:

700 MHz ARM1176JZF-S CPU

400MHz 32-bit x86 Pentium Class CPU

GPU:

Broadcom VideoCore IV @ 250 MHz

none

Memory (DRAM):

256 MBytes (shared with GPU)

512 MBytes (shared with GPU) as of 15 October 2012

256 Mbyte

PCIe ports:

none

PCIe 2.0

USB 2.0 ports:

1 Host

2 Host (from LAN9512)

1 Host,
2 Device

Video input:

A CSI input connector allows for the connection of a RPF designed camera module

The Raspberry PI uses a SoC chip that was originally designed for the set-top box market. Therefore it shows a nice lineup of features on the video side. The integrated HDMI port and on-chip graphics accelerator are testimony to this. However for IoT applications the Quark X1000 SoC used by Galileo offers a really nice selection of interfaces.

In my last post I touched on Galileo’s shield interface implementation. Having experimented with a few shields sitting in my drawer, I realized that the implementation of the Arduino shield interface creates a bit of a challenge. So before you assume that a shield is plug-and-play do your homework. Like with a vintage car they may need some tender loving care.
Here are a few key criteria that you want to check:

Hardware

Does my shield draw a lot of current: the Cypress CY8C9540A 40-Bit I/O Expander is only capable of driving 15/25mA instead of 40/50mA

Are you accessing some of the shield pins at a high rate? Without special tricks, the Galileo can only toggle an IO pin at 477 kHz (see also Galileo FAQ and Forum post on this subject).

Software

Does the driver directly access Atmel’s registers? This can be either the IO-port registers, Interrupt, Pulse Width Modulator (PWM) or Timer registers.

Does it use any AVR libraries? These libraries are exposing the Atmel AVR hardware to the programmer and are therefore a sure sign that you are in for some work to port the Arduino software libraries to the Galileo platform. Search for “#include <avr/” to see how many AVR hardware specific libraries are used.

Well written software libraries only use the official Arduino application programmers Interface (API). However, many of the existing shield libraries directly manipulating AVR hardware registers. This is either done out of ignorance for software portability or out of necessity as to push the hardware to its limits. I expect that with the transition away from the 8-bit AVR (ATmega328) micro controller to the more powerfule 32-bit CPUs ( Arduino Due, Arduino Tre, Galileo and Olimex-STM32) this problem will gradually subside.
Also note that as of this writing the following Arduino Libraries are supported:

There a quite a number of Arduino boards available. The original Arduinos all used 8-bit AVR micro-controllers from Atmel. Recently Arduino adopted 32-bit ARM cores. In this post I want to look at the features of the Galileo board. The Board is about double the size of an original Arduino board and built around the Intel Quark X1000 controller. The Quark family of Intel chips are the new low cost line of x86 controllers that are positioned below the Atom cores. Quarks are elementary particles that make up the atomic nucleus. Intel positions the Quark family for Internet of Things (IoT) applications. The X1000 controller is the first member of this line. The X1000 offers:

The controller is packed into a Flip-Chip Ball Grid Array (FCBGA) package with 393 solder balls that come with a 0.593 mm ball pitch. The package dimensions are 15mm x 15mm. With this kind of a package hand soldering is out of the picture.
Noteworthy is the implementation of the Arduino shield interface. The interface is pretty much designed with external components. For the GPIO/PWM digital shield pins a Cypress CY8C9540A 40-Bit I/O Expander with EEPROM is used. The analog shield pins use an Analog Device AD7298 8-Channel, 1 MSPS, 12-Bit SAR Analog to Digital Converter (ADC) with Temperature Sensor . The Quark controller uses I2C serial interface to control the PGIO/PWM CY8C9540A device and the SPI for the ADC AD7298.