Abstract: This paper proposes and designs a cross-platform embedded real-time system communication model based on sockets, and provides a demonstration based on this model. Keywords: cross-platform; embedded real-time system; socket Introduction Currently, embedded systems are developing at an unprecedented speed and are widely used in high-precision technologies and fields with extremely high real-time requirements, such as communications, military, aviation, aerospace, and industrial control. In these fields, there is an urgent need for a solution that enables the increasing number of embedded devices to communicate with each other. At the same time, due to the strong specialization of embedded systems, embedded devices in different fields often use different embedded real-time operating systems. This makes it difficult to build a unified communication platform. Currently, Microsoft is vigorously developing the Windows CE embedded platform for industrial applications. As a leading manufacturer in the industrial control field, ICP DARPA actively advocates and follows this trend. After two years of unremitting development and testing, ICP DARPA launched the WinCon-8000 series of embedded control systems based on Windows CE.NET and RISC CPU architecture in 2003, and officially established a cooperative relationship with Microsoft's WEP (Microsoft Windows Embedded Partner Program) in October 2003. This dynamic product, upon its launch, received high praise from experts across China and was selected by renowned universities such as Zhejiang University and East China University of Science and Technology as an experimental platform for automation and related majors. This article introduces a communication solution for embedded systems on different platforms using the full range of ICP DAS products. Design Goals Most sophisticated embedded systems possess embedded real-time operating systems, and most real-time operating systems come with network protocol stacks. Communication platforms can be built using network protocols. The TCP/IP protocol suite is currently the most widely used network communication protocol. However, current popular TCP/IP-based applications suffer from limitations such as single functionality and high system resource consumption. Embedded devices generally have low communication volumes and limited system resources, making them unsuitable for large-scale applications. Therefore, communication between embedded devices should be simple and flexible, allowing for additions and subtractions. Real-time Performance: Real-time systems require the system to respond to external events within a specified time. However, the physical distance between communicating embedded devices varies in different applications, and the communication methods used also differ. Communication latency is one of the main factors affecting real-time systems. High-speed communication lines can be used for short-distance communication, but the choice of communication lines is limited for long-distance communication. In low-speed communication lines, to improve the real-time performance of the embedded real-time system, the communication needs to be designed as multi-threaded and multi-tasking, ensuring that each communication request is handled by a separate thread. This guarantees timely system response. Stability is also crucial; embedded real-time systems typically have heavy measurement and computation tasks. While running a large number of tasks simultaneously cannot guarantee the system will never encounter problems, the communication task must not be affected by the tasks of the embedded device itself. Therefore, the design needs to separate the communication task from the actual detection and control tasks. A dedicated task handles communication events, and a buffer is established to ensure timely data storage. Versatility is also important; there are many types of embedded real-time operating systems, and no single operating system currently holds a dominant position in the embedded field. Cross-platform communication for embedded devices must be compatible with various common real-time operating systems and enable networking of embedded devices with different real-time operating systems. Implementation Scheme Based on the characteristics of cross-platform communication in embedded real-time systems, the following design scheme can be adopted: Cross-platform communication: The communication part uses the TCP/IP protocol suite, supported by most real-time operating systems, as the basic protocol of the system. For ease of use, TCP/IP-based sockets are used. A socket is a process communication mechanism modeled after a telephone system and successfully applied on UNIX. It provides an endpoint for inter-process communication. Before communication, both processes create an endpoint: the server binds to a fixed port, while the client can request a random port. The client can send a connection request to the server's port over the network, and the server allows the client's connection upon receiving the request. This establishes a bidirectional communication channel between the server and client. Sockets are divided into three types: stream sockets, packet sockets, and raw sockets. Stream sockets provide reliable, connection-oriented communication streams with a fixed sending and receiving order, using TCP and IP protocols. Packet sockets are a connectionless data service; data is transmitted out of order through independent messages, using UDP and IP protocols, allowing direct access to underlying protocols such as IP or ICMP. Raw sockets, while powerful, are more complex to use and are mainly used for protocol development and testing. The communication handler is designed in a multi-threaded manner. Once another embedded device initiates a connection, a thread or task is started to handle the data sent to the external embedded device. The data type is determined through parsing, and the appropriate processing function is executed. The number of processing functions can be determined based on the actual application, thus maximizing the use of limited system resources. Communication Data Processing A buffer is established between the actual embedded device task and the communication processing task using named pipes or shared memory technology. If continuous data exchange is required during communication, pipe technology can be used. Named pipes support unidirectional and bidirectional communication between processes or tasks. Named pipes have two implementation modes: byte mode and message mode. In byte mode, messages flow between the client and server as a continuous stream of bytes. This means that neither process can know exactly how many bytes are read from or written to the pipe at any given time. In message mode, the client and server send and receive data through a series of discontinuous data units. Each time a message is sent on the pipe, it must be read as a complete message. Therefore, message mode is more suitable for data exchange in communication and real-time tasks. If the embedded device only needs instantaneous data exchange during communication, a shared memory buffer can be used. Simply put, shared memory is memory shared by multiple processes. Shared memory is the fastest inter-process communication method, as it directly maps information into memory, eliminating many intermediate steps. When using shared memory for inter-process communication, attention must be paid to process synchronization. If the communication volume is small, the simplest method is to grant different permissions (read or write) to both processes, thus avoiding complex synchronization mechanisms. The structural diagram of the communication scheme is shown in Figure 1, and the communication flow between embedded devices is shown in Figure 2. [align=center] Figure 1 Structural diagram of the communication scheme Figure 2 Communication flow between embedded devices[/align] Partial code examples The following provides the implementation code for communication under two common embedded device operating systems: Code for the active communicator The active communicator uses WinCE as the operating system. Both WinCE and Windows 2000 use WinSocket, so the programming methods are basically the same. #include "Winsock2.h" #include "Windows.h" WSADATA wsaData; // WinSocket version used // Communication protocol flags struct protoent *ppe; // Address of the socket to be communicated struct sockaddr_in daddr; // Read/write data length DWORD cbRead=0,cbWritten=0; BOOL fSuccess=false; // Communication flags // Communication program DWORD HostConnect(void) { // Determine the WinSocket version to use WSAStartup(MAKEWORD (2,2),&wsaData); // Create a TCP-based socket ppe=getprotobyname("tcp"); SOCKETClientSocket=socket(PF_INET,SOCK_STREAM,ppe->p_proto); // Connect to a socket // Using TCP protocol daddr.sin_family=AF_INET; // Set the port to be connected daddr.sin_port = htons(TargetPort); daddr.sin_addr.s_addr = inet_addr(TargetIPAddress); // Set the IP address of the device to be connected // Connect to the target embedded device if (connect(ClientSocket, (struct sockaddr *) &daddr, sizeof(daddr))) {closesocket(ClientSocket);} else { // Send message...... // Prepare data to send cbWritten = send(ClientSocket, SData, strlen(SD ata)), MSG_DONTROUTE); // Receive message do { cbRead = recv(ClientSocket, RData, 50, MSG_PEEK); if (cbRead > 0) {fSuccess = true;} } while (!fSuccess); ...... // Data processing // Close the socket closesocket(ClientSocket) } return (0); } Passive Communication Side Code The passive communication side selects VxWorks as the operating system. Both Linux and VxWorks can use BSD Socket, so the programming methods are basically the same. Data exchange between communication tasks and real-time tasks is exemplified by the pipe method. #include "vxWorks.h" #include "sockLib.h" #include "inetLib.h" #include "taskLib.h" // Local Socket address struct sockaddr_in serverAddr; // Target communication machine Socket address struct sockaddr_in clientAddr; int sFd; // Listening Socket descriptor int newFd; // Connected Socket descriptor int ix=0; // Number of connected Sockets // Start pipe function void SetupPipe(void) { pipeDrv(); // Pipe driver // Pipe creation pipeDevCreate("\pipe\mypipe", 20, 40); } // Main communication function void Server(void) { // Use TCP/IP protocol serverAddr.sin_family = AF_INET; serverAddr.sin_len = sizeof(struct sockaddr_in); // The port provided for communication on this machine serverAddr.sin_port = htons(HostPort); serverAddr.sin_addr.s_addr = htonl(HostIP); // The local machine's IP address // Create a Socket sFd = socket(AF_INET, SOCK_STREAM, 0); // Bind a Socket bind(sFd, (struct sockaddr *) &serverAddr, sockAddrSize); // Listen on a Socket listen(sFd, SERVER_MAX_CONNECTIONS); // Wait for a communication event FOREVER { newFd = accept(sFd, (struct sockaddr *) &clientAddr, &sockAddrSize); sprintf(workName, "tTcpWork%d", ix++); taskSpawn(workName, NORMAL_PRIORITY, 0, NORMAL_STACK_SIZE, (FUNCPTR)); tcpCommunicateTask, newFd, (int) 0, 0, 0, 0, 0, 0, 0, 0, 0); } } // Function to handle connected communication void tcpCommunicateTask(int sFd,) { do { // Read data ReadBytes = recv(sFd, chRequest, sizeof(chRequest), MSG_PEEK); if (ReadBytes == 0) break; else RSuccess = true; GetAnswerToRequest(chRequest, chReply, &ReplyBytes); // Data processing // Return data WriteBytes = send(sFd, chReply, ReplyBytes, MSG_DONTROUTE); if (WriteBytes != ReplyBytes) break; else WSuccess = true; } while (!(RSuccess && WSuccess)); // Close Socket close (sFd); } // Data processing function void GetAnswerToRequest(char * Request, char * Reply, int * ReplyBytes) { // Open pipe (each task has a different pipe) int fd=open("\pipe\mypipe", O_RDWR,0); ......// Corresponding data exchange } Conclusion Using this cross-platform communication scheme for embedded real-time systems not only enables interconnection and interoperability between embedded devices across different platforms, but also facilitates flexible system organization. The multi-task processing method and the separation of communication tasks greatly improve the system's real-time performance and stability. Based on this scheme, the author established a remote data acquisition system for embedded devices using ICP DAS's full range of products, including PCI and ISA interface industrial data acquisition cards and the WinCon-8000 series of embedded control systems. The system operates stably and has achieved good results. This success is inseparable from ICP DAS's timely and comprehensive service and technical support, as well as its high-quality product series in China. References 1 VxWorks(r) 5.4 Programmer's Guide. Wind River Inc, 1999.6 2 Anthony Jones. Network Programming for Microsoft Windows. Microsoft Press, 1999 3 Li Zhuohuan et al. Linux Network Programming. Beijing: Machinery Industry Press, 2000.1 4 Li Chaoqing. PC and Microcontroller Data Communication Technology. Beijing: Beijing University of Aeronautics and Astronautics Press, 2000 5 Yuan Song, Lin Hu. Principles and Implementation of Universal Serial Bus. Small Microcomputer Systems, 1999(5) 6 Zhang Hongrun, Lan Qinghua. Microcontroller Application Technology Tutorial. Beijing: Tsinghua University Press, 1997