logo资料库

devicenet协议栈.pdf

第1页 / 共34页
第2页 / 共34页
第3页 / 共34页
第4页 / 共34页
第5页 / 共34页
第6页 / 共34页
第7页 / 共34页
第8页 / 共34页
资料共34页,剩余部分请下载后查看
Introduction
FIGURE 1: Layer Protocol
Overview of the Firmware
The Connection Object
The DeviceNet Object
The Identity Object
The Router Object
FIGURE 2: Simple overview of Object Connection
TABLE 1: Connection Object Related Files
TABLE 2: DeviceNet Object Related Files
TABLE 3: Identity Object Related Files
TABLE 4: Additional Helper Files
The Connection Object
FIGURE 3: The Connection Object and Higher Management Objects
Internal Connection Object Services
mConnReadRdy
mConnWriteRdy
mConnRead
mConnWrite
Connection Object Events
UsrConnCreateEvent
UsrConnCloseEvent
UsrConnRxDataEvent
UsrConnTxDataEvent
UsrConnSetAttribEvent
Connection Attributes
TABLE 5: Common Visible Connection Attributes
The DeviceNet Object
Internal DeviceNet Object Services
mDNetSetMACID
mDNetSetSetBaudRate
mDNetSetBOI
mDNetSetMACSwChange
mDNetSetBaudSwChange
mDNetSetMACSwValue
mDNetSetBaudSwValue
mDNetGetMACID
mDNetGetBaudRate
mDNetGetBOI
mDNetGetBusOffCount
mDNetGetAllocChoice
mDNetGetMasterMACID
mDNetMACSwChange
mDNetBaudSwChange
mDNetGetMACSwValue
mDNetGetBaudSwValue
DeviceNet Object Events
UsrDNetInitEvent
UsrDNetSetAttribEvent
The Identity Object
Identity Object Events
UsrIdentityCommunicationFaultEvent
UsrIdentityFaultEvent
UsrIdentityReset
UsrIdentityInitEvent
Internal Identity Object Services
mIdentitySetVendorID
mIdentityGetVendorID
mIdentitySetDeviceType
mIdentityGetDeviceType
mIdentitySetProductCode
mIdentityGetProductCode
mIdentitySetMajorRevision
mIdentityGetMajorRevision
mIdentitySetMinorRevision
mIdentityGetMinorRevision
mIdentitySetSerial
mIdentityGetSerial
mIdentitySetStatus
mIdentityGetStatus
mIdentitySetNameP
mIdentitySetNameLen
The Router Object
Handling Explicit Messaging
Internal Routing Services
mRoutePutByte
mRouteGetByte
mRouteTestValidInputDataLen
mRouteTestNonValidInputDataLen
mRoutePutError
mRouteRxLen
mRouteTxLen
mRouteGetHeader
mRouteGetServiceID
mRouteGetClassID
mRouteGetInstanceID
mRouteGetAttributeID
mRouteGetInBufferPtr
mRouteGetOutBufferPtr
mRouteGetInBufferLength
mRouteGetInBufferDataLength
mRouteGetOutBufferLength
mRouteGetOutBufferDataLength
mRoutePutServiceID
mRoutePutInBufferPtr
mRoutePutOutBufferPtr
mRoutePutInBufferLength
mRoutePutInBufferDataLength
mRoutePutOutBufferLength
mRoutePutOutBufferDataLength
Supporting Functions
Setting Up a Timer
GoDNetProcessAllMsgEvents
GoDNetProcessAllTickEvents
GoDNetInitializeAll
Compile Time Setup
TABLE 6: Compile Time Options
About the CAN Driver
CANOpen
CANClose
CANIsOpen
CANSetFilter
CANClrFilter
CANSetBitRate
CANIsBusError
CANIsRxRdy
CANRead
CANIsTxRdy
CANIsMsgSent
CANSend
CANGetRxCID
CANGetRxCnt
CANGetRxDataPtr
CANGetRxDataTypX
CANPutTxCID
CANPutTxCnt
CANGetTxDataPtr
CANPutTxDataTypX
CANInit
About the Sample Firmware
FIGURE 4: Basic Object Model
FIGURE 5: Project Files
Future Objects
Memory Usage
Summary
Appendix A: Source Code
Worldwide Sales and Service
DeviceNet™ Group 2 Slave Firmware for PIC18 with CAN AN877 Author: Ross Fosler Microchip Technology Inc. INTRODUCTION The DeviceNet™ system is an open network standard, built on the Controller Area Network (CAN), designed to reduce the cost and time to install industrial devices while providing compatibility with multiple vendors. The DeviceNet specification is available from the Open DeviceNet Vendor Association, Inc. (ODVA). Example DeviceNet devices might include motor starters, valves, sensors, displays and more. The DeviceNet specification covers multiple layers, from the wiring and protection circuits, up to the software protocol and application definition (see Figure 1); however, this application note only focuses on a specific development of the software known in the specification as the Predefined Master/Slave Connection Set. To be even more accurate, this application note only presents a slave node within the Predefined Connection Set, also referred to as a Group 2 Slave. The Group 2 Slave developed here is designed with the following features: Supports Polling Messaging Supports Multicast Polling Messaging Supports Change of State/Cyclic Messaging Supports Bit Strobe Messaging Supports Acknowledged Fragmentation Supports Unacknowledged Fragmentation This application note, with attached firmware, is pro- vided to accelerate the process to design a Group 2 Slave node but not do all of the work. There are many details to a slave node that require an understanding of the target application; therefore, this implementation is provided in a very general form with numerous config- urable parameters, event handling functions and vari- ables that must be set or developed for the application. Essentially, you cannot develop a DeviceNet applica- tion without some knowledge of the DeviceNet system and its specification. It is a good idea to have the complete specification available for reference while designing a node. The firmware associated with this document may change as new features are added. Throughout this application note, there are references to the specification. All references are to Volume I of the specification unless otherwise noted. FIGURE 1: LAYER PROTOCOL DeviceNet™ Protocol Application Layer CAN Protocol Physical Layer Data Link Layer Physical Layer Transmission Media Media Layer OVERVIEW OF THE FIRMWARE The DeviceNet system is described in the specification as a collection of objects. Figure 2 shows a simplified view of the object model. There are a number of possi- ble objects within the object model but the required objects include: Connection Object Message Router Object Identity Object DeviceNet Object These are the objects that are developed in this application note. Other objects not listed may become available in future revisions of the firmware. The Connection Object The Connection Object manages all communications between the CAN bus and higher level objects and contains a number of source files. It can contain multiple instances as defined by the Predefined Master/Slave Connection Set (see Chapter 7 of the specification). Table 1 lists the files associated with the Connection Object.  2003 Microchip Technology Inc. DS00877A-page 1
AN877 The DeviceNet Object The Identity Object In this design, there is one instance of the DeviceNet Object. It contains network related information about the node, such as baud rate, MAC ID and more. It is split into two source files as shown in Table 2; one file contains lower level information, while the other is application dependent and requires development based on the requirements of the application. The Identity Object contains information that identifies the device, such as serial number and description. Like the DeviceNet Object and the Connection Object, there are some application specific dependencies that must be developed for the Identity Object. Table 3 identifies the files associated with the Identity Object. The Router Object The Router Object routes Explicit Messages to the appropriate object. In this design, routes are static, plus the object has no external visibility over the DeviceNet system. FIGURE 2: SIMPLE OVERVIEW OF OBJECT CONNECTION Application Related Objects Identity Object I / O M e s s a g i n g Message Router Messaging Explicit Connection Object DeviceNet™ Object CAN bus DS00877A-page 2  2003 Microchip Technology Inc.
AN877 TABLE 1: CONNECTION OBJECT RELATED FILES File Name Description conn.c conn1.c conn2.c conn3.c conn4.c conn5.c conn6.c conn7.c frag.c CAN.C EMM.c UEMM.c NASM.c UsrConn.c This file contains several connection managing functions to capture communications events and dispatch them to appropriate instances or other managing functions. This file provides the Predefined Explicit Messaging connection functionality. This file provides the Predefined Polled/Change of State/Cyclic I/O Messaging connection functionality. This file provides the Predefined Bit Strobed I/O Messaging connection functionality. This file provides the Predefined Change of State/Cyclic I/O Messaging connection functionality. This file provides the Predefined Multicast Polled I/O Messaging connection functionality. This file provides the Unconnected Explicit Messaging functionality which looks similar to other regular I/O connections, but does not support all the events and fragmentation. This file provides the Duplicate MAC ID Messaging functionality which looks similar to other regular I/O connections, but does not support all the events and fragmentation. This file contains the I/O Fragmentation managing functions. This file contains the abstracted CAN driver routines. The functions are abstract to support the possibility of having a variety of CAN options. This file is referred to as the Explicit Messaging Manager. It contains functions to interface Explicit Messaging to the router. Routing specific information is parsed and placed in the Router Object. This file is referred to as the Unconnected Explicit Messaging Manager. It contains functions to interface Unconnected Explicit Messaging to the router. However, only the “Allocate” and “Release” commands directed to the DeviceNet Object are allowed; all other messages are ignored. This file contains the Network Access State Machine functions. These functions are bound together with the Identity Object and the Duplicate MAC ID Message. Application specific logic for the Connection Object is contained within this file; therefore, this file must be developed for the application. TABLE 2: DeviceNet OBJECT RELATED FILES File Name dnet.c UsrDNet.c Description This file contains most of the required logic for the DeviceNet Object. It contains DeviceNet global variables and Explicit Message handling for the commands identified in Section 5-5 of the specification. Logic that depends on the application is contained within this file; therefore, this file must be developed for the application. TABLE 3: IDENTITY OBJECT RELATED FILES File Name ident.c UsrIdent.c Description This file contains most of the required logic for the Identity Object. It contains global variables and Explicit Message handling for the commands identified in Volume II, Section 6-2 of the specification. Logic that depends on the application is contained within this file; therefore, this file must be developed for the application. TABLE 4: ADDITIONAL HELPER FILES File Name class.h errors.h typedefs.h Defined classes of objects. Defined Explicit Messaging errors. Internal data types. Description  2003 Microchip Technology Inc. DS00877A-page 3
AN877 THE CONNECTION OBJECT The Connection Object, as shown in Figure 3, is the largest and most complex object in the design. Within the object, all data and error events must be managed which explains the complexity. All events are received by the managing functions within the conn.c file through calls to the CAN driver. The events are decoded and dispatched to the appro- priate instance based on the availability of the connec- tion. Note that an instance of a connection does not exist until it is explicitly created (see Section 5-5 of the specification). The only two messages that are received without explicitly instantiating a connection are the Unconnected Explicit Request Message and the Duplicate MAC ID Check Message (see Section 7-2 of the specification). Once instantiated, each instance manages the events that it receives. In general, the events include: ConnxCreate – Creates the object ConnxClose – Closes the object ConnxTimerEvent – Handles connection related timers ConnxRxEvent – Handles received data ConnxTxOpenEvent – Handles transmit availability ConnxTxEvent – Notification when data has been put on the bus ConnxExplicitEvent – Handles Explicit Messaging requests At the upper level of the Connection Object are addi- tional managers which process the received data for the instances. This includes Unconnected and Con- nected Explicit Message handling, Network Access Control (see Chapter 6 of the specification) and the application specific I/O. FIGURE 3: THE CONNECTION OBJECT AND HIGHER MANAGEMENT OBJECTS Explicit Message Manager (EMM.c) User I/O Interface (UsrConn.c) Unconnected Explicit Message Manager (UEMM.c) Network Access Manager (NASM.c) Inst. 1 (conn1.c) Inst. 2 (conn2.c) Inst. 3 (conn3.c) Inst. 4 (conn4.c) Inst. 5 (conn5.c) Msg. 6 (conn6.c) Msg. 7 (conn7.c) Abstract CAN Driver Functions (CAN.C) Tx, Rx, Fragmentation, and Time Managing Functions (conn.c, frag.c) DS00877A-page 4  2003 Microchip Technology Inc.
Internal Connection Object Services The Connection Object manages I/O connection data movement to and from the user supplied buffer. It is up to the application to decide how to handle the data above the Connection Object. AN877 There are up to four possible predefined instances that are defined (see Chapter 7 of the specification): Polled Messaging Bit Strobed Messaging Cyclic/Change of State Messaging Multicast Polled Messaging Some basic internal services are provided through the Connection Object for the purpose of managing I/O data. mConnReadRdy Query the Connection Object to determine the status of the read buffer of the specified connection number. Returns true if a message has been received and is waiting in the receive buffer. Valid numbers are 1 through 7; however, only numbers 2 through 5 should be used since these are where the I/O connections reside. Syntax unsigned char mConnReadRdy (unsigned char hInstance) Example if (mConnReadRdy(2)) { // Process application stuff ApplicationProcess(); // Free the connection to accept more data mConnRead(2); } mConnWriteRdy Query the Connection Object to determine the status of the write buffer of the specified connection number. Returns true if the buffer is open to accept new data from transmission. Valid numbers are 1 through 7; however, only numbers 2 through 5 should be used since these are where the I/O connections reside. Syntax unsigned char mConnWriteRdy (unsigned char hInstance) Example if (mConnWriteRdy(2)) { // Process application stuff ApplicationProcess(); // Release the connection to write the data mConnWrite(2); }  2003 Microchip Technology Inc. DS00877A-page 5
AN877 mConnRead Calling this function with the appropriate instance number will indicate to the Connection Object that all data has been processed and the connection should be ready to receive more data. Syntax void mConnRead (unsigned char hInstance) mConnWrite Calling this function with the appropriate instance number will indicate to the Connection Object that all data has been loaded into the connection’s buffer for transmitting on the bus. Syntax void mConnWrite (unsigned char hInstance) DS00877A-page 6  2003 Microchip Technology Inc.
Connection Object Events There are events and global registers that cannot be defined without the application. For this reason, they are passed up to the UsrConn.c object for application specific processing. Code must be developed in this file to manage appropriate events. Upon instantiation, a “Create Event” is generated with the appropriate instance number passed. This event must be handled to set up some application dependent attributes. The attributes that must be set up are: Produced path Consumed path Produced path length Consumed path length Pointer to the consumed data Pointer to the produced data Length of the consumed data Length of the produced data Like the “Create Event”, there is also a “Close Event” when the connection is closed. This is provided to notify the application when the connection is no longer available. AN877 Two other events that may or may not necessarily be set up are the “Rx Event” and the “Tx Event”. These events are generated when data has been transmitted or received. These are provided for any application specific event handling; however, they do not neces- sarily need to be handled as an event. Receive and transmit can be polled through normal Connection Object functions. One other event is the “Set Attribute Event”. This event must be handled for any attribute that is not entirely dependent on the Connection Object alone. The attributes are: _ATTRIB_CLASS_TRIGGER _ATTRIB_PRODUCED_CONN_PATH _ATTRIB_CONSUMED_CONN_PATH _ATTRIB_PRODUCED_CONN_SIZE Not all attributes are required to be settable; however, the event must be handled to generate an error if the event occurs. UsrConnCreateEvent This event function is called when a connection is created by an allocate request. The instance number is passed indi- cating the source of the event. This event is an indication to the application to provide resources necessary for the con- nection to function. Other than application specific resources, buffer space and path information must be provided. If resources are not available, then the application should return ‘0’ to this event; otherwise, the application should return any other value to allow the creation of the connection. Syntax unsigned char UsrConnCreateEvent (unsigned char hInstance) Example unsigned char UsrConnCreateEvent(unsigned char hInstance) { switch (hInstance) { case 2: // Set path information according to Appendix I // of the DeviceNet specification // Set the connection sizes uConn2.attrib.consumed_con_size.word = 13; uConn2.attrib.produced_con_size.word = 20; // Set the pointers to the buffers uConn2.rx.pMsg = uConn2RxBuffer; uConn2.tx.pMsg = uConn2TxBuffer; return(1); case 3: // Set path and connection information return(1); case 4: // Set path and connection information return(1); case 5: // Set path and connection information return(1); } }  2003 Microchip Technology Inc. DS00877A-page 7
AN877 UsrConnCloseEvent This event function is called when a connection is closed by a time-out or release request. The instance number is passed indicating the source of the event. This event is an indication to the application to release any allocated resources. Syntax void UsrConnCloseEvent (unsigned char hInstance) UsrConnRxDataEvent This event function is called when a connection has received data. The instance number is passed indicating the source of the event. Syntax void UsrConnRxDataEvent (unsigned char hInstance) UsrConnTxDataEvent This event function is called when a connection has transmitted its data. The instance number is passed indicating the source of the event. Syntax void UsrConnTxDataEvent (unsigned char hInstance) UsrConnSetAttribEvent This event is generated when an attribute that is defined by the application has been requested to be changed by an Explicit Message. The application must decode the attribute and generate an appropriate response to the request. Refer to the Router Object for details on internal services to handle Explicit Message responses. Syntax void UserConnSet AttribEvent (unsigned char hInstance) Example switch (mRouteGetAttributeID()) { case _ATTRIB_CLASS_TRIGGER: // Process request to set this attribute break; case _ATTRIB_PRODUCED_CONN_PATH: // Process request to set this attribute break; case _ATTRIB_CONSUMED_CONN_PATH: // Process request to set this attribute break; case _ATTRIB_PRODUCED_CONN_SIZE: // Process request to set this attribute break; } DS00877A-page 8  2003 Microchip Technology Inc.
分享到:
收藏