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.