RoadTest: IBM-MBED IoT Starter Kit
Author: shabaz
Creation date:
Evaluation Type: Evaluation Boards
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?:
What were the biggest problems encountered?: Nothing insurmountable; IBM Watson was slightly unintuitive and some things there needed a bit of guesswork. I played a bit with the wireless socket on the mbed application shield before realizing it isn't a supported feature due to a couple of hardware related issues.
Detailed Review:
ARM, IBM and NXP/Freescale combined forces a while back in order to bring out their IoT starter kit bundle.
I was very happy to be able to finally get the chance to try it, particularly because I felt very strongly that the technologies involved from these three legendary organizations were a great combination; ARM’s mbed has been a game-changer since its release, NXP/Freescale’s Kinetis is up there as one of the nicest ARM Cortex-M microcontroller ranges and very easy to use thanks to their ever-growing FRDM board range, and IBM is one of the heavyweights in IoT platforms. It would therefore be very interesting to try the three technologies together.
The hardware bundle contents consist of a FRDM-K64F microcontroller board and an ‘mbed application shield’ populated with a display, sensors and analog controls (potentiometers) and a joystick. This allows the user to easily and quickly generate and observe real-time data for experimenting with IoT.
Freescale’s (now NXP) Kinetis microcontroller series is based around the popular ARM Cortex-M range of cores along with Flash and data memory and integrated peripherals all wrapped up as a low-cost integrated circuit. The Kinetis series is nice because of the wealth of documentation (Motorola Semiconductor which became Freescale always had comprehensive documentation and the philosophy has been followed through over the years), easy-to-use (there are great development environments like Kinetis Design Studio with Processor Expert which is very usable as well as mbed which is discussed further below) and very low cost to get started using the FRDM board range. I also like that the integrated peripherals inside the microcontrollers have Motorola heritage; it is apparent from some register names that some integrated peripheral designs were translated from earlier Motorola microcontrollers so if one is familiar with those then the learning curve is naturally lower with Kinetis.
The range is very good and it is actually fun to use these devices to solve problems. The FRDM-K64F uses one of the more high-end Kinetis chips but there are plenty of other models in the series too and it just keeps growing currently. The entire range is split up into a few categories each with their own strengths and benefits.
The designers have taken the effort to introduce different sensors and connections on each FRDM board so that the user can explore beyond just the microcontroller. The FRDM-K64F for instance has an on-board accelerometer and magnetometer IC.
Ordinarily developing applications for a microprocessor or microcontroller entails setting up a PC or server with many tools such as a compiler, Flash memory programmer, software versioning control, interactive development environment (IDE) and so on, and then repeating all that again for all the physical places you wish to work and for all users. Furthermore it doesn’t encourage rapid prototyping for new projects if all this needs to be done each time. ARM’s mbed platform solves these issues in one fell swoop. The mbed project is essentially all these tools for free online as Software-as-a-Service (SaaS). A free account provides storage space for source code, software versioning, online compiling (saving the need for having a powerful PC) and a wealth of high quality libraries ranging from I2C and SPI to audio and FFT. Prototyping applications with mbed is quicker and is far smoother and simplified experience compared even to Arduino. Application functionality can be extremely rich due to the vast array of libraries.
Since I started using mbed a couple of years ago I’ve got around 30 projects in the cloud and when I’m prototyping for an ARM based device it is the first development platform I often pick up. It is hard to overstate just how fun and easy-to-use the FRDM board and mbed ecosystem is. It is worth obtaining an mbed-compatible board and log on to mbed.com to try it out.
Code written with mbed is compiled in the cloud using a normal C/C++ compiler but it is possible to compile code locally too if the cloud option isn’t desirable for any reason. The offering is called ‘mbed CLI’ and it is a set of scripts that together with a locally installed toolchain (e.g. ARM-GCC) provide the ability to retain mbed features while being able to work offline using your local computer/server.
Mbed CLI is available for Windows, Mac and Linux; I chose to install it on Linux and the CLI instructions were straightforward to create a project and build it all ready for installing on the FRDM board. Mbed CLI relies on Python (there is no need to know how to use Python though) so Python (and Python-dev) need to be installed first. For the build toolchain I used GCC-ARM version 4.9 available here and added GCC_ARM_PATH and MBED_GCC_ARM_PATH environment variables (pointing to the /usr/local/gcc-arm-none-eabi-4_9-2015q3/bin path) in my command shell startup file (.bashrc).
Following the instructions at the earlier link, blinking LED ‘hello world’ type code was downloaded and built using the following commands (scroll through to see the commands and output). This was great because it means prototype code can be developed into a product with developers having full control of the toolchain.
shabaz@ubuntu:~/development/mbed/test1$ mbed import https://github.com/ARMmbed/mbed-os-example-blinky [mbed] Importing program "mbed-os-example-blinky" from "https://github.com/ARMmbed/mbed-os-example-blinky" at latest revision in the current branch [mbed] Adding library "mbed-os" from "https://github.com/ARMmbed/mbed-os" at rev #a6f3fd1a60d5 [mbed] Auto-installing missing Python modules... shabaz@ubuntu:~/development/mbed/test1$ cd mbed-os-example-blinky/ shabaz@ubuntu:~/development/mbed/test1/mbed-os-example-blinky$ mbed compile -m K64F -t GCC_ARM [mbed] Auto-installing missing Python modules... Building project mbed-os-example-blinky (K64F, GCC_ARM) Scan: . Scan: FEATURE_CLIENT Scan: FEATURE_UVISOR Scan: FEATURE_BLE Scan: FEATURE_COMMON_PAL Scan: FEATURE_STORAGE Scan: FEATURE_IPV6 Scan: FEATURE_IPV4 Scan: mbed Scan: env Compile [ 0.4%]: main.cpp Compile [ 0.7%]: greentea_serial.cpp Compile [ 1.1%]: test_env.cpp ... Compile [ 99.3%]: rt_Time.c Compile [ 99.6%]: rt_Timer.c Compile [100.0%]: test_env.cpp Link: mbed-os-example-blinky Elf2Bin: mbed-os-example-blinky +-------------+-------+-------+------+ | Module | .text | .data | .bss | +-------------+-------+-------+------+ | Fill | 62 | 0 | 2221 | | Misc | 27014 | 2208 | 88 | | hal/common | 1504 | 4 | 277 | | hal/targets | 10004 | 12 | 188 | | rtos/rtos | 22 | 4 | 0 | | rtos/rtx | 5721 | 20 | 6786 | | Subtotals | 44327 | 2248 | 9560 | +-------------+-------+-------+------+ Allocated Heap: 65536 bytes Allocated Stack: unknown Total Static RAM memory (data + bss): 11808 bytes Total RAM memory (data + bss + heap + stack): 77344 bytes Total Flash memory (text + data + misc): 47615 bytes Image: ./BUILD/K64F/GCC_ARM/mbed-os-example-blinky.bin shabaz@ubuntu:~/development/mbed/test1/mbed-os-example-blinky$
Security is a topic of prime concern when deploying solutions. It’s not insurmountable; for its early years cloud computing was untrusted but today it is hard to imagine a world without it, virtually every major business has already invested in it and people use such services every day from PCs and mobile phones.
It is also clear that there is a permeation of the same technologies that are used to secure software-as-a-service (SaaS) applications such as online banking being available at the microcontroller level. In other words, from a technology standpoint alone, the days of engineers creating their own custom (in)secure procedures can rapidly diminish because the technical barriers are diminishing.
There are different aspects of security and so it is important to examine what information exists, who needs it, what the information is worth, and then invest time and effort on securing the information. At a hardware level and firmware and OS level there can be features that support security techniques. In the case of the K64 microcontroller family there is a separate hardware crypto acceleration unit that supports some important algorithms used for managing keys and certificates such as the RSA algorithm, and SHA-1 and the more important SHA-256 for hashes used as part of the certificate verification process, and ciphers used for data encryption such as the AES algorithm. All of these are accelerated by the K64 family.
The mbed OS also provides support for these algorithms in software. There is code on github to exercise various algorithms as needed for Transport Layer Security (TLS) which is used for secure HTTP. The example below was useful to demonstrate a way to send data that is not only encrypted but can be authenticated by the recipient to have originated from a particular source with no modification by an intermediary. This particular example uses a pre-shared key (this is just a demo of a single feature, in reality one could use a key exchange mechanism as TLS does).
git clone https://github.com/ARMmbed/mbed-os-example-tls cd mbed-os-example-tls cd authcrypt mbed deploy mbed compile -m K64F -t GCC_ARM
The output is observable using the USB Serial functionality that is part of mbed’s libraries (install the serial driver on your PC).
plaintext message: 536f6d65207468696e67732061726520626574746572206c65667420756e7265616400 ciphertext: d0c6d426e9c795a7bf91aab2301d4ee3b3d689bfb3f33b1a85126885fba9db9ed985f8b382e03cbaf4e25087e61c875bd5888a340f8b51fa673ca1 decrypted: 536f6d65207468696e67732061726520626574746572206c65667420756e7265616400 DONE
Moving from here to full-blown TLS was straightforward; a supplied mbed demo called ‘tls-client’ allows the user to connect up the network cable and transfer using secure HTTP (the demo uses a certificate that has been coded into the C source file); here was the output from the FRDM board:
Using Ethernet LWIP
Client IP Address is 192.168.1.177
Connecting with developer.mbed.org
Starting the TLS handshake...
TLS connection to developer.mbed.org established
Server certificate:
cert. version : 3
serial number : 11:21:B8:47:9B:21:6C:B1:C6:AF:BC:5D:0C:19:52:DC:D7:C3
issuer name : C=BE, O=GlobalSign nv-sa, CN=GlobalSign Organization Validation CA - SHA256 - G2
subject name : C=GB, ST=Cambridgeshire, L=Cambridge, O=ARM Ltd, CN=*.mbed.com
issued on : 2016-03-03 12:26:08
expires on : 2017-04-05 10:31:02
signed using : RSA with SHA-256
RSA key size : 2048 bits
basic constraints : CA=false
subject alt name : *.mbed.com, mbed.org, *.mbed.org, mbed.com
key usage : Digital Signature, Key Encipherment
ext key usage : TLS Web Server Authentication, TLS Web Client Authentication
Certificate verification passed
HTTPS: Received 437 chars from server
HTTPS: Received 200 OK status ... [OK]
HTTPS: Received 'Hello world!' status ... [OK]
HTTPS: Received message:
HTTP/1.1 200 OK
Server: nginx/1.7.10
Date: Thu, 20 Oct 2016 18:01:43 GMT
Content-Type: text/plain
Content-Length: 14
Connection: keep-alive
Last-Modified: Fri, 27 Jul 2012 13:30:34 GMT
Accept-Ranges: bytes
Cache-Control: max-age=36000
Expires: Fri, 21 Oct 2016 04:01:43 GMT
X-Upstream-L3: 172.17.0.4:80
X-Upstream-L2: developer-sjc-cyan-1-nginx
Strict-Transport-Security: max-age=31536000; includeSubdomains
Hello world!
The starter kit is designed to make IoT experimentation quick and easy. To that end there is a supplied board that can be plugged on top of the FRDM board and provides some some additional sensors, controls, an RGB LED and a display and speaker.
There are a couple of SIL header strips at the top of the shield board that are non-functional (they can be converted into a socket for a wireless board with a bit of effort; the wiring is incorrect and would need some tracks cut and patched).
There is supplied code for the application shield and I experimented briefly with the display and speaker; the display has high resolution which is great for displaying parameters such as IP addressing and device identifiers for cloud connections. The speaker is directly wired to the microcontroller output and the volume is low but adequate for its core purpose which is experimentation. It is a very useful shield to have around for general code testing and debug because the standard Arduino connections allow it to be used with many boards. Both the FRDM board and the Application Shield are thoughtfully populated with connection information printed on them.
The mbed website has a quick demo of IBM’s IoT cloud platform, Watson. By plugging in the application shield, connecting up the Ethernet to the switch/router and powering on, it is possible to drag-and-drop the demo from mbed onto the FRDM board. The LCD screen shows a device identifier and that is entered in a special ‘quickstart’ section of the IBM portal. Sensor data from the application shield along with potentiometer values are displayed dynamically in the portal.
As a next step I registered for IBM Watson. 30 days are free but this is quite restrictive; developers often take longer than 30 days to make an evaluation and it would be nice to see permanently free access for a limited number of devices. Things were a little clunky (I got some unexpected errors) but they self-resolved eventually by logging out and logging back in. There is a support mechanism but it isn’t forum based and the error I was getting meant I couldn’t see the pricing options for purchasing support either. Although things went fine after the initial hiccup I was left with the feeling that there could be low-priority ‘cosmetic’ bugs in the system (which most systems can have but there comes a point when even the low-priority issues should be resolved to prevent putting off users). It was interesting that the password policy was slightly different on account setup than for a subsequent password when the password has been forgotten; basically little inconsistencies like that exist. I also didn’t like some of the graphic displays of data auto-resized bar-graph height which could become misleading. These displays are a convenience rather than core functionality so perhaps I’m being overly critical. It is quite easy to get lost in the IBM portal because there are many services (Watson is just one of them) and in some places things are not intuitive.
It is possible to create your own devices in Watson and give them an identifier and unique token (for now I just used random.org). This information needs to be replicated inside the application running on the FRDM board. It took a while to figure out that the organization name needed to be some identifier displayed in the corner of the portal rather than the actual organization name used to create the Watson account. To be honest many of the prompts and messages in Watson can cause a little confusion but it is not hard to figure out. For instance the Watson portal refers to ‘boards’ and ‘cards’ and it took some guesswork to eventually realize that it doesn’t mean IoT boards, but rather ‘boards’ means ‘dashboards’ and ‘cards’ means ‘widgets’ (why they didn’t stick to these well-known names I don’t know). Once this was realized it was straightforward to add widgets and rules to the dashboard to be able to quickly monitor key values from devices deployed in the field.
The dashboard flexibility is good; it would be straightforward to create a status screen for observing operations for a single or multiple site. Some of the widgets are executed really well, such as the temperature example in the screenshot here, which has time navigation sliders in the lower graph that can be used to zoom into the main graph. Rules can be created to perform actions (such as send e-mails) when thresholds are exceeded.
The real strength of the platform is the ability to create your own applications and here IBM supplies good documentation and demo code to be able to connect to the Watson platform to pull out data for processing. The intent is to encourage users to build their applications on BlueMix, IBM’s platform-as-a-service (PaaS) offering but there is nothing stopping one from using an alternative provider or a local server. I tried their demo code on a local PC and it worked well. It relies on obtaining an API key and token from the Watson portal.
The portal offers client libraries so that it is easy to add your own device (based on any FRDM board or otherwise) to the IBM Watson IoT platform. I tried the C++ client library as an experiment and it worked well. The easiest way to use it is to adapt one of the sample client applications to suit. I modified the C++ client library sample to be able to send the IP addresses of the connected device to IBM Watson just as a quick experiment. For this experiment I just modified the sample code to obtain the local IP addresses of the server and send it to the cloud.
Such custom devices could be useful to send all sorts of data into Watson, for example server CPU consumption, users logged on at a site, and so on.
Besides providing friendly APIs that make creating diverse applications easy, there is also real-time operating system functionality within mbed which greatly expands program structure possibilities and allows for users to simplify complex applications and allow them to run reliably. The OS allows for application tasks to be split into separate bits of code that can run whenever CPU capacity and other resources are available. Often in microcontroller projects there is the temptation to write everything in one large loop which can work fine but becomes very complicated quickly. Code can be untangled into separate processes or tasks using a real-time operating system.
The OS within mbed is based on Keil RTX and it appears to be free to use for all personal and commercial applications although this is worth confirming with ARM for commercial scenarios.
The diagram here shows just a small taste of the capabilities that can be enabled by using an OS for applications. Here a large single-loop program has been split up into three smaller tasks called A, B and C. The arrows show dependencies where each task needs to rely on sending or receiving information to another process. As an example process A might read analog sensor values, process B may filter them for noise, and process C could send sensor data to the cloud.
The horizontal execution flow shows that each process gets a portion of CPU time to run and then the next process gets some time and so on. However if there is noise in the sensor data then the data could be filtered out and there would be no need to send the noisy data to the cloud to conserve resources. It can be seen at the point marked ‘a’ that process C halts and waits during the period that perhaps noisy data is being filtered out. Only after an event at point ‘b’ does process C become ready again to run when it receives some CPU time.
It was decided to try out the mbed OS task handling capability. A short program was written that measured the temperature every second and averaged it. If the average changes by more than +- 5% then an alert is activated. The program displays the temperature every second on the display but only issues an Alert message if the average exceeds the threshold. This program was created as two tasks. The first task is responsible for obtaining the temperature measurements and calculating the average. If the average differs from the limits then it sends a signal to a second task.
The second task sits and waits (i.e. consumes no resources) until it receives the signal from the first task. The second task is responsible for issuing the alert.
The averaging settings and temperature and alert display times can all be varied as desired; this is a level of flexibility that would be awkward to achieve in a single thread of execution. The code below exercises thread creation, signals and mutual exclusion (mutex) functionality.
#include "mbed.h"
#include "rtos.h"
#include "C12832.h"
#include "LM75B.h"
#define NUMSAMP 10
#define SIGDATAALERT 1
C12832 lcd(D11, D13, D12, D7, D10);
LM75B sensor(D14,D15);
double degc[NUMSAMP];
double avgmin, avgmax;
Mutex lcd_mutex;
Thread *cloud_handler_thread;
// read the temperature periodically
void
temp_task(void)
{
int i;
double avg=0.0;
while(1)
{
for (i=1; i<NUMSAMP; i++)
{
degc[i-1]=degc[i];
avg+=degc[i];
}
degc[NUMSAMP-1]=sensor.read();
avg+=degc[NUMSAMP-1];
avg=avg/NUMSAMP;
if ((avg<avgmin) | (avg>avgmax))
{
avgmin=0.95*avg;
avgmax=1.05*avg;
// send a signal
cloud_handler_thread->signal_set(SIGDATAALERT);
}
lcd_mutex.lock();
lcd.locate(0,15);
lcd.printf("%.1f deg C", degc[NUMSAMP-1]);
lcd_mutex.unlock();
Thread::wait(800);
lcd_mutex.lock();
lcd.locate(0,15);
lcd.printf(" ");
lcd_mutex.unlock();
Thread::wait(200);
} // end while
}
// display an alert whenever the filtered data exceeds a threshold
void
cloud_handler_task(void)
{
while(1)
{
Thread::signal_wait(SIGDATAALERT);
lcd_mutex.lock();
lcd.locate(0,0);
lcd.printf("ALERT");
lcd_mutex.unlock();
Thread::wait(1000);
lcd_mutex.lock();
lcd.locate(0,0);
lcd.printf(" ");
lcd_mutex.unlock();
}
}
int
main(void)
{
int i;
lcd.cls();
// initialize the bucket of readings
degc[NUMSAMP-1]=sensor.read();
for (i=0; i<NUMSAMP-1; i++)
{
degc[i]=degc[NUMSAMP-1];
}
avgmin=0.95*degc[NUMSAMP-1];
avgmax=1.05*degc[NUMSAMP-1];
// create threads
cloud_handler_thread=new Thread(cloud_handler_task);
Thread temp_thread(temp_task);
while(1)
{
wait(1.0);
}
return(0); // expect warning on this line
}
I really enjoyed exploring this starter kit. The FRDM-K64F is a fantastic microcontroller board with a real-time OS and very feature-rich mbed libraries to back it up. The OS and networking libraries seemed very stable during the experiments which was great to see.
The available sample code that is supplied to manage secure connections and cloud connectivity to IBM’s Watson IoT platform was easy to use. The mbed application shield is surprisingly useful and could speed up application development for IoT deployments while the real hardware is still being developed.
Top Comments
Ive been meaning to try out IoT Watson and this seems like a brilliant start. Thanks and great work.
Another top notch review Shabaz. This review was especially beneficial to me in that I actually learned new things that I wanted to, and needed to, know about.
Looks like a well connected little board, the web development should make it nice and easy to get started with