LEGIC XDK - Release Notes

XDK Release Notes

  1. Version 3.7.0
  2. Version 3.6.1
  3. Version 3.6.0
  4. Version 3.5.0
  5. Version 3.4.0

Version 3.7.0

10-Dec-2020

Consolidated feature increments in v3.7.0

  1. Introducing new ‘AzurePlugAndPlay’ application to simplify the development of IoT solutions,
          * provides easy connectivity with Azure endpoints using X.509 certificates
          * supports Azure IoT plug-and-play behavior
          * streams data from all built-in sensors of XDK110 according to selected configuration
          * follow the application specific template for more details
  2. Support features of Bosch IoT Suite Cloud
          * Bosch IoT suite cloud is used with MQTT support instead of LWM2M using Ditto Thing Channel
          * MQTT payload is constructed in Vorto model https://vorto.eclipse.org/#/details/com.bosch.bcds:XDK:2.0.0.
          * Device configuration and Provisioning used for Connection and Authentication implemented
  3. Deprecate the LWM2M based Bosch IoT suite application
  4. Expose the username and password for MQTT
  5. MQTT module decoupled into two separate agents – AwsmqttAgent and ServalMqttAgent, with improved event handling and better debug support
  6. SensorDataAggregator module implemented for time based aggregation of the sensor data
  7. Replaced old root CA certificate with valid one in AwsSendDataOverMQTT application
  8. Provide Enterprise Wifi support for all WLAN based examples in XDK Workbench
  9. Added source code for Driver, Utils and Essentials package instead of .a files in workbench
  10. Added Trial version of XDK Datalogger - XDL120, to the Workbench
  11. Added Bootloader v1.3.0 version bin file

Version 3.6.1

12-Feb-2020

XDK-Workbench version 3.6.1

  1. Sensors Mutual exclusivity is removed and now noise sensor can be enabled along with other sensors
  2. In SendDataOverMQTT application, implemented MQTT reconnect
  3. Unused source files are removed from AmazonFreeRTOS Library
  4. In AwsSendDataOverMQTT application, implemented AWS Shadow MQTT Topics to control device LED
  5. In SDK Common, improved firmware download over the air functionality.
  6. In SDK Common, Added Enterprise WiFi authentication

Version 3.6.0

21-Mar-2019

XDK-Workbench version 3.6.0

  • SDK: v3.6.0
  • XDK Workbench Version: 3.6.0

SDK

Notable changes include:

  • Added Wlan reconnect functionality
    • HttpExampleClient, PpmpUnide & SendDataOverMQTT applications updated to use reconnect functionality.
  • ServalPAL
    • ServalPalWiFi_NotifyWiFiEvent notify radio connection and disconnection events as SERVALPALWIFI_CONNECTED and SERVALPALWIFI_DISCONNECTED events.
    • Following events are not supported SERVALPALWIFI_STATE_CHANGE, SERVALPALWIFI_SOCKET_SERVICE and SERVALPALWIFI_DATA_RECEIVED.
    • Removed SERVAL_THREAD_RUN macro implementation in pThreading.h.
  • SNTP feature using simplelink UDP sockets
  • Adaptive Data Rate (ADR) interface for LoRa
  • Fota through Http as port of the common code
  • CPU sleep enabled in Idle task
  • Master Feature control macro
    • This macro is used to select the features needed by application
    • ALL    —-> All the features will be enabled
    • NONE   —-> All the features will be disabled
    • SELECT —-> Application has to select the required features
  • Mbedtls configuration optimized for the binary size (Enabled only the required configurations for the below cipher suites)
    • For DTLS - PSK is implemented
      • The default cipher suite is MBEDTLS_TLS_PSK_WITH_AES_128_CCM_8
    • For TLS - RSA certificate exchange is implemented
      • The default cipher suite is MBEDTLS_TLS_RSA_WITH_AES_128_CBC_SHA
      • PEM certificate string is expected from the user to define the server certificate.

Eclipse Mita

Mita Version: legacy@d83a77c9a2b0382aab15360d1053a12bfd22a0e0

Since Workbench 3.5 the following things changed:

  • Support the LoRa module
  • Implement MQTT over TLS
  • Improve HttpRestClient stability
  • Minor code generation fixes

LoRa Module

We are now supporting the LoRa module. You can use it like this:


setup lora: LoRa {

    region = EU;  
    loraAppKey = \[0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00\];  
    loraAppEui = \[0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00\];  
    var binary = raw(1);  
    var semantic = cayenne(2);  
}  

every button\_one.pressed {  
    var buffer = new array<CayennePayload>(1);  
    data\[0\] = CayennePayload.HumiditySensor(environment.humidity.read() as uint8);  
    lora.semantic.write(data);  
}  
every button\_two.pressed {  
    var buffer = new array<uint8>(1);  
    buffer\[0\] = 1;  
    lora.binary.write(buffer);  
}

For more details on this consult the Mita documentation.

MQTT over TLS

You can now talk securely with an MQTT broker. For this you change the protocol from mqtt:// to mqtts:// and configure certificatePath with either a relative or absolute path to the server’s certificate. For more details consult the the Mita documentation.

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

https://github.com/eclipse/mita/issues?q=is%3Aopen+is%3Aissue+label%3ABug

Version 3.5.0

20-Nov-2018

Changelog

SDK

The SDK has had a major change in the Security layer with respect to 3.4.0.

Notable changes include:

  • ARM mbed-TLS ( Apache License version 2.0 ) security library replaces Escript Cycur-TLS library
    • mbedtls-2.12.0 library is integrated
    • Escript Cycur-TLS library and its dependencies are completely removed
      • Will not be supported anymore
    • For DTLS - PSK is implemented
      • The default cipher suite is MBEDTLS_TLS_PSK_WITH_AES_128_CCM_8
    • For TLS - RSA certificate exchange is implemented
      • The default cipher suite is MBEDTLS_TLS_RSA_WITH_AES_128_CBC_SHA
      • PEM certificate string is expected from the user to define the server certificate
  • The complete MbedTLS adaptor for ServalStack (EPL 2.0) is temporarily provided as part of the Common Code Base and will be contributed to ServalStack once it has well matured
  • Amazon FreeRTOS is updated to v1.4.2
  • A new application for streaming live sensor data using Long Range (LoRa) radio based on RN2483 is added
    • The application is called LoRaThingsNetworkExample
      • By default the ecosystem is provided with The Things Network
      • Easy-to-use LoRa interface is added in the Connectivity of the Common code base
  • The application compilation time is improved
    • Only the necessary shared packages are compiled based on the application needs
    • By default, in the common configuration, all the packages will be enabled
    • User can choose to enable/disable the shared packages and its dependencies based on application needs using the individual application makefile feature-set macros
  • Application support for Bootloader v1.2.0 is added
    • RAM is used instead of NVM (User page) flag to switch from application to bootloader
    • Backward compatibility also provided in case user uses bootloader version lesser than v1.2.0
  • VirtualXdkDemo application has had the below changes.
    • Rolling LED indication if there is no BLE connectivity
    • Integrated Noise sensor in the High priority data BLE service
    • External temperature sensor/ LEM sensor can now be connected as hot-plug in the runtime
  • Fixed the BoschXDKCloudConnectivity application to parse the config file if End Of Line (EOL) character is not provided in config.txt file
  • Fixed the AwsSendDataOverMQTT application publish data payload for the right sensor values
  • Watchdog is enabled by default in all the applications with ~4 minutes of timeout
    • Watchdog reset cause is printed in all the applications at appropriate places
  • Moved BLE Sensor Services from BLE shared package to Common code base and legacy support for BCDS_SensorServices.h has been provided
  • Ethernet IEEE 802.3 32-bit CRC related support are added to Utils shared package
  • Cayenne-LPP serializer is fixed for right endianness for all the supported sensors
  • ADC central is improved for dynamic ADC channel configuration changes

Eclipse Mita

Since the last Workbench release the following things changed:

  • Added Eclipse Hono over MQTT
  • Added SD card
  • Added noise sensor
  • Added ADC
  • MQTT now supports username/password authentication
  • The MQTT implementation now reconnects if connection is lost
  • Initialization of global variables is more robust
  • The wrongly spelled configuration item “authentication” in WLAN was renamed (from “authentification”)

Eclipse Hono

We’ve implemented an Eclipse Hono resource. This means that you no longer have to manually implement how Hono talks over MQTT. Instead you can directly set it up like this:


setup net: WLAN { /\* ... \*/ }
setup backend: HonoMqtt {
  transport \= net;
  url \= "mqtt://iot.eclipse.org";
  clientId \= "XDK42";
  authentication \= Authenticated(username\="consumer@HONO", password\="verysecret");

  var telemetry \= telemetry(qos\=0);
}

SD Card

You can now read from and write to files on SD cards. As usual this requires a setup. There you declare which files you want to access on the card and how to operate on them. Let’s say you want to log acceleration data to a csv file called log.csv every time you press the first button:

package main; import platforms.xdk110;

setup logging: SDCard { var csvInit = rewindingTextWrite(“log.csv”); var csv = appendingTextWrite(“log.csv”); }

every XDK110.startup { // this truncates the log file and writes the csv header logging.csvInit.write(“accel_x_axis, accel_y_axis, accel_z_axis\n”); }

every button_one.pressed { logging.csv.write(`${accelerometer.x_axis.read()}, ${accelerometer.y_axis.read()}, ${accelerometer.z_axis.read()}\n`); }

You can read from files the same way. Note that you need to specify an additional argument for reading: the chunk size you want to read.

There are different ways to access files: when reading you can either always read from the start or from where you last left off. When writing you can either always truncate and write the whole file or always append to a file.

Last but not least you can operate on files in both text mode, reading and writing strings, and binary mode, reading and writing byte arrays.

** Noise Sensor **

You can now access the SDK’s noise sensor implementation from Mita directly. We’ve taken great care to validate any access and configuration to it. We will try to notify you for example if you access the noise sensor more often than you’ve configured it to sample the microphone.

** ADC **

Accessing ADC channels works just like accessing any other connectivity:

setup adc: ADC { var microphone = channel(CH4); }

every 10 milliseconds { let sample = adc.microphone.read(); }

XDK Workbench

Major changes in the workbench includes:

  • Added support for bootloader 1.2.0
  • We now support several SDK’s
    • This means that user can now change / upgrade the SDK’s without having to update the complete workbench
  • Added support for the latest Java library
    • JRE - from 1.8.121 to 1.8.181

** Known Issues Mac OS **

We are updating the JRE feature. Since versions previous to 3.5.0 have some execution bits not set you need to change the file permissions of features/com.bosch.cds.xdk.jre.macosx.x86_64.feature_@VERSION@/jre/Contents/Home/lib/jspawnhelper to 755 or else the update wil fail. If you’ve already updated without changing permissions some files have lost their execution bit (permission 755). You can fix this manually by running these commands:

chmod 755 XDK.app/Contents/MacOS/XDK-Workbench chmod 755 XDK.app/Contents/Eclipse/Segger/macosx/JLinkGDBServer chmod 755 XDK.app/Contents/Eclipse/Segger/macosx/libjlinkarm.dylib

chmod 755 XDK.app/Contents/Eclipse/com.bosch.cds.xdk.jre.macosx.x86_64.feature_*jre/Contents/Home/bin/java chmod 755 XDK.app/Contents/Eclipse/com.bosch.cds.xdk.jre.macosx.x86_64.feature_*/jre/Contents/Home/bin/jjs chmod 755 XDK.app/Contents/Eclipse/com.bosch.cds.xdk.jre.macosx.x86_64.feature_*/jre/Contents/Home/bin/keytool chmod 755 XDK.app/Contents/Eclipse/com.bosch.cds.xdk.jre.macosx.x86_64.feature_*/jre/Contents/Home/bin/orbd chmod 755 XDK.app/Contents/Eclipse/com.bosch.cds.xdk.jre.macosx.x86_64.feature_*/jre/Contents/Home/bin/pack200 chmod 755 XDK.app/Contents/Eclipse/com.bosch.cds.xdk.jre.macosx.x86_64.feature_*/jre/Contents/Home/bin/policytool chmod 755 XDK.app/Contents/Eclipse/com.bosch.cds.xdk.jre.macosx.x86_64.feature_*/jre/Contents/Home/bin/rmid chmod 755 XDK.app/Contents/Eclipse/com.bosch.cds.xdk.jre.macosx.x86_64.feature_*/jre/Contents/Home/bin/rmiregistry chmod 755 XDK.app/Contents/Eclipse/com.bosch.cds.xdk.jre.macosx.x86_64.feature_*/jre/Contents/Home/bin/servertool chmod 755 XDK.app/Contents/Eclipse/com.bosch.cds.xdk.jre.macosx.x86_64.feature_*/jre/Contents/Home/bin/tnameserv chmod 755 XDK.app/Contents/Eclipse/com.bosch.cds.xdk.jre.macosx.x86_64.feature_*/jre/Contents/Home/bin/unpack200 chmod 755 XDK.app/Contents/Eclipse/com.bosch.cds.xdk.jre.macosx.x86_64.feature_*/jre/Contents/Home/lib/jspawnhelper rm XDK.app/Contents/Eclipse/features/com.bosch.cds.xdk.jre.macosx.x86_64.feature_*/jre/Contents/MacOS/libjli.dylib ln -s  ../Home/lib/jli/libjli.dylib XDK.app/Contents/Eclipse/features/com.bosch.cds.xdk.jre.macosx.x86_64.feature_*/jre/Contents/MacOS/

This will be fixed from the next release onwards.

Version 3.4.0

08-Aug-2018

** XDK110 SDK **

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

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)

    • 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

Sensor

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

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

  • 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

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.

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

https://github.com/eclipse/mita/issues?q=is%3Aopen+is%3Aissue+label%3ABug