Demonstration system software design based on ARM and WinCE

introduction

The presentation system has a history of several decades, starting with the original pure optical slide projector. Today, digital projection technology has become mainstream with its integration advantages with PCs. The traditional digital presentation system consists of a PC and a projection device, which realizes the three functions of a controller, a signal source, and an optical projection. During the presentation, the presenter directly operates the PC, and the PC outputs the signal to be displayed to the projection device. As a controller and signal source, the PC is at the core. In this structure, using the PC as a signal source is conducive to its strong processing power and can bring about better presentation effects; at the same time, as a controller, the PC can use its rich human-computer interaction capabilities to provide convenient operation. On the other hand, the presentation system with PC as the core also has the following limitations:

① Dependence on PC. The demonstration system must be equipped with a PC for operation and providing demonstration signals, which brings inconvenience to the demonstration.

② The presenter's usage environment cannot be seamlessly migrated. In some highly professional fields, presenters often need an environment that can run professional software, but PCs dedicated to presentations often do not have this condition, so the presentation effect is naturally greatly affected.

1 Overall design ideas and processes

1.1 Achieving the Goal

In view of the above-mentioned shortcomings of traditional demonstration systems, with the goal of improving the portability and ease of use of demonstration systems, embedded demonstration systems hope to replace the core position of PCs in demonstration systems through other means, so that demonstrators can complete the demonstration with the help of as few devices as possible, or even without additional equipment, and have good environmental adaptability, so that demonstrators can get a better user experience.

1.2 Implementation approaches and methods

At present, equipment manufacturers mainly improve the portability and usability of the system by equipping it with interfaces such as USB, 1394, and card readers. These interfaces read files in external storage devices such as USB flash drives, SD cards, and mobile hard disks through the embedded processor inside the projector, convert the file information into video signals, and output them to the projection device, thus realizing PC-free presentations, such as EPSONEMP1815.

From a structural point of view, this method is to use the embedded system as the controller of the demonstration system, and use mobile storage devices such as USB flash drives and flash memory cards as the source of demonstration information, thereby replacing the PC. Although this can achieve demonstration without PC, the entire system still has the following limitations:

① The performance of the hardware layer is not enough to realize the processing of complex documents and data. Although the current embedded system is equivalent to a streamlined PC system, its hardware performance has made great progress after the development in recent years, but there is still a big gap compared with the processing power of the PC. At the current stage, the processing power of the embedded system cannot perfectly execute the document data processing and application on most PCs.

② In terms of software layer, embedded system application software has limitations. Although the hardware and software conditions of embedded systems are very close to those of PCs, both embedded Windows systems and Linux systems are simplified versions of their PC versions. Most professional software on PCs do not have versions corresponding to embedded systems, and cannot meet the diverse needs of professional demonstrations.

1.3 Design

To meet the requirements, the design of the embedded demonstration system mainly considers the following two aspects:

(1) Local file demonstration based on the processing power of the embedded system itself
Existing embedded demonstration systems all support local files by reading storage media such as USB flash drives and flash cards through USB interfaces and card readers. Although this method of relying on the processing power of the embedded system itself has the software and hardware deficiencies analyzed above, it is fully capable of some demonstration tasks that do not require high computing power.

(2) Network-based thin client solution
A thin client is a computer terminal that does not require any application program in a client-server network system. It communicates with the server via a specific protocol by connecting to a local area network. The thin client transmits its mouse, keyboard and other inputs to the server for processing, and the server then transmits the processing results back to the client for display.

The thin client solution fully utilizes the network connection capabilities of the embedded system and can effectively overcome the limitations and shortcomings of the embedded system itself.

It is mainly reflected in the following two aspects.

① Small amount of computation, suitable for embedded systems. As a thin client, the embedded system only needs to receive and display the remote operation screen sent back by the server during the implementation of the entire system. The lower hardware requirements can achieve display effects comparable to PC.

② Directly utilize the mature software system on the PC side and have good software compatibility. Since the embedded system acts as a thin client and directly uses the remote server as a remote desktop to indirectly operate the remote server, the software environment and document data operated by the user on the client are completely consistent with those on the server side, thus providing a good user experience of seamless "migration" of the usage environment and habits from the remote server side to the client side.

However, thin client-based applications also have their shortcomings, such as dependence on remote servers and networks, and failure to work once out of the network environment.

To sum up, considering the current software and hardware environment, it is most feasible to adopt a solution that takes into account both of the above approaches.

1.4 Hardware Platform Introduction

This embedded demonstration system is based on the ARM9 embedded system with Samsung S3C2440 as the core. The digital display signal output by the development board is converted into an analog VGA signal through an auxiliary output circuit, and finally output to the projector. The development board hardware comes with a USB interface, a card reader, and a network card interface for data exchange with the outside world.

1.5 Software Requirements Analysis

The main functions that need to be implemented in the software part of this design are:

① Manage local file resources and exchange data with external storage devices through the USB and card reader interfaces on the development board.
② Open and play local documents, videos, pictures and other files on the embedded system to meet basic demonstration requirements.
③ As a thin client, it can realize remote connection function and control and echo the remote server.

1.6 System Structure

Figure 1 Embedded Demonstration System

The system structure is shown in Figure 1. The embedded system hardware is located at the bottom layer of the system. The embedded operating system at the second layer drives the underlying hardware downwards, provides interfaces to the application upwards, and schedules and manages the software and hardware resources of the embedded system. The entire embedded system contains a complete set of software and hardware architectures, and has a certain computing power. It can run simple programs and realize the function of managing local resources.

Through the RJ45 Ethernet interface of the system, the embedded system can be used as a network thin client that can obtain an independent IP address in the local area network, connect to the remote server through the remote connection program, and send simple input information such as mouse and keyboard. After the server performs calculations, it echoes the processing results, achieving the effect of indirectly realizing complex applications and processing on the thin client.

2 Main technologies and implementations

In terms of software, it mainly involves the system layer and the application layer.

2.1 System Layer

The embedded system of this design adopts Microsoft's embedded operating system Windows CE 5.0. Based on the high efficiency and ease of use of Windows desktop operating system, Windows CE is compatible with common embedded hardware and encapsulates the underlying hardware interface, making it easy for developers to develop embedded applications. On Windows CE 5.0, Microsoft provides a development platform compatible with .NET Framework. NET Compact Framework enables developers to develop embedded applications in an environment as close to desktop applications as possible, improving the development efficiency of the program and the portability under different platforms.

The focus of this design is to develop application programs for remote control and local resource management modules on Windows CE.

2.2 Remote Control Module

Remote control is a technology that allows one computer (Remote/client) to remotely control another computer (Host/server) on the Internet. The control program is generally divided into two parts (client program Client and server program Server). When starting control, the Client sends a request to the Server, and the Server establishes a connection with the Client after accepting the request.

2.2.1 UltraVNC

Using UltraVNC as a remote control program is similar to other remote control programs. It uses a client/server architecture and allows remote PCs to be connected, monitored, and controlled via a TCP/IP network. UltraVNC is a remote control program developed based on RealVNC and has the following features:

◆ Complies with the RFB protocol widely used in the industry;
◆ After optimization, it effectively reduces the system resource usage when connecting to the network, and is suitable for use on embedded and other devices with limited performance;
◆ Free program, and open source code under the GPL protocol, which is easy to carry out secondary development.

To achieve remote control, you need to install the server program on the remote PC and the client program on the embedded system. For the WinCE platform, UltraVNC does not have an officially released compatible client, so you need to port the UltraVNC official client program to the embedded device of the WinCE platform.

2.2.2 RFB Protocol

RFB (Remote FrameBuffer) is a simple protocol for remote graphics users that works at the frame buffer level, so it is compatible with current mainstream operating systems, including Windows, Linux, and Mac OS.

RFB is a true "thin client" protocol. The design of the RFB protocol focuses on reducing the hardware requirements on the client. In this way, the client can run on different hardware, and the task implementation of the client will be as simple as possible.

The RFB protocol is stateless for the client. That is, if the client is disconnected from the server, then when it reconnects to the same server, the client's state will be saved. Even, a different client can be used to connect to the same RFB server, and the new client can already obtain the same user state as the previous client. Therefore, the user's application interface becomes very convenient. As long as the appropriate network connection exists, the user can use their own applications, and these applications will always be saved, even at different access points. In this way, the system will provide users with a familiar and unique computing environment no matter where they are.

2.2.3 Program structure and implementation process

Common data structures defined by the program:

① "class Conn". The core class for connection implementation, mainly responsible for connecting to the UltraVNC Server, displaying content, and processing information returned by the Server.
② "class ConnOpts". The ConnOps class defines the connection parameters required to connect to the UltraVNC Server, such as connection mode, IP address, port, connection password, etc.
③ "class NetworkConn". NetworkConn encapsulates network connection-related functions in WinCE to facilitate program calls
④ "namespace Vnc.RfbProto". The Vnc.RfbProto namespace encapsulates the basic data structure and functions of the RFB protocol as the underlying software call of the remote control module.
⑤ "class VncAuth". System security component, used to encrypt and transmit user connection passwords.

Basic process of program function realization:

① Establish a network connection with the remote server by obtaining the input connection parameters.

ConnOpts connOpts = new ConnOpts(textBox_IP.Text.Trim(),5900, textBox_passWord.Text.Trim(), viewOpts); //Get the server IP address, port, connection password and other information, and create a new connection setting object connOpts
……
if(opts == null)
GetConnDetails();
EstNetworkConn();
if(opts.ConnMode == ConnMode.Active) //Establish a network connection with the server
Connect();
else
Listen();

② Confirm the remote connection protocol version, verify the user identity, and initialize the local and remote ends.

NegoProtoVer(); //Match the communication protocol with the server
sideAuth(); //Verify the user informationSendCliInit
(); //Send the client initialization informationReadServInit
(); //Read the server initialization informationSetPixelFormat
(); //Set the resolution
formatSetEncodings();

③ The connection starts and the remote screen is displayed.

CreateDisp(); //Generate display screen

④ Continue to transmit the operation instructions and return to the updated result screen.

if(opts.ViewOpts.ServScaling != ServScaling.Default) //Send screen refresh information
SendSetScale((byte)opts.ViewOpts.ServScaling);
SendUpdReq(0, 0, frameBufWidth, frameBufHeight, false);

2.3 Local Resource Management Module

In order to facilitate the management of local resources in embedded systems, it is necessary to add local resource management functions to the application. The program can access the connected resources locally through external interfaces such as USB interfaces and card readers, thereby realizing simple demonstration functions of local resources such as documents and pictures.

The local resource management function is mainly implemented through .net compact framework. The .net compact framework class library contains the System.IO.File class for accessing and managing local files. Calling related methods can realize functions such as opening, cutting, copying, and pasting files. The system can currently directly open files such as Word documents (*.doc) and picture files (*.jpg, *.gif).

Part of the function code:

public voidShowTree() //Generate a file structure tree
public voidAddNode(stringdir,TreeNodeparentNode) //Add child node
private voidbutton5_Click(objectsender, EventArgse) //Open file

2.4 Functional Integration

To apply it to actual products, the above two parts of the program need to be integrated into a unified interface. At the same time, in order to provide a friendly user interface, the original WinCE system's menus, taskbars and other interface elements need to be hidden in the program, and the application program provides a full-screen display interface.

Hide the taskbar and display full screen code:

//Call the system dynamic link library
[DllImport("CoreDll")]
public static extern IntPtrFindWindow(stringlpClassName, stringlpWindowName);
[DllImport("CoreDll")]
public static extern boolShowWindow(IntPtrhwnd, intnCmdShow);
[DllImport("aygshell.dll")]
static extern uintSHFullScreen(IntPtrhwndRequester, uintdwState);
[DllImport("coredll.dll")]
public static extern IntPtrGetCapture()//Full screen display
public voidShowFullScreen(System.Windows.Forms.FormobjForm)//Hide the taskbar
public voidHHTaskBar()

3 Performance and effect testing

① After the program is executed, two buttons are used to switch between remote control and local management functions.
② Click the file structure tree in the left window to browse local files and preview Word documents and pictures.
③ After the remote control is successfully connected, users can open and edit complex files completely according to their PC usage habits and continue to use the server-side software operating environment without having to learn and adapt to new operating methods.

The system test results are shown in Figures 2 to 4.

Figure 2 Initial interface of the program Figure 3 Local file management

Figure 4 Remote Control

Conclusion

This design expands the existing embedded demonstration system to the concept of network thin client, proposes a more complete embedded demonstration system design and implements it. Through the local resource management module, local file management and display can be realized; through the remote control module, seamless migration from the existing PC environment to the embedded system is realized, and all user document data and applications can be displayed and controlled on the projector controlled by the embedded system, thus solving the software and hardware limitations of the existing embedded demonstration system.

At present, the system is still in its early stages and there are still some problems, mainly reflected in:

① The operation effect of the remote control module is still not ideal, and there is still a delay in the screen display during the remote control process. This requires further optimization of the operation efficiency of the remote control software in the future development process, while improving the hardware and selecting an embedded processor with stronger computing power.

② At present, only remote control under wired network is supported. With the increasing popularity of wireless network technologies such as WiFi, the next step is to consider adding wireless network support to the system to improve the convenience of the demonstration process.

③ In terms of local file management, the current supported file formats are relatively few and cannot meet the demonstration needs. We plan to add support for more document, video, and image formats if performance permits, and enhance the versatility of demonstration equipment.