The information in this document is for informational purposes only. Please inform HMS Industrial Networks of any
inaccuracies or omissions found in this document. HMS Industrial Networks disclaims any responsibility or liability
for any errors that may appear in this document.
HMS Industrial Networks reserves the right to modify its products in line with its policy of continuous product
development. The information in this document shall therefore not be construed as a commitment on the part of
HMS Industrial Networks and is subject to change without notice. HMS Industrial Networks makes no commitment
to update or keep current the information in this document.
The data, examples and illustrations found in this document are included for illustrative purposes and are only
intended to help improve understanding of the functionality and handling of the product. In view of the wide range
of possible applications of the product, and because of the many variables and requirements associated with any
particular implementation, HMS Industrial Networks cannot assume responsibility or liability for actual use based on
the data, examples or illustrations included in this document nor for any damages incurred during installation of the
product. Those responsible for the use of the product must acquire sufficient knowledge in order to ensure that the
product is used correctly in their specific application and that the application meets all performance and safety
requirements including any applicable laws, regulations, codes and standards. Further, HMS Industrial Networks will
under no circumstances assume liability or responsibility for any problems that may arise as a result from the use of
undocumented features or functional side effects found outside the documented scope of the product. The effects
caused by any direct or indirect use of such aspects of the product are undefined and may include e.g. compatibility
issues and stability issues.
®
Anybus
CompactCom
is a registered trademark of HMS Industrial Networks.
™
is a trademark of HMS Industrial Networks.
All other trademarks are the property of their respective holders.
When starting an implementation of the Anybus CompactCom 30 or the Anybus CompactCom
40, host application example code is available to speed up the development process. The host
application example code includes a driver, which acts as glue between the Anybus CompactCom
module and the host application. The driver has an API (Application Programming Interface),
which defines a common interface to the driver. Also included in the example code is an example
application which makes use of the API to form an application that can be used as a base for the
final product.
This guide is developed to describe a step-by-step implementation of the Anybus CompactCom driver and
example application. The programmer is requested to have basic knowledge in the Anybus CompactCom
object model and the communication protocol before starting the implementation.
This document is based on the contents of version 3.06 of the host application example code.
The guide is divided into two steps:
Step One: The adaptations needed for the target hardware are done here and a simple application is
developed. The goal with this step is to make sure that the hardware specific code is working and that it
is possible to connect to the network and exchange a limited amount of data.
Step Two: The code is adapted to the target product. The goal with this step is to customize the code
and add to it, to configure the data that will be sent on the network. After this, the application can be
further extended and improved.
The driver is fully OS independent and it can even be used without an operating system, if
required. Furthermore, it can be used for Anybus CompactCom 30 modules as well as Anybus
CompactCom 40 modules. The driver supports multiple operating modes, where selection of one
of the implemented modes can be made at runtime.
It is possible to use modules from the 30- and the 40-series in the same application, see 30- and
40-series Modules in the Same Application, p. 51.
The host application example code is available in different versions for different platforms. When
writing this guide, the platforms depicted below are available.
Each folder contains all files for a specific platform/development environment.
Platform
Generic
Xilinx, MicroZed
ST, STM3240-EVAL
NXP, TWRP1025
HMS, USB II BoardVisual StudioUsed for the HMS Starter Kit hardware (USB board)
Reference Project/Tool Chain
-
GNU
Keil µVisionUsed for the STM3240-EVAL evaluation platform
IAR Embedded WorkbenchUsed for the STM3240-EVAL evaluation platform
Code WarriorUsed for the NXP TWRP1025 evaluation platform
Description
Can be ported to any platform
Used for the Microzed evaluation platform with
Anybus IP
®
Anybus
CompactCom™Host Application Implementation Guide
HMSI-27-334 1.7 en-US
Introduction6 (54)
Host Applicaon ObjectsADI/Process Data
CompactCom Applicaon HandlerMain Loop
Example Applicaon
API
CompactCom Driver
System Adaptaon Layer
Anybus Physical Interface
2.1Overview
Parts of the driver code need to be adapted to the host application platform. This generally
includes functions which access the Anybus host interface, or functions which need to be
adapted to integrate the driver into the host system. The figure below shows the different parts
of the host application example code.
Fig. 1Software overview
The host application example code is divided into five different folders depending on the
functionality and whether the files need to be adapted or not by the user.
Folder Structure
/abcc_abp (part of the driver - read only)
/abcc_drv (part of the driver - read only)
/abcc_adapt
/abcc_obj
/example_app
Contains all Anybus object and communication protocol definitions.
Files may be updated when new Anybus CompactCom releases are
available.
These files are read only and must not be changed in any way by
the user.
Contains source and header files for the driver.
Files may be updated when new Anybus CompactCom releases are
available.
These files are read only and must not be changed in any way by
the user.
Contains configuration files.
These files must be modified by the user to adapt the driver and
the example code to the system environment. Note: If using
example code adjusted to a specific platform, most of the
adaptations needed in this folder are already completed.
Includes all Anybus host application object implementations.
These files can be modified if needed, for optimization and/or
additional features.
Example application including:
– Main state machine to handle initialization, restart, normal and
error states.
– State machine patterns to show how to send Anybus
CompactCom messages.
– Implementation of callbacks required by the driver.
– Definition of ADIs, Application Data Instances, and default
process data mapping setup.
These files have to be adapted to the application by the
programmer. Additionally they may be modified for optimization
and/or additional features.
®
Anybus
CompactCom™Host Application Implementation Guide
HMSI-27-334 1.7 en-US
Introduction7 (54)
2.2Preparations
Before continuing, try to answer as many of the questions below as possible. This will make the
later decisions during implementation easier. It is also good to have access to the hardware
schematics of the target hardware during the implementation.
Step One
Consider the following questions:
•What operating mode, or modes, shall be used in the design?
•What communication interfaces shall be used to communicate with the CompactCom in the
design?
•What networks shall be used in the design?
•Are the networks available in the CompactCom 40 series or is there also a need to use
CompactCom 30 series modules?
•Are the Module Identification pins connected to the host processor?
•Are the Module Detection pins connected to the host processor?
Step Two
Consider the following questions:
•Is the interrupt signal implemented in the hardware?
•What parameters/data shall be communicated on the network in the final product?
–Name
–Data type
–Number of elements
–Read/Write access
–Acyclic access, Cyclic access
–Max/Min/Default values
•Which events (diagnostics) shall be reported on the network?
•What network identification parameters are available? E.g. Vendor ID, Product Code, Id
number etc.
•...implemented the system specific functions needed to communicate with the Anybus
CompactCom.
•...compiled the host application example code with default settings.
•...exchanged data between the host application and the network master/scanner.
3.2System Set-up
These defines can be found in abcc_adapt/abcc_td.h.
General settings for the system environment, to be used in the driver, are configured here.
3.2.1Big- or Little Endian
Configure if the host application is a big endian system or a little endian system. Define ABCC_
SYS_BIG_ENDIAN if it is a big endian system. Do not define (leave as default) if the host
application is a little endian system.
8 (54)
#define ABCC_SYS_BIG_ENDIAN/* Big endian host application */
/* #define ABCC_SYS_BIG_ENDIAN */ /* Little endian host application */
3.2.216–bit Char System
Configure if the host application is a 16-bit char system or an 8-bit char system (i.e. if the
smallest addressable type is 8-bit or 16-bit). Define ABCC_SYS_16BIT_CHAR if it is a 16-bit
char system. Do not define (leave as default) if it is an 8-bit char system. Configuring of 16-bit
char for an 8-bit char system is not recommended.
#define ABCC_SYS_16_BIT_CHAR/* 16 bit char system */
/* #define ABCC_SYS_16_BIT_CHAR */ /* 8 bit char system */
3.2.3Extended Bus Endian Difference
If the endianness for the external parallel data bus differs from the internal data bus endianness,
enable this define. If parallel 16-bit operating mode is not used, this define is ignored.
Define the Data Types for the current system. For 16-bit char systems, all 8-bit types shall be
typed to 16-bit types. The following data types must be defined:
9 (54)
BOOL
BOOL8
INT8
INT16
INT32
UINT8
UINT16
UINT32
FLOAT32
Standard boolean data type.
Standard boolean data type, 8-bit.
Standard signed 8-bit data type.
Standard singed 16-bit data type.
Standard signed 32-bit data type.
Standard unsigned 8-bit data type.
Standard unsigned 16-bit data type.
Standard unsigned 32-bit data type.
Float (according to IEC 60559).
3.3Anybus CompactCom Set-up
These defines and functions are found in abcc_adapt/abcc_drv_cfg.h. Detailed
descriptions are available in abcc_drv/inc/abcc_cfg.h.
Settings for how to use and communicate with the Anybus CompactCom. Operating mode,
interrupt handling, memory handling etc., are configured here.
3.3.1Communication Interfaces and Operating Modes
Define the communication interfaces and the operating mode between the host application and
the CompactCom (Parallel, SPI, Serial), that will be used in the implementation. There are several
possibilities to set the operating mode depending on how the host application is intended to
communicate with the Anybus and also depending on how the operating mode is selected by the
user.
•First, define all communication interfaces that will be supported by the implementation. All
interfaces that will be used must be defined here, otherwise an error will be reported later
on. Only define the interfaces that will really be used, since every enabled interface will
increase the compiled code size.
ABCC_CFG_DRV_SERIAL and ABCC_CFG_DRV_PARALLEL_30 use the CompactCom half duplex
communication protocol, with limited data sizes for process data and message data.
•Get the operating mode from external hardware - If the operating mode is set e.g. via a dipswitch connected to the host application processor or via an HMI controller, define the
ABCC_CFG_OP_MODE_GETTABLE and implement the function ABCC_SYS_GetOpmode
() in abcc_adapt/abcc_sys_adapt.c.
#define ABCC_CFG_OP_MODE_GETTABLE ( TRUE )
If not defined, the operating mode defines must be explicitly defined for the specific module
type. (See ABCC_CFG_ABCC_OP_MODE_30 and ABCC_CFG_ABCC_OP_MODE_40
below).
•If the operating mode pins on the CompactCom host connector can be controlled by the
host processor, define ABCC_CFG_OP_MODE_SETTABLE and implement the function
ABCC_SYS_SetOpmode() in abcc_adapt/abcc_sys_adapt.c.
#define ABCC_CFG_OP_MODE_SETTABLE ( TRUE )
If not defined, it is assumed that the operating mode signals of the CompactCom host
connector are fixed or controlled by external hardware, e.g. a dip-switch.
•If only one operating mode per module type (CompactCom 30 and CompactCom 40) is
used, define the operating mode with ABCC_CFG_ABCC_OP_MODE_30 and ABCC_CFG_
ABCC_OP_MODE_40. The available operating modes (ABP_OP_MODE_X) can be found in
abcc_abp/abp.h.
If parallel operating mode (8-bit or 16-bit) is not used, this section can be ignored.
If direct access to the CompactCom memory is available (the host controller provides dedicated
signals to access external SRAM), define ABCC_CFG_MEMORY_MAPPED_ACCESS to TRUE and
define the base address with ABCC_CFG_PARALLEL_BASE_ADR (this address must be
defined to suit the host platform).
#define ABCC_CFG_MEMORY_MAPPED_ACCESS ( TRUE )
#define ABCC_CFG_PARALLEL_BASE_ADR ( 0x00000000 )
If direct access to the CompactCom memory is not available, several functions to read and write
data must be implemented in abcc_adapt/abcc_sys_adapt.c (described in abcc_drv/inc/abcc_sys_adapt_par.h).
The recommendation is to have direct access to the CompactCom memory if possible for a simpler and
most often faster implementation.
3.3.3SPI Operating Mode Specifics
11 (54)
Only for 40-series. If SPI operating mode is not used, this section can be ignored.
The length of an SPI message fragment in bytes per SPI transaction is defined with ABCC_CFG_
SPI_MSG_FRAG_LEN.
If the ABCC_CFG_SPI_MSG_FRAG_LEN value is less than the largest message to be
transmitted, the sending or receiving of a message may be fragmented and take several SPI
transactions to be completed. Each SPI transaction will have a message field of this length
regardless if a message is present or not. If messages are important the fragment length should
be set to the largest message to avoid fragmentation. If IO data are important the message
fragment length should be set to a smaller value to speed up the SPI transaction.
For high message performance a fragment length up to 1524 octets is supported. The message
header is 12 octets, so 16 or 32 octets will be enough to support small messages without
fragmentation.
•If the Module Identification pins (MI) on the CompactCom host connector are not
connected to the host processor, ABCC_CFG_MODULE_ID_PINS_CONN must be defined
as FALSE, and ABCC_CFG_ABCC_MODULE_ID must be defined to the correct
CompactCom module ID that corresponds to the module ID of the used device. If defined, it
shall be set to the correct ABP_MODULE_ID_X definition from abcc_abp/abp.h.
If ABCC_CFG_MODULE_ID_PINS_CONN is defined as TRUE, the function ABCC_SYS_ReadModuleId() in abcc_adapt/abcc_sys_adapt.c must be implemented.
The recommendation is to connect the Module ID pins on the application connector directly to GPIO-pins
on the host processor and implement the ABCC_SYS_ReadModuleId() function.
•If the Module Detect pins (MD) in the host application connector are connected to the host
processor, the ABCC_CFG_MOD_DETECT_PINS_CONN shall be set to TRUE and the
ABCC_SYS_ModuleDetect() function in abcc_adapt/abcc_sys_adapt.c must
be implemented.
#define ABCC_CFG_MOD_DETECT_PINS_CONN ( TRUE )
12 (54)
3.3.5Message and Process Data Settings
Leave the following defines with the default values for now.
#define ABCC_CFG_MAX_NUM_APPL_CMDS
#define ABCC_CFG_MAX_NUM_ABCC_CMDS
#define ABCC_CFG_MAX_MSG_SIZE
#define ABCC_CFG_MAX_PROCESS_DATA_SIZE
#define ABCC_CFG_REMAP_SUPPORT_ENABLED
#define ABCC_CFG_CMD_SEQ_MAX_NUM_RETRIES
#define ABCC_CFG_MAX_NUM_CMD_SEQ
The different platforms can have different default values depending on the available resources.
If the IRQ pin is connected the driver can be configured to check if an event has occurred even if
the interrupt is disabled. It can be used e.g. to detect the CompactCom power up event. Define
ABCC_CFG_POLL_ABCC_IRQ_PIN to enable this functionality, and implement the function
ABCC_SYS_IsAbccInterruptActive() in abcc_adapt/abcc_sys_adapt.c.
#define ABCC_CFG_POLL_ABCC_IRQ_PIN ( TRUE )
In this step, we will not use the interrupt functionality, which means that we will define ABCC_
CFG_INT_ENABLED as FALSE.
If the IRQ pin is not connected, this define must be set to false.
#define ABCC_CFG_INT_ENABLED ( FALSE )
3.3.7Communication Watchdog Settings
The timeout for the CompactCom communication watchdog is configured with ABCC_CFG_WD_
TIMEOUT_MS. If a timeout occurs, the callback function ABCC_CbfWdTimeout() is called.
The watchdog functionality is only supported by the SPI-, serial- and
parallel30 (half duplex) operating modes.
13 (54)
#define ABCC_CFG_WD_TIMEOUT_MS ( 1000 )
3.3.8ADI Settings
Leave the following defines with the default values for now.
#define ABCC_CFG_STRUCT_DATA_TYPE ( FALSE )
#define ABCC_CFG_ADI_GET_SET_CALLBACK ( FALSE )
#define ABCC_CFG_64BIT_ADI_SUPPORT ( FALSE )
3.3.9Debug Event Print Settings
For development purposes, a number of debug functions are available for the developer. The
following defines affects debug printouts from the driver. If additional printouts are needed from
the application code, use the ported function ABCC_PORT_DebugPrint() in abcc_adapt/abcc_sw_port.h.
•Enable or disable the error reporting callback function ABCC_CbfDriverError() with
ABCC_CFG_ERR_REPORTING_ENABLED. The function is described in abcc_drv/inc/
abcc.h.
#define ABCC_CFG_ERR_REPORTING_ENABLED ( TRUE )
•Enable or disable driver support for print out of debug events within the driver with ABCC_
CFG_DEBUG_EVENT_ENABLED. ABCC_PORT_DebugPrint() in abcc_adapt/
abcc_sw_port.h will be used to print debug information.
#define ABCC_CFG_DEBUG_EVENT_ENABLED ( TRUE )
•Enable or disable printout of debug information, such as file name and line number, when
ABCC_CbfDriverError() is called with ABCC_CFG_DEBUG_ERR_ENABLED.
•Enable or disable printout of received and sent messages with ABCC_CFG_DEBUG_MESSAGING. Related events such as buffer allocation and queuing information is also
printed.
#define ABCC_CFG_DEBUG_MESSAGING ( FALSE )
•Enable or disable printout of command sequencer actions with ABCC_CFG_DEBUG_CMD_
SEQ_ENABLED.
#define ABCC_CFG_DEBUG_CMD_SEQ_ENABLED ( FALSE )
3.3.10Startup Time
If the CompactCom IRQ pin is connected, ABCC_CFG_STARTUP_TIME_MS will be used as a
timeout while waiting for the CompactCom to become ready for communication. An error
(APPL_MODULE_NOT_ANSWERING) will be reported if the start-up interrupt is not received
within this time. If the interrupt pin is not available ABCC_CFG_STARTUP_TIME_MS will serve
as time to wait before starting to communicate with the CompactCom. If not defined, the default
value is 1500 ms.
#define ABCC_CFG_STARTUP_TIME_MS ( 1500 )
If possible, the recommendation is to use the startup interrupt (option available for the SPI and parallel
communication interfaces).
14 (54)
3.3.11Sync Settings
Only for 40-series.
Leave the following defines with the default values for now.
#define ABCC_CFG_SYNC_ENABLE ( FALSE )
#define ABCC_CFG_SYNC_MEASUREMENT_IP ( FALSE )
#define ABCC_CFG_SYNC_MEASUREMENT_OP ( FALSE )
3.4System Adaptation Functions
A number of functions must be implemented for the driver to be able to access the Anybus
CompactCom. The functions shall be implemented in abcc_adapt/abcc_sys_adapt.c.
The functions are described per operating mode in the files specified below.
These functions can be found in abcc_drv/inc/abcc_sys_adapt.h.
ABCC_SYS_HwInit()
This function can be used to initiate the hardware required to communicate with the
CompactCom device (e.g. configuring the direction and initial values of used host processor port
pins). This function shall be called once during the power up initialization.
Note: Make sure that the CompactCom is kept in reset state when returning from this function.
ABCC_SYS_Init()
This function is called by the driver at start-up and restart of the driver. If needed, any hardware
or system dependent initialization shall be done here. If not used, leave the function empty.
ABCC_SYS_Close()
Called from the driver if the driver is terminated. If resources were allocated in ABCC_SYS_
Init() it is recommended to close or free them in this function. If not used, leave the function
empty.
ABCC_SYS_HWReset()
This function must be implemented to pull the reset pin on the Anybus CompactCom interface to
low.
15 (54)
ABCC_SYS_HWReleaseReset()
This function must be implemented to set the reset pin on the Anybus CompactCom interface to
high.
ABCC_SYS_AbccInterruptEnable()
For now, interrupt will be disabled. Leave this function empty for now.
ABCC_SYS_AbccInterruptDisable()
For now, interrupt will be disabled. Leave this function empty for now.
ABCC_SYS_IsAbccInterruptActive()
If the interrupt pin (IRQ) is connected to the host processor, this function shall read the interrupt
signal from the CompactCom and return TRUE if the interrupt pin is low (i.e. interrupt is active)
and return FALSE if the interrupt pin is high (i.e. the interrupt is inactive). It is used to enable
polling of the interrupt pin of the CompactCom interface if interrupts are not enabled.
ABCC_SYS_SyncInterruptEnable()
For now, synchronization will be disabled. Leave this function empty for now.
ABCC_SYS_SyncInterruptDisable()
For now, synchronization will be disabled. Leave this function empty for now.