Cross-Domain Development Kit XDK110 Platform for Application Development

Transcription

1 First Steps Guide Cross-Domain Development Kit Platform for Application Development Bosch Connected Devices and Solutions : Data Sheet Document revision 1.0 Document release date 01/08/16 Document number Technical reference code(s) Notes --FIRST-STEPS-GUIDE Data in this document is subject to change without notice. Product photos and pictures are for illustration purposes only and may differ from the real product s appearance. Subject to change without notice

2 First Steps Guide Page 2 XDK Guide First Steps PLATFORM FOR APPLICATION DEVELOPMENT The First Steps Guide provides the first steps in the usage of the XDK Workbench and the XDK. This includes a major overview of the features of the XDK Workbench and how to get started with an own application on the XDK. Additionally, some useful coding features of the XDK Workbench are described. Table of Contents 1. XDK WORKBENCH STARTUP OPENING THE XDK WORKBENCH XDK WORKBENCH WORKSPACE (XDK VIEW) APPLICATION TEMPLATE HELLO WORLD CODE EXAMPLE HELLO WORLD OPERATING TASK HELLO WORLD TIMER TASK SENSOR EXAMPLE INITIALZING LIGHT SENSOR READING LIGHT SENSOR XDK LIVE MONITOR PLUGIN GENERAL DESCRIPTION OF THE PLUGIN LIVE MONITOR USAGE USEFUL FEATURES OF THE XDK WORKBENCH SHOWING LINE NUMBERS ENABLING AUTOSAVE BEFORE BUILDING A PROJECT ADDING A NEW INTERFACE RENAME A PROJECT IN THE XDK WORKBENCH This guide postulates a basic understanding of the XDK Workbench. For new users we recommend going through the XDK Workbench First Steps guide first:

3 First Steps Guide Page 3 1. XDK Workbench Startup 1.1 Opening the XDK Workbench Start the XDK Workbench by clicking on the XDK icon on your desktop. The default path of the application is located in C:\XDK-Workbench\XDK-Workbench.exe. During the startup a splash screen appears. The welcome screen will be shown afterwards. Picture 1: Welcome Screen of the XDK Workbench The welcome screen is sectioned in three parts: Hands-On & Documentation (upper left), Feedback (upper right) and the XDK-Examples (lower left) Hands On & Documentation This section contains four buttons. Click&Go: Access the workspace set up for a quick start Getting Started: The shortcut to the XDK Forum for community interaction XDK Docs: This button will open the documentation Eclipse Docs: This button will open the Eclipse help (XDK Workbench ist based on Eclipse) Feedback Clicking the respective button will take you to the matching XDK community forum section to get help, to post a new application or to post an improvement. Inside the community you will find hints, tips and tricks and you can get in touch with other developers.

4 First Steps Guide Page XDK Examples - Basics The XDK comes with a variety of application examples. Choose one example and click on it. The chosen example will be imported into the workspace. The following examples are currently included: XdkApplicationTemplate This is an empty template serving as a starting point for new projects. LedsAndButtons This example contains a showcase for the use of LEDs and buttons. SdCardExample This example contains the showcases for the use of the SD card file system XDK Examples Networking HttpExampleClient This example shows how to use the network stack to perform an HTTP Client Request. HTTPS is not yet implemented. If an encryption is required, it is recommended to implement an own small encryption. (e.g. Base64) WlanNetworkManagement This example demonstrates how to use the XDK WLAN Abstraction to scan for networks, join networks, set a static IP address or dynamically obtain an IP address via DHCP. Lwm2mExampleClient This example demonstrates how to register with a LW-M2M Server including the standard LW-M2M Objects. Unencrypted and encrypted communication is both supported. SendDataOverUdp This example demonstrates how to send arbitrary data over WLAN as a UDP Broadcast XDK Examples - Sensors SendAccelerometerDataOverBle This example streams raw accelerometer data from the BMA280 Acceleration sensor via Bluetooth Low Energy (BLE). The Alpwise Data Exchange Profile is used; Alpwise ios/android App is required. Send "start" to XDK, so that streaming of data begins. SendVirtualSensorDataOverUsb The example will print out raw data from all available physical sensors. The example captures the sensor data of all sensors in one cycle. StreamSensorDataOverUsb This example will print out data from the virtual sensors over the USB port. The particular sensor can be selected in the source code. SendAccelDataOverUdpandBle If you want to use WLAN and BLE, here is a demo for this. This example demonstrates how to read sensor values from the BMA280 Acceleration sensor and send the data over WLAN (UDP Broadcast) and Bluetooth Low Energy via the Alpwise Data Exchange Profile. Either use your Android or ios mobile phone (see Android or ios App Store) to connect to XDK and receive the data. Send "start" to XDK via Bluetooth Low Energy, so that streaming of data begins.

5 First Steps Guide Page XDK Workbench Workspace (XDK View) Let s get started with the workspace view. Picture 2: XDK workspace window The default Workbench setup is split into four main tiles per default: XDK Devices (upper left), Project Explorer (lower left), Editor (upper right) and Console (lower right). The menu bar is located at the top of the window as usual. Each tile can be maximized or minimized by clicking on the respective symbol on the tile. Resizing is possible by changing the position of the tile borders. You can change the perspective by clicking on the Open perspective button (see 1.1.1) The menu bar Picture 3: The menu bar The menu bar contains all necessary functions of the XDK workbench. There is a classic menu structure and a symbols bar. Some entries are available only in a suitable context (e.g. Refractor). The symbols are only active highlighted if a matching context exists.

6 First Steps Guide Page 6 Symbol buttons of the menu bar Picture 4: Symbol buttons 1. Project/Other same as File\New, opens the Project Wizard (see picture 11) 2. Save/Save all saves (all) files shown in the editor. 3. Build all compiles all files. 4. Opens C Project Wizard; shows all examples per default. 5. Opens the welcome page. 6. External Tools: click on the black arrow for more options. Same structure as in the Run menu above. 7. Open Element opens the element menu. 8. Search opens the File/C++ search menu, can also be reached via Search above. 9. Toggle Mark Occurrences: marks occurrences in the editor. 10. Next/Previous Annotation; jumps to the next/previous annotation. Choose the annotation type by clicking on the black arrow. 11. Last Edit Location sets the cursor to the last edited position in the editor. 12. Forward /Back to switches between the register cards in the editor. Picture 5: Quick access bar 1. Quick Access; shows the possibilities of the Workbench by simply typing in characters or numbers sorted by categories. 2. Open perspective; changes the Workbench view according to the chosen perspective. 3. After choosing a different perspective the matching symbol appears right from the Open perspective button for faster access. The buttons disappear with right-click/close XDK Devices Picture 6: XDK devices list

7 First Steps Guide Page 7 The XDK devices list (picture 6) shows a list of previous and currently connected XDKs. The three buttons on the right allow to flash, boot or to debug the device. For activating the debug mode the JLink adapter (sold separately here) must be connected. Right clicking on the XDK will open the context menu. You can choose Go to Bootloader and Flash Bootloader. Also you can rename the XDK device here. (Picture 7). Picture 7: Connected XDK devices The COM and JLink buttons in the device list (picture 7) can also be manually activated or deactivated. The COM button enables the current connection between the XDK and the PC. The JLink button enables the current connection over the JLink of the XDK to the PC. What a JLink does will be described in section Flash Button Select a project from the Project Explorer or import an example from the XDK welcome screen. Press the Flash button. The XDK Workbench then compiles the project.the XDK is then put into bootloader mode. The compiled project is now transferred to the XDK, which boots automatically on completion. Picture 8: XDK flash view Boot/Reboot The button is context-sensitive and can change between Boot and Reboot, depending on the current mode of the XDK. By pressing the Boot button the XDK boots from bootloader to application mode. By pressing the Reboot button XDK switches from application mode to bootloader mode Debug For debugging a JLink adapter is required. Choose a previously compiled project. The XDK Workbench configures the debug configuration automatically. The binary is downloaded to the XDK and the debugger starts. The XDK Workbench proposes to switch to debug perspective.

8 First Steps Guide Page XDK Device Information To get some system relevant information like the connected XDK s CoreID or the USB serial number you can mouse over a device. A window will appear and display the information. The CoreID is unique for each XDK and is based on it s micro controller ID. Picture 9: XDK device information Project Explorer The project explorer stores all current XDK projects. It allows the creation of new projects and the implementation of example projects from the welcome screen. It is also possible to import and export projects from and to the XDK community. Picture 10: Project explorer Creating a new Project It is possible to create new projects in the project explorer. For this you have to right-click in the project explorer area -> select New -> select Project. Picture 11: Project wizard Now you have to choose between certain project types. It is recommended to create a C project.

9 First Steps Guide Page 9 Picture 12: New Project Open XDK Project Template and then select Application Template. This will include the required XDK Toolchain. The toolchain is required to compile and flash an application onto the XDK. Picture 13: New Project type selection

10 First Steps Guide Page Editor Picture 14: XDK workbench code editor The editor area of the XDK workbench allows entering and editing of code lines. More functions are available by using the context menu Code Editor - Autocompletion Code autocompletion is an useful feature of the XDK workbench. Type the starting character and complete the name with ctrl + space. With this shortcut it can be avoided to type long variable names. Additionally it is a convenient way to find variables and functions you want to use from the included libraries. Picture 15: Code editor autocompletion window

11 First Steps Guide Page Console Picture 16: Console view The Console tab shows an overview of the status of the Workbench, allows sending data to the XDK and shows output coming from the XDK via USB. Buttons are available on the upper right side of the tile, depending on the current status. These buttons contain functions like go to next error, clear console, etc. There are two additional tabs. Progress shows the current status of e.g. flashing. Picture 17: Progress bar You can cancel the operation by clicking on the red button on the right side of the progress bar. The Problems tab displays existing problems detected by the XDK Workbench. Picture 18: Problems view

12 First Steps Guide Page XDK Operating Modes This chapter describes the different operation modes of the XDK, how to determine in which mode the XDK is and how to switch between them. Please note that in normal operation, the XDK Workbench will automatically detect the mode it currently is in. Furthermore, the XDK Workbench will try to automatically perform the mode switch that is required for its correct function. However, there may be certain situations in which the automatic detection or the automated switching does not work. In general, the XDK knows the following modes Bootloader Mode Application Mode Assertion Stack Overflow Bootloader Mode The XDK bootloader is stored in the first 64 kb of XDKs flash memory. When the bootloader is no longer present or becomes corrupted, an update or recovery is only possible via the JLink JTAG Adapter. The bootloader allows uploading XDK applications via USB (see XDK Bootloader in the XDK General for further information). The bootloader is write-protected and can only be overwritten or updated using the JLink JTAG Adapter (sold separately) via XDK Workbench. When powering up, the XDK will automatically go into the bootloader mode, which is indicated by the red LED. If the XDK finds a valid application, the bootloader will automatically turn off the red LED and start the application. If no valid application is found or the XDK is forced to go into bootloader mode, the yellow LED indicates if the XDK is successfully connected to a PC. Once the red and yellow LEDs are solid on, the XDK shows up in the device view of the XDK Workbench and can be programmed. How to engage the Bootloader The XDK can be set into bootloader with a useful feature of the XDK workbench. Right-click on the XDK and select Go to Bootloader. In the case that the XDK does not respond (and is possibly not even recognized over USB), you can manually force the XDK into boatloader mode via Approach 1 Approach 1 Switch off XDK Press and hold Button 1 Turn on XDK Release Button 1 as soon as red LED turns on This approach is the "last resort" when XDK does not respond. Even if the XDK is not recognized over USB, approach 1 will work. There are two more possibilities to set XDK into bootloader mode: Approach 2 Get XDK into application mode (typically by turning it on) Connect it to your PC Start XDK Workbench Right-click on your XDK in the XDK Device View and select Go to Bootloader The second approach will set a flag in the user page of the MCU of XDK. When XDK reboots, the bootloader reads the flag and engages itself. Only after booting an application, the flag is reseted. Approach 3 Get XDK into application mode (typically by turning it on) Connect it to your PC Connect to XDK with a serial terminal program (see XDK_USB_DEVICE_HANDLING_Terminal) Send the following string: #reboot$ XDK will automatically reboot and go into the bootloader

13 First Steps Guide Page 13 This is technically the same as Approach 2, but it is to mention that it is possible to send commands to the XDK via the serial interface. More information on the commands that can be sent by USB can be found in the User Guide in chapter Binary images uploaded via the bootloader must be transferred in the XMODEM-CRC format Application Mode/Startup Guide This simple guide is intended for developers who are going to develop applications for XDK, to know the basic startup procedure of the system before they start writing their application. The XDK software can be configured to start in two ways as described below. The configuration can be done using the _SYSTEM_STARTUP_METHOD macro present in the application makefile. By default the XDK is shipped with DEFAULT_STARTUP enabled. Refer the code block below representing the change. export _SYSTEM_STARTUP_METHOD=CUSTOM_STARTUP Default Startup The main() function implemented in the SystemStartUp module will be the first C function executed during power ON and it does the following: 1. EFM32 chip is configured to a proper state with the help of the library function exported by emlib. 2. All interrupt sources are configured to maximum priority to ensure that ISR runs at highest priority. 3. System peripherals like GPIO, I2C and USB are initialized to a proper state. 4. GPIO pins are configured to their default value. 5. The user page module is initialized. It is used to save configuration information like Wi-Fi MAC address, Bluetooth MAC address, etc., in the user page area of flash. 6. Creates a default application specific initialization timer and start it. 7. Gives control to the operating system by starting the task scheduler of FreeRTOS. Custom Startup The custom startup procedure will exclude steps 3 to 5 of the default startup procedure described above to give users the flexibility in initializing system peripherals. Users can choose to initialize and configure the peripherals which they want to use in their application. If the custom startup procedure is configured, users have to ensure that the GPIO pins they are using are initialized to a proper default state. In both of the above configurations XDK's SystemStartUp module will schedule a default application-specific initialization timer appinitsystem which will run in the timer task context with task priority 2. Note: main.c is required to start up the freertos operating system. All code implementations will take place in additional interface header.h files and implementation.c files. Please refer to the section 5.3 how to add new interfaces to the XDK.

14 First Steps Guide Page Application Template The XDK Workbench provides a recommended project-template for own projects. This template is called XdkApplicationTemplate. It includes the XDK toolchain that is required to compile and flash a project to the XDK. Picture 19: XDK application template The XdkApplicationTemplate can be imported in two different ways. One is to import the template over the welcome screen by clicking on the example XdkApplicationTemplate. The other one is to generate the XdkApplicationTemplate as project as described in the section Hello World Code Example 2.1 Hello World Operating Task This section gives a small introduction about the operating and timer tasks. It should give the user a basic understanding about how these tasks work via a hello world implementation. The start will take place with the operating tasks. Code 1: Hello world implementation - main.c /* own header files */ /* system header files */ #include <_Basics.h> #include <stdio.h> /* additional interface header files */ #include "XdkSystemStartup.h" /* functions */ int main(void) { systemstartup(); }

15 First Steps Guide Page 15 Code 2: Hello world operating task application file - application.c /* system header files */ #include <stdio.h> #include <_Basics.h> /* additional interface header files */ #include "FreeRTOS.h" xtaskhandle Application_gdt; /* Application to print "hello world" on serial console. */ void Application_init(void * pvparameters) { (void) pvparameters; for (;;) { printf("hello world\r\n"); vtaskdelay((portticktype) 1000 / porttick_rate_ms); } } /* This is a template function where the user can write his/her custom application. */ void appinitsystem(xtimerhandle xtimer) { (void) (xtimer); } /*Call the Application Init API*/ xtaskcreate(application_init, (const char * const) "Application_init", 256,NULL,1,&Application_gdt); 2.2 Hello World Timer Task An other type of tasks beside the operating tasks are the timer tasks. These have the advantage to run an application periodically without manual implementations of any infinite loops. How to use them will be shown in the implementation code 3 of the hello world application with timer tasks:

16 First Steps Guide Page 16 Code 3: Hello World Timer Task Application File - application.c /* system header files */ #include <stdio.h> #include <_Basics.h> /* additional interface header files */ #include "FreeRTOS.h" /* Macro used to define blocktime of a timer */ #define TIMERBLOCKTIME UINT32_C(0xffff) #define TIMER_AUTORELOAD_ON pdtrue #define SECONDS(x) ((portticktype) (x * 1000) / porttick_rate_ms) /* Print string "Hello World" on the console */ void printhelloworld(xtimerhandle pxtimer) { _UNUSED(pxTimer); printf("hello world\r\n"); } /* Application to print "hello world" on serial console. */ void Application_init(void) { xtimerhandle timerhandle_gdt; /* create timer task to read and print lightsensor data every three seconds */ /* Validated for portmax_delay to assist the task to wait Infinitely (without timing out) and ticks cannot be 0 in FreeRTOS timer. So ticks is assigned to 1 */ timerhandle_gdt = xtimercreate( (char * const) "Test Application to print Hello World", SECONDS(3), TIMER_AUTORELOAD_ON, NULL, printhelloworld); } /*start the timer*/ xtimerstart(timerhandle_gdt, TIMERBLOCKTIME); /* This is a template function where the user can write his/her custom application */ void appinitsystem(xtimerhandle xtimer) { _UNUSED(xTimer); Application_init(); }

17 First Steps Guide Page Sensor Example Following the first own sensor measuring will be implemented. The reason why the light sensor will be implemented is because the search for mistakes is relatively simple. As described before the example will be implemented in the recommended XdkApplicationTemplate project. Note: appinitsystem() is required for the example and should not be deleted First of all, the interface of the light sensor has to be included. Code 4: Including primary header /* Include this code in XdkApplicationTemplate.c */ #include "XdkSensorHandle.h" Equally to this the interface of the light sensor interface can be included with the following header file. This interfaces provides all required functions to initialize and use the sensor. Code 5: Including sensor specified header #include "_LightSensor.h" XdkSensorHandle.h has the advantage that it includes the header file _LightSensor.h of the light sensor and it also contains the interfaces of all other sensors of the XDK. Therefore XdkSensorHandle.h will be used as primary header file. 3.1 Initialzing light sensor The next step is to initialize the light sensor. Code 6: Implementation of the initialization of the light sensor /* Include this code in XdkApplicationTemplate.c */ static void initlightsensor(void) { /* initialize light sensor */ Retcode_T returnvalue = RETCODE_FAILURE; returnvalue = LightSensor_init(xdkLightSensor_MAX44009_Handle); if ( RETCODE_OK = returnvalue) { printf("light Sensor initialization Failed\n\r"); } }

18 First Steps Guide Page 18 The first expression is used to generate a return code. Afterwards the light sensor is initialised by LightSensor_init(), which returns the return code that can be checked if the sensor was correctly initiated. 3.2 Reading light sensor After the correct initialization the sensor is ready to read. The following code snippet describes how a function reading the incoming sensor data has to be implemented. Code 7: Implementation to read the light sensor data /* Include this code in XdkApplicationTemplate.c */ static void readlightsensor(xtimerhandle xtimer) { (void) xtimer; /* Read and print light sensor data */ uint32_t milliluxdata = UINT32_C(0); Retcode_T returnvalue = RETCODE_FAILURE; returnvalue = LightSensor_readLuxData( xdklightsensor_max44009_handle,&milliluxdata); } if (RETCODE_OK == returnvalue) { printf("light sensor data obtained in milli lux :%d \n\r",(unsigned int) milliluxdata); In code 7 the sensor value of the light sensor is read. The first expression is related to the freertos operating system and so not necessarily needed. It is only there to prevent a warning of the compiler. The following declaration of the variable milliluxdata describes the generation of a 32-bit variable where the light sensor data is stored. It follows the declaration of the condition state returnvalue if the data could be read. The next line of code describes the actual reading of the light sensor data via LightSensor_readLuxData(). The display of the data takes place in the if bracket, the printf() is only executed if the return value of LightSensor_readLuxData() is RETCODE_OK. This means that the reading of the light sensor data was successful. The initialization of the light sensor and a function that reads its data are implemented. Now a timer or operating task has to be implemented that periodically reads the data und prints it to the XDK Workbench console. Additionally to the code lines above the implementation of the timer task takes place in appinitsystem(): The following code lines shows how to implement the required timer task.

19 First Steps Guide Page 19 Code 8: Implementation of the timer task /* Include this beneath (void) (xtimer) in appinitsystem() */ uint32_t timerblocktime = UINT32_MAX; uint32_t oneseconddelay = UINT32_C(1000); uint32_t timerautoreloadon = pdtrue; xtimerhandle LightSensorHandle = NULL; initlightsensor(); LightSensorHandle = xtimercreate((const char *) "readlightsensor", oneseconddelay,timerautoreloadon, NULL, readlightsensor); xtimerstart(lightsensorhandle,timerblocktime); The first three variable declarations are required properties for the timer task. This includes the periodicity of the timer, an one second delay and the maximal block time. For more information please refer to the freertos guide that you can find here. Additionally to the declaration of a timer handle for the timer task is required. This handle LightSensorHandle gives direct access to the timer task and can be used for example to start or stop the task. The next line of code executes the initialization of the light sensor. Finally the last two lines of code create and start the required timer task. The first one xtimercreate() creates the timer task and the second one xtimerstart() starts the timer task. Finally the first own sensor application is ready be built and flashed to the XDK.

20 First Steps Guide Page XDK Live Monitor Plugin 4.1 General description of the plugin Version 1.4.0, XDK Workbench ships with an additional plugin that allows to visualize sensor data. The plugin parses incoming USB traffic from XDK and visualizes it in a graph. An XDK application that wants to make use of the visualization and logging capabilities needs to implement a simple, string-based protocol. Furthermore, data received by XDK Workbench can be logged into a comma separated values (CSV) file. An adaption of the sensor example (3.) has to be done to show the full capability of the XDK Live Monitor Plugin. Therefore the orientation sensor will be used to show how the plugin works. Replace the initialization of the light sensor in code 6 with the following lines of code. Code 9: Initilization of the orientation sensor returnvalue = Orientation_init(xdkOrientationSensor_Handle); This call will initialize the orientation sensor, similar to the light sensor. Analogous to the read light sensor data function, the current orientation values can be read. The following three lines of code has to be inserted in the read data function (code 7). Addtionally to this the variable milliluxdata and the function LightSensor_readLuxData() has to be deleted. Code 10: Implementation to read the orientation sensor data // struct that holds the orientation data in radiants EulerData_T eulervaluesinrad; // fill eulervaluesinrad with zeros memset(&eulervaluesinrad, 0, sizeof(orientation_eulerdata_t)); // Obtains the data of the orientation sensor in radiants Retcode_T returneulervalue = Orientation_readEulerRadianVal(&eulerValuesInRad); Code 9 reads the data of the orientation sensor. The printf statement of code 7, that prints out the data to the console can be commented out, because it is only for debugging purposes. The orientation sensor data can be accessed in a similar way as shown in code 7 by using exampledata.x or exampledata.something. All other code from the previous example can stay untouched. It will work as before.

21 First Steps Guide Page Protocol The application needs to provide the data in a special data format. This allows the plugin to extract the sensor data and plot it in a graph, as well as providing it to the data logger. The data logger allows saving the received data into a CSV file Data Format This data format is intentionally kept simple, to allow developers an easy use of the monitoring capabilities. A practical example may look like this: 1 {[MONITOR] BMA280(4251) :x=216 y=-83 z=4063} The example above shows a simple string that was sent from the XDK hardware via USB. The pattern of a monitoring message is shown here: {[MONITOR]<sensor>(<timestamp>):<key>=<value><unit> }\n\r The bold parts mark required segments while any italic segments are optional. The ellipsis (...) marks the option to add more key-value pairs. Such a string can be generated and sent using the printf function: Code 11: Implementation of the printf function for the LiveMonitorPlugin /* This function has to be included there where the code is printed to the console */ printf( {[MONITOR]%s(%ld):x=%f%sIy=%f%sIz=%f%s} \n\r, BMA280, xtaskgettickcount(), sensordata.accelx, mg, sensordata.accely, mg, sensordata.accelz, mg ); // format string // data source // timestamp // value for x // unit for x // value for y // unit for y // value for z // unit for z It is also possible to display more or less data. To do so the statements after the : has be expanded or reduced. X,y and z describe the displayed variable in the plugin. The additional modifier as %f describes the data format of the displayed value and %s is a following string statement. Note: The correct printf format modifier like %s or %ld are essential to get the LiveMonitorPlugin work. Possible Formats: The examples and patterns given below are valid monitoring strings and may be used by an application to communicate with the monitoring plugin. Strict (Default) Example:

22 First Steps Guide Page 22 1 {[MONITOR] BMA280(4251) :x=216 y=-83 z=4063} 2 {[MONITOR] BMA280(4251) :x=216mg y=-83mg z=4063mg} Pattern: {[MONITOR]<sensor>(<timestamp>):<key>=<value><unit> }\n\r Orientation Sensor Another configuration beside the default configuration is the quaternion configuration. This configuration displays the values between the measuring range of 1 and 0. This can be useful to display the gyroscope data for example. How to display it will be shown with a small change in the previous example that was changed to use the orientation sensor. To use the quaternion configuration the code 10 has to be adapted. The data has also be read as quaternion values to be displayed with the quaternion configuration. The following lines of code will have to replace the code from code 10. Code 12: Implementation to read data in quaternion values Orientation_QuaternionData_T QuaternionValues; Retcode_T returnquatvalue = Orientation_readQuaternionValue(&QuaternionValues); The quaternion configuration will display the data as shown in the following example. Example: 1 QUATERNION: w= 0.0 x=0.0 y=0.0 z=0.0 Pattern: QUATERNION: x=<value_x> y=<value_y> z=<value_z> w=<value_w>\n\r As before the pattern can be generated and send by the printf function. Code 13: Implementation of the printf function for the quaternion View of the LiveMonitorPlugin printf("quaternion: w=%f x=%f y=%f z=%f\n\r", sensordata.w,sensordata.x, sensordata.y, sensordata.z);

23 First Steps Guide Page Live Monitor Usage Assuming that your XDK application is configured to send its sensor data via USB using one of the above specified formats, XDK Workbench is now able to receive this data, log it into a CSV formatted file and visualize the data in a live-view. To start, you need to open the required views. To do this, follow these steps: Open the XDK Workbench. Click on the toolbar item "Window" > "Open View" > Other. Picture 27: Window view Browse for "XDK Monitor. Picture 28: Show View Click OK.

24 First Steps Guide Page 24 A new view will appear which looks like this: Picture 29: Live Monitor Plugin Now connect an XDK device and flash your application containing the printf statement onto it. Select the device in the "Device" drop-down menu and use the "Refresh" button in the views toolbar to refresh the devices list. Click on "Start" and the plugin will parse incoming USB traffic and present it in the live-chart: Picture 30: Live Monitor Adjustments If no data seems to be received, you should check the parser settings via the "Gear" symbol in the views' toolbar. There you can choose between several predefined parser expressions, as well as define your own filters. The datagroup expression is used to extract information like "data source", "timestamp" and the "datablock" which contains the actual key-value pairs.

25 First Steps Guide Page 25 Picture 31: Monitor Configuration The output for the MONITOR configuration should look like this: Picture 32: Default Live Chart Similar to this the output of the quaternion configuration should look like this: Picture 33: Quaternion Live Chart To enable logging of the received data, hit the check box "Enable file-logging". A dialog will pop up and ask you to configure the logging process.

26 First Steps Guide Page 26 Picture 34: Monitor Configuration In the dialog shown above you can configure the output path and define several Logging-Filters". These filters are whitelist-filters, meaning that only data matching one of these filters will be logged. Depending on whether there was any sensor data received before, there may already be some filters defined. To add additional filters, enter the filter expression into the checkbox and press the "Add Filter button to add to the list. Start logging by pressing the "OK" button. Logging will start immediately. Uncheck the "Enable filelogging" checkbox to stop recording afterwards. It is also possible to open multiple monitor views. To do so, click on the "Open New Monitor View" button in the views' toolbar. This will open a secondary view which can be configured independently.

27 First Steps Guide Page Useful features of the XDK Workbench 5.1 Showing Line Numbers This section describes how to set useful configurations in the XDK Workbench. First, you should enable autosaving before building. The following screenshot shows where the configuration can be found in Window > Preferences and which checkbox has to be selected. Picture 35: Line Numbers 5.2 Enabling autosave before building a project Another useful setting is autosaving before flashing. This feature is especially helpful if there are small changes in the code done and not saved before the project was flashed to the XDK. Sometimes it can happen that code that was not saved is flashed to the XDK and it runs for example a non-functional application on the XDK besides working code. The following screenshot describes where autosaving can be enabled found in Window > Preferences. Picture 36: Enabling autosave 5.3 Adding a new Interface This section describes how to add new interfaces to an existing application in the XdkApplicationTemplate or in other projects. There are two ways to add new source and header files to an existing project. Import existing files into the project or create a new one. Existing files can be placed in the project folder and simply imported in the XDK

28 First Steps Guide Page 28 Workbench by refreshing the project. The following Screenshot shows how to create both an implementation file and a header file. Picture 37: Creating a new Interface Note: Both files need to have the correct ending tag, for example the implementation file.c Picture 38: Creating h.- and c. file The header file only has to be included in the.c implementation file. Therefore the implementation file has to be additionally added to the makefile of the project. The following screenshot shows where in the makefile the include has to be done. Both works similar for new files or for imported files.

29 First Steps Guide Page 29 Picture 39: Editing Makefile 5.4 Rename a Project in the XDK Workbench If you rename a project in XDK Workbench, the project configuration as well as the makefile has to be modified. 1. Click your project in XDK Workbench and select Properties. 2. Go into the C/C++ Build tab and update the BuildDirectory. To do this, click on Workspace and select the "make" folder inside your renamed application. Picture 40: Properties View

30 First Steps Guide Page 30 Picture 41: Build path 3. Open up the makefile in your renamed application. You may want to modify the _APP_NAME, as it defines the name of your executable file afterwards. Furthermore, you may want to add and/or change the files listed in _XDK_APP_SOURCE_FILES. Picture 42: Makefile 4. And last but not least rename the project name. Picture 43: Renaming a project