Chapter 92. API Overview

The main client-application access to CCB functionality is via the common named device /dev/ccb. It is the responsibility of the client-application to open a handle onto this common device, and then to read and write messages as appropriate.

The common layer will automatically start the protocol control thread and use the standard eCos cyg_io interface connection to the specific CCB interface (hardware port) device drivers.

For CYGPKG_IO_FILEIO configurations the client-application can use the open(), write(), read() and select() functions. If CYGPKG_IO_FILEIO is not configured then the standard cyg_io_lookup(), cyg_io_read() and cyg_io_write() function interface is used.

Note: The client-application writes to the CCB are always blocking. The read operations can be configured as non-blocking if required, and if CYGPKG_FILEIO select() support is configured will default to non-blocking operation.

The common and driver-specific CCB packages also provide access to some GET/SET operations that can be accessed via the relevant cyg_fs_fgetinfo/cyg_fs_fsetinfo or cyg_io_get_config/cyg_io_set_config functions. The “key” values supported are:


This key allows a snapshot view of the number of pending client-application RX messages.

Note: As packet reception might occur during calls to this config operation, the information returned may already be stale. If the thread reading this count is the only thread reading messages then this value can be viewed as the minimum number of messages pending. i.e. the client-application should always be able to read the returned number of messages.

A client-application using select() to do a non-busy wait for a message should not normally need to worry about the number of pending messages. This config key support is provided to correspond with the functionality described by the CCB protocol documentation.


This option allows, where provided by the underlying hardware interface port driver, sets of statistics to be monitored. The <cyg/io/ccb_port.h> header file defines the cyg_ccb_devio_stats_t structure used to hold RX and TX information for a specific device driver. This config key functionality uses the <cyg/io/ccb.h> header file defined cyg_ccb_io_stats_t structure to step through the available interface statistics.

The initial cyg_ccb_io_stats_t.priv_ctx field should be initialised to NULL, and then this key config call repeated until the common CCB support returns cyg_ccb_io_stats_t.priv_ctx == NULL (indicating no more data). As per the following pseudocode example:

cyg_ccb_io_stats_t stats;
cyg_bool moredata = true;

stats.priv_ctx = NULL; // start

do {
  int res = cyg_fs_fgetinfo(pcapp->fd,CYG_IO_GET_CONFIG_CCB_STATISTICS,&stats,sizeof(stats));
  if (res < 0) {
    diag_printf("FAIL: Get statistics error %d \"%s\"\n",res,strerror(errno));
    moredata = false;
  if (moredata) {
    moredata = (stats.priv_ctx != NULL);
    if (moredata) {
      diag_printf("Device \"%s\" : RX pkts=%u (bytes=%llu) dropped=%u : TX pkts=%u (bytes=%llu) retrans=%u failed=%u>n",
} while (moredata);

When using a cyg_io_handle_t reference to the common CCB layer then the example above would use the corresponding cyg_io interface:

  Cyg_ErrNo res = cyg_io_get_config(pcapp->handle,CYG_IO_GET_CONFIG_CCB_STATISTICS,&stats,&slen);


Normally the client-application should not need to force a global bus reset. The common CCB layer performs a bus reset as part of the normal application startup. This config “key” may be useful during testing/development, or if an unrecoverable error is detected.

There is also a minimal function call API providing some “stateless“ message helper routines.

Application support API

Table of Contents
cyg_ccb_build_message -- Construct message
cyg_ccb_check_response -- Check response

These functions are available for the client-application to aid in message processing.

See the Testing section's ccb_master test client-application for an example of access to the /dev/ccb and use of these functions.

Documentation license for this page: eCosPro License