Communication between MQX RTOS and Android Operating System

Transcription

1 Freescale Semiconductor Application Note Document Number: AN4810 Rev. 0, 12/2013 Communication between MQX RTOS and Android Operating System by Freescale Semiconductor, Inc. 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 The application source code can be found in the AN4810SW.zip file. For more details about MQX RTOS, see Contents 1. Overview MQX Application Android OS Application Conclusion References Freescale Semiconductor, Inc. All rights reserved.

2 Overview 1 Overview The 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). 2 MQX Application 2.1 Architecture Figure 1. High level implementation view For 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 Implementation GPIO 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. 2 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 module 2. 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 Freescale Semiconductor 3

4 3 Android OS Application 3.1 Architecture The 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. 4 Freescale Semiconductor

5 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. Freescale Semiconductor 5

6 3.2 Implementation The 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 6 Freescale Semiconductor

7 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. Freescale Semiconductor 7

8 This figure shows the previously described behavior. Figure 8. Server thread flowchart 8 Freescale Semiconductor

9 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 Freescale Semiconductor 9

10 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 10 Freescale Semiconductor

11 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 Freescale Semiconductor 11

12 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 Conclusion A 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. 12 Freescale Semiconductor

13 References 5 References Kinetis Microcontrollers with ARM Cortex: Android Developers: Freescale MQX RTOS: Freescale Semiconductor 13

14 How to Reach Us: Home Page: freescale.com Web Support: freescale.com/support 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. 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 Freescale Semiconductor, Inc. Document Number: AN4810 Rev. 0 12/2013