With the rapid development of the information society and the growing demand, people's functional requirements for equipment are constantly improving.
This article refers to the address: http://
The diversity of devices leads to a diversity of transport protocols, and data synchronization is built on proprietary protocols, each of which can only support a limited variety of devices, systems, and data types. These incompatible protocol technologies increase the complexity of the work of users, manufacturers, service providers, and developers, while also limiting the use of mobile devices, data access and distribution. To this end, the communications industry giants have developed an industry-standard data synchronization protocol called SyncML (Synchronization Markup Language) protocol, which has been widely supported by most vendors.
In a Bluetooth car hands-free device developed by the author, the SyncML protocol is used to realize the synchronization of the phone book between the Bluetooth mobile phone and the in-vehicle device, and when the incoming call is answered, the name prompt is given, the phone book entry is navigated, and the phone number is selected to make a call. Greatly convenient for users to use. The device uses dual processors and the structure is shown in Figure 1:
Figure 1 Car hands-free equipment structure
The system adopts CSR's BC5 (BlueCore5-Multimedia External) Bluetooth chip to realize the OBML binding protocol of SyncML, and connects the synchronous channel of the mobile phone for data transmission and reception. The main processor adopts the MCF5251 chip of Freescale to realize the SyncML representation protocol. Synchronization protocol and application, processing of SyncML documents, phone book saving and SyncML document generation, wherein the mobile phone is a SyncML client and the in-vehicle device is a server.
1 SyncML synchronization protocol
1.1 Overview of the protocol
SyncML is an industry-wide mobile data synchronization protocol that uses a unified format XML (extensible markuplanguage) language for message passing between devices. XML is similar to HTML, and users can customize their own tags for easy popularization.
The SyncML protocol is defined based on XML, thus inheriting its simple, open and extensible language, which makes the whole protocol highly flexible and scalable. It can be applied to various terminal devices and network devices, and is simple, flexible and easy to implement. Products implemented in accordance with this protocol will ensure interoperability to the greatest extent possible. Since the release of the SyncML protocol, nearly 700 companies have announced support in the world. 3GPP has also decided to adopt SyncML as its data synchronization standard. WAP2.0 released in 2001 also uses SyncML as a data synchronization solution.
1.2 SyncML protocol system
SyncML is a set of protocols, including data synchronization protocols, presentation protocols, and transport mode binding protocols.
(1) Data synchronization protocol: The synchronization protocol defines the interaction process of messages between the client and the server. At the same time, seven synchronization types are defined: two-way synchronization, slow synchronization, client one-way synchronization, client refresh synchronization, and server side. One-way synchronization and server-side refresh synchronization, server notification synchronization. Two-way synchronization and slow synchronization are mandatory for compatibility specification requirements, and other synchronization modes are not mandatory. Two-way synchronization and slow synchronization are implemented in the device developed by the author.
(2) Representation Protocol: Defines the representation of the SyncML document. A SyncML document is an XML file that conforms to the XML specification and may be split into multiple SyncML messages. A SyncML message consists of two parts: a message header and a message body. The SyncML header contains information such as the route, version, authentication, and session of the message, as described by the SyncHdr element. The message body contains one or more SyncML commands, as well as data that needs to be synchronized, as illustrated by the SyncBody element.
(3) Transmission mode binding protocol: In order to achieve compatibility of transmission protocols between different devices, the SyncML protocol is bound to HTTP (hypertext transfer protocol) hypertext transfer protocol, WSP (wireless session protocol) wireless session protocol and OBEX (IrDA). Object exchange protocol) These three transport protocols basically cover the transmission of all devices. The OBEX binding protocol is implemented in the device developed by the author.
1.3 SyncML protocol framework
The synchronization application framework based on SyncML can be divided into three layers: the lowest layer is the communication protocol layer, such as HTTP, WSP, OBEX and other network transmission protocols; the middle layer is the SyncML protocol implementation and interface layer, which is the core layer of the architecture, providing SyncML Implement and provide a unified development interface to the synchronous application layer. The SyncML interface is the application programming interface of the SyncML adapter. It is also the interface between the framework entity and the network transmission, and is responsible for initiating and maintaining a network connection between application A and application B. To synchronize the application layer.
2 SyncML server design
In the Bluetooth car hands-free system, the SyncML server system is designed based on SRTK. SRTK (SyncMLReference Toolkit) is an implementation toolkit provided by SyncML organization. It is not only researched and discussed by domestic scholars, but also serves as the basis for the implementation of many enterprise-level synchronization functions. SRTK provides a unified implementation method and command parsing method, but there is no Provides all the details of the implementation, and does not provide an application for any specific application. For example, when the server receives the SyncML document on the mobile phone, how to process the command, what kind of SyncML document is generated, the developer needs to implement it, and the SRTK only provides the implementation in Windows, Palma, Linux environment, in MCF5251. Need to be transplanted.
2.1 SRTK
SRTK is divided into three layers:
The first layer: the core layer, implements SyncML application, mainly includes SyncML management, command generation and command processing. This layer is platform-independent. The management part manages the SyncML instance and the work area, controls the buffer, and switches between the send and receive modes. The command generation part constructs the synchronous data packet and the command sequence to generate a synchronized document, which is only used for the "send" mode; command processing Partially parsing received packets, extracting commands, handing them over to registered event response functions or callback functions, only for "receive" mode.
The second layer: the plug-in layer, which provides services for the core layer, is divided into two parts: SyncML workspace management and document codec. This layer has platform relevance. Workspace management manages the memory for sending and receiving packets, processing the send and receive data buffers, allowing concurrent execution; the document codec portion encodes and decodes XML and WBXML documents, and compresses or parses XML and WBXML packets.
The third layer, the system database layer, encapsulates some system-related library functions, such as memory allocation and string processing. The layer is divided separately to make the whole module independent of the platform.
2.2 System Design
The SyncML main application is implemented on Freescale's operating system FlexOS for its 32-bit embedded processor. The SRTK is ported. Based on this, the synchronization command is processed in the form of a callback function and the SyncML document is parsed. The client adds "add", "update", "delete" to the server-side phone book, thereby realizing the phone book synchronization between the Bluetooth mobile phone and the car Bluetooth hands-free device. The OBEX binding protocol is implemented by BC5 on its GOEP application profile, which completes the data transfer of the SyncML document on Bluetooth.
2.2.1 Synchronized process
(1) Establish OBEX connection: This part is implemented by BC5. BC5 queries the mobile phone to register the Bluetooth channel for its SyncML service through SDP (Service Discovery Protocol), and establishes a Bluetooth connection with this channel, which is the premise of phone directory synchronization.
(2) Synchronization initialization: After the connection is successful, the synchronization initialization is performed. In the process, the server and the client device first exchange information, mainly including the capability description, the database and synchronization type requested for access, the authentication information, and the synchronization anchor. Then, the server actively sends a command to notify the mobile phone to start synchronization. The MCF5251 forwards the document containing the Alert command with code 206 to the mobile phone via BC5. After successfully receiving and parsing the document, the mobile phone will send a synchronization request to the SyncML server.
(3) Synchronization processing and data mapping: BC5 forwards the SyncML document received from the mobile terminal to MCF5251, MCF5251 parses the document, saves the phone book VCARD list, establishes ID mapping table, and generates a response SyncML document, which is sent by BC5. Phone, continue the synchronization process.
(4) End of synchronization: When there is only the Status command in the document sent by the mobile phone, this indicates that the synchronization ends. At this time, the MCF5251 parses the VCARD list and notifies BC5 that the synchronization is over, and BC5 disconnects the OBEX from the mobile phone.
2.2.2 Workspace Management and Memory Management
Workspace management and memory management are at the heart of the entire SyncML application. When the system is initialized, first set the maximum number of bytes in all work areas, and then allocate memory for the current work area when the SyncML routine is initialized. The maximum number of bytes needs to be notified to the phone, set in the Meta attribute in the message header (SyncHdr), as described below: 10000 This defines the maximum number of bytes of the SyncML document is 10000.
The porting work of SRTK is mainly reflected in memory management. Since most of the SyncML applications need to allocate memory dynamically, and MCF5251 does not allow dynamic memory allocation, this paper designed the function MyMalloc when porting SRTK to MCF5251. Statically allocate memory, its C language description is as follows:
Void * MyMalloc(unsigned int Number)
{
Unsigned char * temp;
Temp = (unsigned char *) AllMemSFS + SysDFC;
SysDFC += Number;
Return temp;
}
Among them, AllMemSFS is an array of system memory, which is large enough to satisfy all applications. SysDFC is the number of bytes of memory allocated by the system, and Number is the number of bytes requested. The function returns a pointer whose starting address is equal to the sum of the AllMemSFS first address and SysDFC.
2.2.3 Key Technologies of the Application
According to the sales volume of mobile phones in recent years, the author selected 6 mobile phones for simultaneous testing, including Sony Ericsson W908c, Sony Ericsson K530c, Sony Ericsson W700c, Nokia N72, Nokia 6230, Nokia 6500c. It is found that these Bluetooth mobile phones have certain compatibility problems in SyncML synchronization. The experimental results show that Sony Ericsson W908c, Sony Ericsson K530c, Sony Ericsson W700c do not allow forced slow synchronization, that is, when the mobile phone requests to update the phone book with the server (Alert command code is 200). When the server wants to force slow synchronization (Alert command code is 201) and the server responds to the Alert command with the status code of 200 (indicating that the SyncML command completed successfully), the phone will cancel the synchronization. In this case, the server's response to the Alert command, Command, must have a code of 508 (a refresh request indicating that the server and the client are in sync with each other), so that synchronization can be completed normally.
The speed of the phone book synchronization is a key indicator for the user experience. Therefore, on the basis of ensuring the synchronization compatibility of the Bluetooth mobile phone, the author has done the following processing to improve the synchronization speed: (1) increase the OBEX byte length per packet, The operation is valid for most mobile phones; (2) increase the maximum number of message bytes that the server can receive, which is only valid for some mobile phones. During the synchronization process, the synchronization will fail under the following conditions: (1) The Bluetooth connection is disconnected during the synchronization, the SyncML synchronization service is aborted, the synchronization fails; (2) If the SyncML document received by the server exceeds the set, it can be received. The maximum number of bytes of the message or a syntax error, the server will abort the synchronization, the command BC5 disconnects the phone, and the synchronization fails. To disconnect, be sure to follow the OBEX protocol. For an ongoing data transfer, Abort must be called to abort this data transfer before it can be properly disconnected, otherwise the next synchronization will not be synchronized correctly.
3 Conclusion
The experimental results show that the application of SyncML protocol can realize the synchronization of the phone book between the Bluetooth mobile phone and the car hands-free device, which provides a lot of convenience for the user to make a call. Similarly, the SyncML protocol enables personal data synchronization between any SyncML-enabled mobile device, and its commercial implementation will be revolutionary for mobile computing. The author of this paper innovates: Using the BC5 chip of CSR and the MCF5251 chip of Freescale, the embedded SyncML server system is designed to realize the synchronization of the phone book between the Bluetooth mobile phone and the in-vehicle device.
10 segment led bar ,red led bar ,yellow green led bar
Wuxi Ark Technology Electronic Co.,Ltd. , https://www.arkledcn.com