AN4810: Communication between MQX RTOS and Android

Freescale SemiconductorApplication Note

© 2013 Freescale Semiconductor, Inc. All rights reserved.

Remote controlling and monitoring is becoming a requirement in the embedded world because the communication between different embedded devices and mobile devices, such as smartphone, is becoming more popular.

This document demonstrates MQX RTCS™ ability to communicate with an Android OS application, which is running on a smartphone. The hardware used to illustrate this app note is the TWR-K60N512 kit and a smartphone running on the Android Operating System (OS).

Although this document explains Android OS application, developing an Android OS application and Java programming is beyond the scope of this document. For more information, see http://developer.android.com .

The application source code can be found in the AN4810SW.zip file. For more details about MQX RTOS, see www.freescale.com/mqx .

Document Number: AN4810Rev. 0, 12/2013

Contents1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22. MQX Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23. Android OS Application . . . . . . . . . . . . . . . . . . . . . . . 44. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Communication between MQX™ RTOS and Android Operating Systemby Freescale Semiconductor, Inc.

Communication between MQX™ RTOS and Android Operating System, Rev. 0

2 Freescale Semiconductor

Overview

1 OverviewThe implementation is divided into two applications. The first application runs on the TWR-K60N512-KIT by using the Freescale MQX RTOS. The purpose of this application is to execute the commands received from the Android OS application. The second application runs on Android OS. It includes a GUI that allows the user to control the LED status and change the position of a servo motor that is connected to the TWR-K60N512-KIT.

This figure shows the high level implementation. TWR-K60 System module uses Ethernet to communicate to a wireless access point. A smartphone uses Wi-Fi to communicate with the Wireless access point. This configuration supports a direct communication between the two devices in the Local Area Network (LAN).

Figure 1. High level implementation view

2 MQX Application

2.1 ArchitectureFor MQX, this application defines a main and a server task. The main task is used to configure the GPIO module, Flex Timer module, RTCS, and to create the second task and send broadcast messages. The second task is the server task. The purpose of the server task is to handle the communication with the Android OS application. This communication allows the Android OS application to send commands to the TWR-K60 System and execute operations in the Tower System hardware.

2.2 ImplementationGPIO controls the 4 LEDs in the TWR-K60N512-KIT by using the LWGPIO driver. LEDs are turning on and off depending on the commands read from the messages, which are received from the Android OS application. After the GPIO is initialized with the function InitializeIO(), the main task calls the function InitializeFlexTimer() which starts and configures the Flex Timer module to control the servo motor. The InitializeNetworking() function is called next to initialize the RTCS. It can be configured to set a static IP address or use the DHCP client to get a dynamic IP address.


Freescale Semiconductor 3

MQX Application

The main task starts an infinite loop and User Datagram Protocol (UDP) messages are broadcast for these reasons:

1. Allowing the Android OS application to find the TWR-K60 System module2. Getting the IP address.3. Starting a Transmission Control Protocol (TCP) communication with the TWR-K60 System

module through the server task

The server task is created to set up and run a TCP server to wait for the Android OS application client. After a connection is established between the TWR-K60 System module and the Android OS application every message received in the TWR-K60 is processed by an internal parser, which identifies the defined commands and parameters and allows the embedded system to detect which command to execute, such as to turn ON/OFF an LED, move a servo motor, and print to the UART port. This figure shows the flow chart of each task.

Figure 2. MQX tasks flow charts



Android OS Application

3 Android OS Application

3.1 ArchitectureThe application running in the Android OS System is integrated with three User Interfaces (UI). The first UI is launched when the application starts and scans for available TWR-K60 devices in the LAN. This image shows the UI.

Figure 3. Android OS application scan UI

Once all devices are found, a second UI is launched listing all TWR-K60 systems found. The user can then choose one of these devices and start a communication.

Figure 4. Android OS application devices found UI

The third and last UI allows the user to interact with the TWR-K60 System module within the established TCP connection. For demonstration purposes some user interface objects are used, such as buttons to turn ON/OFF LEDs in the TWR-K60 System board, a text box that acts as a serial-to-ethernet, and a slider to move and set position to a servo motor.




Figure 5. Android OS application devices control UI

The user can exit the application and enter again to start the flow of the UI one more time. At that point, the user can select either the same device previously used or a different TWR-K60 System device.




3.2 ImplementationThe Activity Show Device is the start point of the Android OS application. This code is responsible for bringing up the first UI in the application. It sets the listeners for the button in the first UI, initializes global variables, starts the server thread, and starts an asynchronous thread called RefreshActivity. This thread is dedicated to show an information dialog in the application every time a new TWR-K60 System device is found in the LAN.

The first UI scans during the 10 seconds after the last device was found and provides time to find additional TWR-K60 devices if there are any. If there are no new devices found within the 10 seconds, the first UI finishes and loads the second UI listing the available devices in the LAN. This is the flowchart for this part of the code.

Figure 6. Show devices flowchart




This figure represents both the actions which the RefreshActivity thread performs to send the information dialog when a new device is found in the LAN, and the execution of the ListingActivity thread when the scanning period finishes.

Figure 7. RefreshActivity thread flowchart

The Server thread creates a UDP socket to listen for the broadcast messages sent by the TWR-K60 devices through the LAN. This UDP socket also checks the flag that the RefreshActivity thread sets when the scanning period time is complete. Every time a message is received, it is parsed and identified. If this message belongs to a TWR-K60 System device, it is registered in the list. This process continues until the RefreshActivity thread completes the scanning period time.




This figure shows the previously described behavior.

Figure 8. Server thread flowchart




If the scanning period time is complete, the ListingActivity thread is executed. This thread shows the second UI where a list of the available devices is shown allowing the user to select the desired device to control.

Figure 9. ListingActivity thread flowchart




As shown in this figure, when the user selects one of the devices in the list, the event listener launches the third and the last UI. The process starts when an item from the list is selected. After the onListItemClick listener gets the desired item, an informative dialog displays which device was chosen. Finally, the ControlActivity thread starts the execution using the information from the second UI and creating the third UI.

Figure 10. OnListItemClick event flowchart




The ControlActivity thread is the last stage. This thread shows the third UI. The buttons, the seek bar, and the text box are activated as the listeners. When the IP address is obtained from the devices, a TCP connection is established to send commands to the TWR-K60 System device. This figure shows the outline of this process.

Figure 11. ControlActivity thread flowchart



Conclusion

The events for the graphic objects, such as buttons, seek bar and text box, send the commands to the TWR-K60 System device using the TCP connection performed in the ControlActivity thread as shown in this figure.

Figure 12. Graphic objects events flowcharts

When the user exits the application or when the back button is pressed in the Android OS interface, the first UI is loaded again and the process starts again.

4 ConclusionA communication between a Kinetis™ MCU and an Android OS device can be accomplished using the basic TCPIP programming and the Freescale MQX RTOS. This application provides a baseline to create more elaborate and complex solutions using a Kinetis MCU and Android OS. This solution mostly benefits remote controlling in the embedded world by using a device such as a smartphone running on the Android OS.



References

5 ReferencesKinetis Microcontrollers with ARM® Cortex: www.freescale.com/kinetis

Android Developers: http://developer.android.com

Freescale MQX RTOS: www.freescale.com/mqx

Document Number: AN4810Rev. 012/2013

Information in this document is provided solely to enable system and software

implementers to use Freescale products. There are no express or implied copyright

licenses granted hereunder to design or fabricate any integrated circuits based on the

information in this document.

Freescale reserves the right to make changes without further notice to any products

herein. Freescale makes no warranty, representation, or guarantee regarding the

suitability of its products for any particular purpose, nor does Freescale assume any

liability arising out of the application or use of any product or circuit, and specifically

disclaims any and all liability, including without limitation consequential or incidental

damages. “Typical” parameters that may be provided in Freescale data sheets and/or

specifications can and do vary in different applications, and actual performance may

vary over time. All operating parameters, including “typicals,” must be validated for each

customer application by customer’s technical experts. Freescale does not convey any

license under its patent rights nor the rights of others. Freescale sells products pursuant

to standard terms and conditions of sale, which can be found at the following address:

freescale.com/SalesTermsandConditions.

How to Reach Us:

Home Page: freescale.com

Web Support: freescale.com/support

Freescale, the Freescale logo, and Kinetis are trademarks of Freescale Semiconductor,

Inc., Reg. U.S. Pat. & Tm. Off. Tower is atrademark of Freescale Semiconductor, Inc.

All other product or service names are the property of their respective owners. ARM is

the registered trademark of ARM Limited.

© 2013 Freescale Semiconductor, Inc.

Documents

AN4810: Communication between MQX RTOS and Android