Application architecture in a nutshell

This is only a recommendation and a overview for the architecture defined for the existing XDK110 SDK examples.

Users are free to have their own architecture.

This is provided to enhance the users to better understand the XDK110 SDK application examples at first glance.

This is preferred software architecture to re-use the software modules in the application.

The XDK110 SDK Applications will have a AppController.c and AppController.h file

AppController.c is where the Scheduler gives control to the application

AppController.h is where the common user application related configurations are available

Thread components in the application control

The application by default has 2 threads.

A command processor thread

The command processor provides the application with a execution context

It is universal in the sense that it is able to execute arbitrary functions which are passed to it

Any application software component that is event driven in the system is expected to re-use this command processor

A RTOS thread

Any application software component that is periodic / polling based in the system is expected to be implemented in this

Note

Users are recommended to avoid using software timers since the bad use of timers and overloading the timer service routine would result in a non-deterministic timing and instabilities

You can have multiple RTOS threads if there is a real need and also not have one if the system is completely event driven and can be a only dependent on the Command Processor

Software control flow

The application has 3 basic steps.

Setup

Here the necessary modules required for the application like the WLAN, BLE, Sensors, etc are initialized

This is more of a software resource allocation

All the user configurations to enable communication are provided here

Enable

Here the necessary modules required for the application like the WLAN, BLE, Sensors, etc are prepared for usage

This is where we actually initialize and configure the components and modules for user interaction

Note

From a more technical perspective, the Setup and Enable implementations must be a blocking call and must be independent of command processor for synchronization purposes since the calling thread could be suspend awaiting for the same, other way around

Enable calls can be a part of the fire step as well

The Command Processor is expected to be used for Setup and Enable

Fire

Here the application specific control flow based on user needs is implemented

This can be a part of the Command Processor or the RTOS thread or the combination of both

You may have applications where there is no Fire step if it is a simple event driven application dependent on basic components

Note

These Setup, Enable and Fire implementation can also be iterative based on application needs

Fire can be a part of the command processor or the RTOS thread or both are neither

Application common code base

A reusable code base is provided in the common part of the SDK

This is not holy

This is only a common application software which could potentially change / grow if there is a new requirement / improvement needed for an existing / new application example

In essence the idea here is to provide a easy-to-use reliable re-usable code modules to be shared between different applications

The interfaces are completely independent of compile time configurable macros since this would limit the software flexibility

Only the most commonly / definitely needed configurations are provided to the interface user control and the application users are expected to customize these are per their need

There is a right trade-off between data-abstraction, flexibility and memory foot-print

Users are free to either modify this common code base as per their custom needs and write applications independent of these as well

A HTTP rest client custom header level can be incremented if there is a real need

A simple sensor data logger if it needs higher throughput, it could use the low level library API directly instead of the abstracted interfaces since the wrappers would add more run time

It has 3 components namely Connectivity, Sensor and Utility

Connectivity

Consists of modules that provide connectivity to the outside world. Supported connectivity modules are :

BLE

This is a single instance transport layer. At the moment we only support slave mode where the XDK110 becomes a device that can be connected to (as compared to connecting to some other device)

Sensor Handle

This provides various sensor handles to ease the user to access in-built sensors

Sensor

This supports XDK110 in-built sensor modules. It provides a simple wrapper for sensor data acquisition with best possible common configuration

Support :

Accelerometer

Variants

BMA280

BMI160

Interrupt

Slope based on BMA280

Magnetometer

Variant

BMM150

Gyroscope

Variants

BMI160

BMG160

Humidity

Variant

BME280

Temperature

Variant

BME280

Pressure

Variant

BME280

Light

Variant

MAX44009

Interrupt

Threshold

Noise

Type

RMS value

Variant

AKU340

External Sensor

This supports external sensors interfaced to extension bus of the XDK110 hardware

Support :

LEM

Variants

All XDK110 bus compatible sensors

Senses

Current

Voltage

MAX31865

Variants

PT100

PT1000

Senses

Temperature

Resistance

Virtual Sensor

This supports XDK110 in-built sensor based virtual sensor realization

Support :

Rotation

Compass

Absolute Humidity

Calibrated Accelerometer

Calibrated Gyroscope

Calibrated Magnetometer

Gravity

Step Counter

Finger Print

Linear Accelerometer

Gesture

Utility

Consists of utilities that can be used based on application need. Supported utility modules are :

Cayenne LPP Serializer

This provides single instance Cayenne LPP based serialization

The Cayenne Low Power Payload (LPP) provides a convenient and easy way to send data over LPWAN networks such as LoRaWAN. The Cayenne LPP is compliant with the payload size restriction, which can be lowered down to 11 bytes, and allows the device to send multiple sensor data at one time.

FOTA

Eases the firmware update on the XDK110 SDK

Support :

FOTA validation of a user provided firmware binary in the SD card

Update of valid firmware from the SD card

PPMP Serializer

This provides XDK in-built sensor data serialization

The Production Performance Management Protocol (PPMP) specifies a format that allows to capture data that is required to do performance analysis of production facilities

It allows monitoring backends to collect and evaluate key metrics of machines in the context of a production process.

It is doing that by allowing to relate the machine status with currently produced parts

Serval PAL

This is a prerequisite for EPL 2.0 ServalStack ( a network stack ) feature set usage

Utils

Eclipse Mita

Eclipse Mita is now officially part of the XDK Workbench! Formerly known as XDK LIVE, this new language for IoT has found an official home at the Eclipse Foundation. You can find its site here: Eclipse Mita

And with this move to an open source language we've continued to add system resources to Mita. A quick overview of what's changed:

HTTP and MQTT Stability

Added Gyroscope

Added GPIO

Added I2C

WLAN improvements

Bluetooth fixes

Let's go over these in detail.

HTTP and MQTT Stability

Both HTTP-REST and MQTT have received stability improvements. You should now be able to use them without the XDK crashing after or even before the first message. MQTT Example: https://www.youtube.com/watch?v=eMwhioLz6xM

Gyroscope

You can now use the gyroscope natively in Mita. As always sensors don't need a setup and can be used directly:

let rot_x = Gyroscope.x_axis.read();

There are two different gyroscope sensors on the XDK, the BMG160 and the BMI160, and there is a sensor fusion implementation shipped with our SDK. The default gyroscope uses this virtual sensor with minimal drift, but you can access the raw sensors as well.

GPIO and I2C

If you have an external device you want to access using Mita, most of them communicate over I2C, and things like light switches can often be toggled with GPIO. Both of these are now implemented in the XDK110 platform in Mita.

As you can see above, you can write or read both single and multiple bytes from I2C at once, really simplifying accessing external devices.

WLAN Improvements

WLAN configuration has been improved and simplified. You can now use open networks as well as WPA2-Enterprise authenticated ones in addition to the existing WPA(2)-Personal authentification, and configuration was improved as well. More details on how to configure WLAN can be found in the XDK110 platform specification.