[Serialization] Design and Implementation of the C # communication (Serial Port and network) framework-12. Secondary Development and application,

[Serialization] Design and Implementation of the C # communication (Serial Port and network) framework-12. Secondary Development and application,

Contents

Chapter 2 secondary development and application... 2

12.1 project preparation... 3

12.2 reference related components... 4

12.3 build the main program... 5

12.4 development of device drivers... 6

12.4.1 assume the communication protocol... 6

12.4.1.1 protocol for sending and reading real-time data commands... 6

12.4.1.2 parsing Real-time Data Protocol... 6

12.4.1.3 example of sending and receiving data... 7

12.4.2 create a device module... 7

12.4.3 build protocol-driven... 8

12.4.4 construction parameters and real-time data instance classes... 8

12.4.5 build a device driver... 9

12.5 development of graphic display... 9

12.6 data export development... 9

12.7 development of service components... 10

12.8 Configuration tool application... 10

12.8.1 parameter configuration... 10

12.8.2 drive mounting... 11

12.9 summary... 11

Chapter 2 Secondary Development and Application

Supporting secondary development is an important feature of the framework. As a designer or architect, it is a great honor to make your work widely used. No matter how many projects you have done, it is not easy to have your own representative works. It is also a great pleasure to be able to make some friends through a wide range of works. Therefore, we have been striving to make SuperIO more stable, better support secondary development, and build a communication platform faster.

This section describes how to use SuperIO for secondary development. The development process is as follows:

 

 

12.1 Project Preparation

1) Select Framework4.0 as the target framework.

The target platform of all case programs uses x86. It mainly takes into account the compatibility between 32-bit and 64-bit operating systems.

12.2 reference related components

Reference related components in the development kit. For example:

 

Frame Structure

Data Header

Slave address

Command code

Checksum

Agreement ended

0x55

0xAA

 

0x61

 

0x0D

Bytes

1

1

1

1

1

1

12.4.1.2 parsing Real-time Data Protocol

After receiving the command for reading real-time data, the lower computer verifies the data and returns the real-time data. The sum is the sum starting from the "Slave address, does not include "Data Header", "checksum", and "protocol termination ".

The received data frame is as follows:

Frame Structure	Data Header		Slave address	Command code	Traffic	Signal	Checksum	Agreement ended
	0x55	0xAA		0x61	Floating Point Type	Floating Point Type		0x0D
Bytes	1	1	1	1	4	4	1	1

 

12.4.1.3 sending and receiving data example

Sending (hexadecimal): 0x55 0xaa 0x00 0x61 0x61 0x0d

Receive (hexadecimal): 0x55 0xaa 0x00 0x61 0x43 0x7a 0x00 0x00 0x43 0xb4 0x15 0x0d

Traffic Data: 250.00

Signal data: 360.00

12.4.2 create a device module

For example:

12.4.3 protocol-driven Construction

Create two classes: MySendProtocol and MyReceiveProtocol. MySendProtocol inherits the SuperIO. Device. DeviceSendProtocol base class, And MyReceiveProtocol inherits the SCL. Device. DeviceReceiveProtocol class.

Both the MySendProtocol and MyReceiveProtocol classes are overwritten)

"Function61" function, Function61 function in MySendProtocol class completes packaging and sending command operation, Function61 function in MyReceiveProtocol class completes data parsing operation, FunctionXX will appear in two classes in pairs, mainly for the sake of note.

In the MySendProtocol instance, you can call the DriverFunction and input the corresponding command, for example, 0x61. The "Function61" function is automatically called as the driver interface for calling the corresponding command function. The GetSendCmdBytes function interface is encapsulated on the basis of the DriverFunction and can also be used. However, you must set "isbox" to "false". Otherwise, special processing will be performed on the sent data.

In the MyReceiveProtocol instance, you can call the DriverFunction and input the corresponding command, for example, 0x61. The "Function61" function is automatically called as the driver interface for calling the corresponding command function. The GetAnalysisData function is encapsulated on the basis of the DriverFunction function. It can also be used. It only calls one more GetCommand function interface.

For specific code, see the DeviceDemo project.

12.4.4 construct parameters and real-time data instance type

Create two classes: MyDeviceParameter and MyDeviceRTDataMyDeviceParameter inherit from the SuperIO. Device. DeviceParameter class and are used to save the backup parameters. You can add new Device parameters to this class.

MyDeviceRTData inherits the SuperIO. Device. DeviceRealTimeData class and is used to save the real-time data of devices. You can customize the real-time data of devices based on the communication protocol.

After the two classes inherit the base classes, they will automatically inherit the two generic functions SaveSerialize and GetSerialize. The SaveSerialize function serializes the current object into XML, and GetSerialize generates object instances in reverse order for the serialized XML. The SuperIO. Device. DeviceParameter class and the SuperIO. Device. DeviceRealTimeData class inherit from the SerializeOperation class. Their interfaces are IserializeOperation, and SerializeOperation is just a simple class library for serialized XML operations.

If developers want to completely customize a data persistence file, they can inherit the IserializeOperation interface, rewrite the corresponding interface functions, and customize the way to store data.

12.4.5 build a device driver

Both "build protocol driver" and "build parameters and real-time data instance class" are preparations for building a running device and will be used as the properties of the running device.

Create a new Device class: MyDevice, which inherits from SuperIO. Device. RunDevice1.

The developer notices that there is another SuperIO. device. runDevice class, which is a relatively early running device class. Considering the platform compatibility, it is still being used in succession. However, SuperIO is not recommended for newly developed device models. device. runDevice1 class. They are all inherited from the IRunDevice interface.

12.5 graphic display development 12.6 data export development 12.7 service component development 12.8 Configuration tool Application

Mount and delete the global parameters and driver information of the Framework Platform.

12.8.1 parameter configuration

Parameter configuration mainly involves software information, installation operations, network and serial communication. The configuration content is as follows:

The development of device drivers is described in detail. For other plug-ins, develop them according to the actual situation. For details, see the secondary development manual.

 

Author: Wei Xiaozhi

Email: 504547114@qq.com

QQ: 504547114

. NET Development Technology Alliance: 54256083

Document Download: http://pan.baidu.com/s/1pJ7lZWf

Http://www.bmpj.net