As a follow-up to the Hardware Specs post, I wanted to share more details about the software for the Swift01 and our approach to building it.

Overall Architecture

In order to best illustrate my plan for the software on the Swift01, I decided to draw a diagram, a picture is, after all, worth a thousand words:

There are probably a handful of things that pop out at you, but let me talk through this piece by piece, from the bottom up.

Serial Bootloader

This piece of software allows the module software to be updated without connecting to the chipset’s debugger interface and provides some integrity-checking in the process of over-writing the old software with the new.

At first, this feature will be accessible over the main serial port but, eventually, Firmware will be update-able over the wireless interface. This will work by writing the entire firmware image to the serial flash as it is received over the wireless connection, then rebooting and flashing the program memory out of the SPI flash. This is based heavily on Felix Rusu’s OptiBoot modifications for his MoteIno.

Wireless Stack

The wireless stack deals entirely with sending and receiving messages over the wireless mesh connection. There are a couple of sections stacked up here, so bear with me as I dissect this a little further.

RF Driver

This is all of the lowest-level software for handling the behavior of the PHY (transceiver). Much of this has already been written by Atmel and is included in the Atmel Software Framework (ASF)

AES Encryption

Initially, this will be comprised of a message-signing scheme where a Pre-shared Key will generate a specific signature to validate each message. Eventually, a more complex security scheme will be used which will fully encrypt each message transmitted and received. With either scheme, only valid messages will be passed up to the next layer.

802.15.4 MAC

This software adheres to the IEEE 802.15.4 specification for point-to-point messaging. This software is included in the afore-mentioned ASF. This layer of the stack will only pass messages to the next layer if they are intended for this device (including broadcast messages).

802.15.5 Mesh

This the single-most complex part of the software package. This software block is responsible for managing a number of point-to-point connections and deciding how best to route traffic between them to achieve broader network coverage. I have broken down the development of this block into a number of smaller pieces to make it easier to develop:

Each of the numbered boxes is a reference to the 802.15.5 specification, but this should give you a better idea of how information moves through this block. On the right is the management section, there is a lot of configuration that happens there to define the behavior of the right side, the data section. Please note the bottom, highlighted section refers to the 802.15.4 MAC block I discussed previously.

There’s a lot that could be said about this section, but the best thing I could do is summarize the features that are provided by this block (in the context of wireless mesh networking):

• Addressing
• Route redundancy with self-healing
• Message group transmission
• Reliable Broadcast
• Route tracing

Feel free to ask questions if you feel this area needs more detail explained!

MQTT (future)

As indicated, this is a future feature that we plan to develop once the core development is complete. MQTT is a transport-layer protocol developed by IBM and it is a very good fit for the Internet of Things. In this architecture, all devices publish and subscribe to information at a central coordinator, thus abstracting the network away from individual addresses and toward the information on the network.

The other advantage to using an MQTT architecture is that the intelligence of the system is more configurable, given that it can reside on the network gateway between the mesh and a traditional network. This allows data to stay where it is generated and consumed rather than traveling across the internet as is the case in many first-generation IoT applications.

I/O Driver and API

The Swift is equipped with a number of external I/O pins, both analog and digital, that allow a host system to expand its I/O capabilities. In the case a more advanced system (see “Scripting Engine”), these I/Os can become the eyes and ears of the device, potentially eliminating the need for an additional microcontroller

Ext. Serial Driver and API

As with the I/O driver above, this subsystem provides access to additional capabilities to either the host microcontroller or a scripting engine residing on the Swift.

Persistent Storage Driver and API

The external memory subsystem provides a platform for both the wireless bootloader mentioned above and the later-detailed scripting engine. It could also be used to queue messages in the case of network outages.

Primary Serial UART Driver and API

This feature is designed to allow the module to communicate with a host through the primary serial interface on the board. This provides support to the AT Command interface.

FreeRTOS Scheduler

FreeRTOS (Free real-time operating system) provides the Operating System for the higher-level software to run on top of. Basically handling problem of how to run multiple different applications at the same time on the same, single-core system. It also provides helpers like mailboxes and mutexes in order to assist multiple applications in sharing the same system resources. Even most advanced users will leave anything below this layer untouched and build their functionality on top of the RTOS.

Wireless Network Service

This service acts as the interface between the wireless stack and the OS. The service gets called on a regular basis with a high priority, and processes messages all the way up and down the stack. It also interacts with the other applications running on the OS in order to send and receive messages on the wireless mesh network.

AT Command Interface

This service handles all communication with the host microcontroller and is responsible for configuration of the wireless stack in order to define its behavior. This is also the default path for messages incoming and outgoing.

Scripting Engine (future)

In order to provide an easy way to make the Swift operate independently from another device (Arduino, etc.), a scripting engine will be built to allow less technical users to write software to be executed directly on the device without working with a traditional toolchain. The scripting engine will have access to things like the I/Os and serial ports as well as, obviously, sending and receiving messages. Scripts will be stored on the SPI flash.

The choice of scripting language is likely to be a hotly-contested issue as there are many opinions about what language will best serve an embedded application like this. At this point, the Swiftlet team is leaning toward implementing Javascript. This is driven primarily by a desire to make this language accessible. The final nail in the coffin, however, is IBM’s choice of Javascript for NodeRed. Employing the same language on the automation server and the device itself makes a lot of sense as any potential user will only need to learn one new language at the most.

Regardless, this software hasn’t yet been written so, we are open to feedback about the community’s desires.

Conclusion

I hope this helps you understand our approach a little better. Please don’t hesitate to ask questions where things are not clear and definitely add your opinions too!