Backend Interface

Table of Contents
cyg_mbop_read_discrete_inputs -- Read discrete inputs
cyg_mbop_read_coils -- Read coils
cyg_mbop_write_single_coil -- Write single coil
cyg_mbop_write_multiple_coils -- Write multiple coils
cyg_mbop_read_input_regs -- Read input registers
cyg_mbop_read_holding_regs -- Read holding registers
cyg_mbop_write_single_reg -- Write single holding register
cyg_mbop_write_multiple_regs -- Write multiple holding registers
cyg_mbop_rw_multiple_regs -- Read and/or write multiple holding registers
cyg_mbop_mask_reg -- Mask holding register
cyg_mbop_read_fifo_queue -- Read FIFO contents
cyg_mbop_read_file_record -- Read file records
cyg_mbop_write_file_record -- Write file records
cyg_mbop_read_id -- Return specific extended device ID
cyg_mbop_canopen -- Perform CANOPEN operation

The cyg_modbus_backend_t structure defines the set of handler functions used to implement the support for the relevant MODBUS operation. A simple NUL terminated ASCII name can be provided as a human-readable description of the backend. The application attaches the backend descriptor structure via the cyg_modbus_server_start() function.

Note: To avoid blocking the main MODBUS server processing loop the attached handler functions should NEVER block. The handlers should be written to return control as quickly as possible. If a hardware operation required by the specific MODBUS function then the handler should schedule suitable code, which will asynchronously respond to the request when the required data is available or action has been performed. The provided tests/modbus_ut.c example application provides one possible implementation of such “deferred” support.

If a particular MODBUS function is not supported (or required) by the backend implementation then a NULL pointer can be used, with the server support returning a CYG_MB_EXCEPTION_ILLEGAL_FUNCTION equivalent error to the calling client.

The backend structure is defined in the <cyg/modbus.h> header, which also provides the function prototypes for the individual handlers as detailed over the following pages. The cyg_mbop_ prefix is used for the prototypes to indicate a MODBUS Backend OPeration.

Each handler is passed the parameters ctx and private. The ctx value is an opaque context descriptor for the main server loop, and is used to identify individual transactions via the API. The private parameter is the private context value specified when the backend is registered, and can be the hook for the user application hardware support.

The backend descriptor also provides the BASIC (mandatory) and REGULAR (optional) NUL terminated ASCII identification strings accessed via the MEI Type 14 function code.

The timeout descriptor field is used to force a timely “exception” response back to a client when the backend does not provide a response within the configured number of seconds. This MODBUS control generated timeout exception replaces any subsequent response made by the user-application for the relevant ctx handle.

Other than the device idread function the handlers do not return any error state. The handlers are passed validated requests, and are expected to return a valid response or exception via the provided MODBUS API.

Documentation license for this page: eCosPro License