SDO is the most complex part of the CANopen protocol, with a response mechanism, there are many modes of transmission, and the complete SDO function node to provide 1 SDO server and a number of SDO clients, so the implementation of the SDO is extremely difficult, the protocol of the various transmission methods of parsing processing and traces to follow, The coordination of multiple SDO client services and multiple access to the SDO server is not easy, and here is a way to--sdo the thread.
Note that the thread here is not a multithreaded technology provided by the operating system, and in order to ensure good portability of the protocol stack, it is not good to tune the operating system-related library functions in the CANopen protocol stack core code. Our SDO thread here is just a set of SDO service processing methods based on the multithreading mechanism of the operating system, each of which represents an SDO link established with other nodes on the network, which is equivalent to establishing an SDO communication path between two nodes, each of which has a description of the path. In this node it seems as if a thread is responsible for this path (but will never really create a system thread), in the process of communication between the two sides through this path to communicate, the end of the SDO communication to release the thread, each node can simultaneously with multiple nodes to establish multiple such paths and non-impact, The same effect as the threading mechanism of the operating system. We know that each thread creates a parameter table that describes the properties of the thread and some private data, and similarly, the creation of an SDO thread initializes a corresponding parameter and data structure body--SDO the thread parameter table, which describes the properties of the SDO link and provides the storage of the private communication data.
The SDO thread parameter table can be said to be the core of the SDO thread, and all SDO thread creation, deletion, and SDO communication are related to this parameter table. The parameter table contents include all parameters that describe an SDO access procedure, not detailed here.
An SDO access is done this way. First, the SDO initiator node (SDO client) collects enough information to create an SDO thread, which is to initialize the SDO thread parameter table, put the collected information in a specific format into the parameter table, form a frame of SDO request, send out. The SDO service node (SDO server) receives this frame request, establishes an SDO thread for it, and decomposes the frame request parsing to get enough information to initialize the parameter table for this SDO thread. Then the program will follow the description of the parameter table to perform the function of the server to collect data to satisfy the SDO request, and then return the collected data to the SDO client, and if the request ends, release the thread, or wait for the next frame request to arrive; SDO The client determines whether the request has a subsequent request after receiving an answer, and none releases the SDO thread. If, in this process, the SDO server and SDO client nodes have received SDO requests from other nodes or need to request other nodes through the SDO, the new SDO thread is implemented, just like the previous steps, so that multiple SDO servers and SDO can be implemented Client services are implemented without interfering with each other, equivalent to a two-way multi-line railway, which is much more cool than a single wire.
This method has been implemented under single chip microcomputer, and the effect is good.
(As of 2007.11.6)
Old text backup: How to implement SDO services