Blog

<p>This past week, I managed to get some free time to dig into <a href="https://www.mbed.com/en/development/software/mbed-os/">ARM mbed OS</a>, and get a simple application talking to wot.io. The most obvious way to do this was to use ARM's own <a href="https://github.com/ARMmbed/mbed-client">mbed-client</a> interface to communicate with an instance of the <a href="https://www.mbed.com/en/development/cloud/mbed-device-server/">mbed Device Server</a>. As <a href="https://www.mbed.com/en/development/cloud/mbed-device-server/">mbed Device Server (MDS)</a> is already integrated into <a href="wot.io">wot.io</a>'s Data Service Exchange, as soon as I had the mbed-client code integrated into an application, I should be able to get my data into an existing workflow.</p>
<p>Looking at the supported board options, and what I had laying on my desk already, I decided to use the <a href="http://www.freescale.com/products/arm-processors/kinetis-cortex-m/k-series/k6x-ethernet-mcus/freescale-freedom-development-platform-for-kinetis-k64-k63-and-k24-mcus:FRDM-K64F">Freescale FRDM-k64f</a>, since it's Ethernet interface has a supported <a href="https://github.com/ARMmbed/sal-driver-lwip-k64f-eth">lwip driver</a>. The board comes prepopulated with a <a href="http://www.freescale.com/files/sensors/doc/data_sheet/FXOS8700CQ.pdf">FXOS8700CQ accelerometer and magnetometer</a>, which has a very similar interface to the <a href="http://www.freescale.com/files/sensors/doc/data_sheet/MMA8452Q.pdf">Freescale MMA8452Q</a> that I've used in a few of my projects. While there is no obvious direct mbed OS support for the accelerometer in the <a href="https://github.com/ARMmbed/mbed-hal-frdm-k64f">FRDM-k64f hardware abstraction layer</a>, we should be able to use the HAL support I2C interface to talk to it. ARM already provided a <a href="https://developer.mbed.org/components/FXOS8700Q/">FXOS8700Q sensor driver</a> under the Apache 2 license that can be easily ported to mbed OS.</p>
<p>Reading over the <a href="https://docs.mbed.com/docs/getting-started-mbed-os/en/latest/FirstProjectmbedOS/">mbedos documentation</a>, and <a href="http://yottadocs.mbed.com/#installing">yotta documentations</a>, I managed to set up both a local development environment on my Mac, and I also setup a home lab development environment using a <a href="https://github.com/cthulhuology/containers">Docker container</a>. The Docker container makes it easy to move my development environment from machine to machine, such as from home lab to office lab and back again.</p>
<p>Creating a new project using yotta is straight forward using the text based wizard:</p>
<script src="https://gist.github.com/cthulhuology/8dc3b1cf32b36ea65119.js"></script>
<p>Here I've created a project called <em>accel</em> and creates a skeleton of the <em>module.json</em> file which describes to yotta how to manage the dependencies for our applications. To install our own dependencies, we can use the <em>yotta install</em> to inject our dependency.</p>
<script src="https://gist.github.com/cthulhuology/f10b456136965da62ea1.js"></script>
<p>At the time of this writing this will modify the <em>module.json</em> file as follows:</p>
<script src="https://gist.github.com/cthulhuology/0cbc19be9d20e58bf741.js"></script>
<p>If you were to do this at a later date, the version string saying <em>^1.1.15</em> will probably be different. ARM mbed OS is undergoing rapid development, and the file I generated just last week was <em>^1.1.11</em>, almost a patch a day! This rapid development can be seen in all aspects of the system. On any given day, the <em>yotta build</em> command which actually compiles the binary application, will return different deprecation warnings, and occasionally entire libraries are in an unusable state. Generally the optimized builds will compile cleanly, but I have had problems with <em>yotta build --debug-build</em> failing to compile due to register coloring issues. That said, as ARM mbed OS leaves beta, I expect these issues will be resolved.</p>
<p>To setup the development environment for the Freescale FRDM-k64f, it is also necessary to select the appropriate target:</p>
<script src="https://gist.github.com/cthulhuology/85de7e472fef5296b0be.js"></script>
<p>This configures our build environment to build for the FRDM-k64f using arm-none-eabi-gcc. A complete list of available target architectures can be obtained using the <em>yotta search target</em> command:</p>
<script src="https://gist.github.com/cthulhuology/86c4bf50fd4218ab9cd9.js"></script>
<p>Switching which C++ compiler you use requires switching the full target. Switching targets will fetch the associated target dependencies as well, and as such it is important to build after you've selected your target. With the target set to <em>frdm-k64f-gcc</em>, we can build the <a href="https://github.com/wotio/mbedos-accel-frdm-k64f">source code</a> for this project.</p>
<p>The behavior is as follows:</p>
<ul>
<li>initialize i2c</li>
<li>initialize FXOS8700QAccelerometer</li>
<li>initialize Ethernet adapter</li>
<li>acquire a DHCP lease</li>
<li>initialize an ipv4 tcp/ip stack</li>
<li>pick a random port and</li>
<li>create a M2MInterface object to connect to MDS</li>
<li>create a M2MSecurity context for our MDS connection</li>
<li>create a M2MDevice object to create the device's OMNA LWM2M resources</li>
<li>create a M2MObject that will actually represent our device sensor tree</li>
<li>create two M2MResources for our x and y axis (not following the OMNA LWM2M conventions)</li>
<li>add our M2MObject and M2MDevice to a list to be used to update registrations</li>
<li>setup a timer to update the registration every 20 seconds</li>
<li>enable the accelerometer</li>
<li>setup a timer to sample the accelerometer every 5 seconds</li>
<li>setup a callback to setup the device and resource registrations</li>
<li>start the main scheduler loop</li>
</ul>
<p>To build the application, we can simply use the <em>yotta build</em> command to generate a <em>accel.bin</em> file in <em>build/frdm-k64f-gcc/source/</em>. This is the build artifact that is our application binary. The boot loader on the FRDM-k64f board knows how to load this file on reset. We can install this application by copying the <em>accel.bin</em> file to the USB storage device (on my Mac <em>/Volumes/MBED</em>).</p>
<p>Once the the application binary is installed, the device registers itself with <a href="https://www.mbed.com/en/development/cloud/mbed-device-server/">mbed Device Server (MDS)</a> running on our demo cluster. The data is then available to all of the services which request device notifications. The routing layer inside of the wot.io data service exchange ensures that only those users who have the rights to see the data from a given device can see it.</p>
<p>As the wot.io data service exchange supports multiple protocols, we can use an off the shelf command line client to read the data from the data service exchange. Just to quickly test getting this into a script, we can use <a href="https://www.npmjs.com/package/wscat">wscat</a>, a node module which speaks the <a href="https://tools.ietf.org/html/rfc6455">RFC6455 WebSocket protocol</a>:</p>
<script src="https://gist.github.com/cthulhuology/9c922d48fbd1670a826b.js"></script>