The XDK110 SDK application software architecture is defined and a common code base as part of the application is provided.

SDK release summary

  • All the previous XDK110 SDK example applications are refactored for the architecture to re-use the common code base. This means:
    • We have Enterprise WPA2 support in applications where WLAN is the transport medium
    • Noise sensor is available for any in-built sensor based application
  • ServalStack which was previously licensed to Bosch Internal Open Source (BIOS) is now migrated to EPL 2.0 license version
  • All the EMLib vendor library files are compiled by default with USB being a feature control
  • FATfs for SD card is configured for Longer file names (user can now provide file of 64 bytes long name)
  • FOTA (Firmware update) from SDCard
    • FOTA validation of a user provided firmware binary in the SD card

    • Update of a valid firmware from the SD card

  • TI CC3100MOD chip in-built file system is now limited to 4kB per file
  • The XDK110 SDK BSP's outdated BCDS_BSP_Extension_Gpio.h is replaced by BSP_ExtensionPort.h by making it more generic and simple
  • Two new example application are added
    • AwsSendDataOverMQTT
      • To demonstrate MQTT using Amazon FreeRTOS secure sockets to stream sensor data to AWS server
    • SigfoxDataExample
      • To demonstrate SIGFOX communication using innocomm S-Wing module interfaced on XDK extension bus to stream sensor data using Cayenne Low Power Payload (LPP) format

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


  • 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.


  • 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


  • 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


  • 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


  • 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


  • 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


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)

    • Support :

      • BCDS Bidirectional service

      • XDK Sensor Service

      • User defined custom service

  • HTTP Rest Client

    • Implements an HTTP REST Client.

    • Supports :

      • POST

      • GET

  • LED

    • Implements XDK in-built LED control

    • Support :

      • LED colors

        • Red

        • Yellow

        • Orange

      • LED controls

        • On

        • Off

        • Toggle

  • LWM2M

    • Implements LWM2M client

    • Support :

      • Standard OMA objects

        • Object ID 3 : Device

        • Object ID 4 : Connectivity monitoring

        • Object ID 5 : Firmware update

      • Standard IPSO (OMA standardized) objects

        • Object ID 3301 : Illuminance

        • Object ID 3303 : Temperature

        • Object ID 3304 : Humidity

        • Object ID 3310 : Light control

        • Object ID 3313 : Accelerometer

        • Object ID 3314 : Magnetometer

        • Object ID 3315 : Barometer

        • Object ID 3334 : Gyroscope

      • Standard XDK (BCDS vendor specific) objects

        • Object ID 15000 : Sensor device

        • Object ID 15003 : Alert notification

  • MQTT

    • Implements MQTT (Message Queuing Telemetry Transport) which is an ISO standard (ISO/IEC PRF 20922) publish-subscribe-based messaging protocol

    • Support :

      • Types

        • EPL 2.0 ServalStack (a network stack) based MQTT

          • Non-secure

          • Secure

            • Only server certificate authentication

        • Amazon FreeRTOS based MQTT over secure sockets

          • Secure

            • With client certificate authentication

  • UDP

    • Implements TI Simplelink library based UDP socket communication

    • Support :

      • Open

      • Send

      • Close

  • WLAN

    • This is a single instance transport layer. Supports connection to a wireless wide-area network, also referred to as WiFi

    • Support :

      • Connection Types

        • Personal WPA2

        • Enterprise WPA2

          • Service pack update in the chip is a prerequisite


Consists of modules that can sense from the outside world. Supported sensor modules are :

  • Button

    • This senses actuation of XDK in-built physical buttons. This provides the button event notifications in application thread context

    • Support :

      • Button controls

        • In-built Button 1

        • In-built Button 2

      • Button Events

        • Press

        • Release

  • 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


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

  • SNTP

    • Supports EPL 2.0 ServalStack ( a network stack ) based SNTP handling module

  • Storage

    • Implements the storage medium data exchange

    • Support :

      • Medium

        • SD card

        • WiFi chip file system

      • Operations

        • Availability check

        • Read

        • Write

        • Rename

        • Delete

        • Transfer

  • Time Stamp

    • This provide utility functions for time stamp conversions

    • Support :

      • SNTP timestamp to the standard POSIX "struct tm" format

      • POSIX "struct tm" format to ISO 8601 format

  • Utils

    • Supports basic Utility functions like common interface inclusion and useful macros

    • This will be extended going forward

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


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.

let rot_x = Gyroscope.x_axis.read();
let rot_z = Gyroscope_BMI160.z_axis.read();

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.

setup gridEye : I2C {
  deviceAddress = 0x68;
  var powerControl = register_uint8(address = 0x00);
  var framerate = register_uint8(address = 0x02);
  var temperatures = array_register_int16(address = 0x80, length=64);

setup lightSwitch : GPIO {
  var toggle = digitalOut(pin = PA1, initialValue = false);

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.

Other Improvements

You can find more changes in the commit history of the Eclipse Mita GitHub repository, detailing miscellaneous stability improvements and bugfixes.

Known Issues