Connecting Electric Imp and SmartThings

June 8th, 2016 | SpinDance | Development

There are a myriad of Internet of Things (IoT) cloud and hardware providers out there, all competing to be the platform upon which you can build your next great gadget. Two of these providers are Electric Imp and SmartThings (now owned by Samsung). These IoT providers have two very different approaches to the world of IoT:

Electric Imp

  • Sells hardware targeted to developers($20)
  • Leverages the Squirrel programming language in an online development environment
  • Leverages Electric Imp hardware modules
  • Does not include tools to build a customer facing UI, but instead allows the developer to implement their own database and front end.
  • Has an offering to run an instance of their cloud on your equipment, protecting you in case they are bought out/go out of business etc.


  • Sells hardware targeted to consumers (the Arduino Shield retails for $35)
  • Leverages the Groovy programming language in an online development environment
  • Is set up to talk to any hardware, provided the customer has the SmartThings hub ($100)
  • Has a cloud solution that is largely geared towards developers, and has tools for designing a mobile UI that will be displayed in their mobile app
  • Privatized platform instances not available

Both systems have strengths and weaknesses,…

Read more

Introduction to Akka

June 7th, 2016 | Brian Ensink | Development

SpinDance has started using Akka to build microservices that add new features to existing cloud applications. Akka is a toolkit for building reactive, message driven distributed applications using the actor model. Our experience with Akka has been very positive so far and we plan to continue using it not just to add features to existing systems but also to build entire distributed, scalable and fault tolerant cloud applications. This is our first blog post about Akka and a brief overview of the topic. We will have more to say about Akka in the coming weeks.

Actor Model

Akka’s foundation is the actor model. An actor is a container for state and behavior. You can think of an actor as a small computing engine. Actors are fairly independent from each other and can only communicate by sending messages to other actors. An actor has a queue, or mailbox, of incoming messages which it will process in order.

An actor does not have its own dedicated thread but instead many actors are executed on a thread pool. Actors may be executed concurrently but an individual actor is only processing one message at a time. The actor views the world as a single thread which eliminates the need for expensive thread safety code within the actor. Actors are also executed in parallel in contrast to other event driven systems….

Read more

Living the Values – A Perspective on Receiving Advice

June 3rd, 2016 | Mike Stroud | Uncategorized

My son was practicing basketball last night. Every time an athlete made a move that led to an unfavorable result, the coach blew the whistle. She would explain the consequences of the move, give the athlete a couple of other options with predicted outcomes, and then let the athlete execute whichever move they chose without further interruption. It was a brief interrupt that occurred no more than once each time they crossed the court. She would praise their second effort by focusing on choice rather than outcome. As I watched, I was impressed with how she kept the advice brief and the players in control of their task (the basketball).

That’s when it occurred to me. When receiving advice anywhere and at any time, what most of us desire is an experience similar to what I saw at basketball practice where the ball remained in the athletes hands and encouragement followed the coaches interrupt. Sometimes this doesn’t happen and instead we receive advice from someone who takes over our task or tells us explicitly how to do the task. Now, I’m not talking about the person who does this infrequently. After all, we have each done it at one time or another and on occasion it is necessary. For those cases we need to put it behind us.  What I am talking about is when it is recurring and the next incident occurs before the prior incident is forgotten….

Read more

Boot Selectors and Loaders for ARM Processors

June 2nd, 2016 | SpinDance | Development

Boot loaders and selectors have long been a part of embedded applications. At their core they are designed to be run for a short period of time before the main application takes over. The responsibility of the boot application is to perform all necessary functionality before the main application is started. This could be loading the main application in preparation for its execution or selecting which application to run. While they usually do not get much attention at design time, it is extremely important to ensure that they are bug free because they are not designed to be updated. If you have a bad boot application you can make it impossible to upgrade your devices, or even worse, make bricks out of them.

Loader vs. Selector – What’s the Difference?

There are two types of boot applications that we will look at here. They differ mainly based on how many versions of the main application can be stored on the device.

If the amount of memory in your design allows for two copies of the application, then the boot application can be simplified by implementing the firmware update process in the application itself. In this approach, one copy of the application can erase the other copy and then download a new version into the empty application slot. The boot application then is just a boot selector that is responsible for checking the application slots to see if an application is present and valid,…

Read more