- Table of Contents
- Configuration Overview
This chapter shows how to incorporate the CCB support into an eCos configuration, and how to configure it once included.
The CCB support is contained in a single eCos package CYGPKG_IO_CCB. However, it depends on the services of a collection of other packages for complete functionality. For example, the CYGPKG_KERNEL, CYGPKG_ERROR and CYGPKG_IO_FILEIO packages.
Incorporating the CCB support into your application is
straightforward. The essential starting point is to incorporate the
CCB eCos package (
CYGPKG_COHERENT_CCB) into your
This may be achieved directly using ecosconfig add on the command line, or the Build->Packages... menu item within the eCos Configuration Tool.
Depending on the CCB package configuration other packages may be required (e.g. UART device driver support). The package requires that the CYGPKG_KERNEL and CYGPKG_ERROR packages are included in the eCos application configuration.
It is recommended to include the CYGPKG_IO_FILEIO
select() functionality to allow
client-applications to avoid having to use a busy message read loop.
This option defines the maximum size of message that can be received, and should include space for the standard message header. The default value caters for the maximum possible message size. For low-memory targets or where the maximum message sizes are fixed and known for all bus nodes, then this option can be tuned to minimise the memory footprint. Any messages that exceed this configured size will be dropped.
The value of this option is used to define the buffer sizes required by the low-level I/O driver to accept packets.
This option defines the maximum number of pending received messages that can be queued for the client application. As per the Coherent Connection Bus Protocol “Only complete messages are buffered; if there is not enough buffer space remaining for a new message, the message will be discarded”. This option can be tuned to reflect the ability of the client application to read and process messages, against the memory footprint required for each descriptor.
The CCB subsystem uses an internal thread to handle asynchronous actions and to process packet reception. This option defines the ADDITIONAL size that is added to the variant CYGNUM_HAL_STACK_SIZE_TYPICAL setting to define the stack size for this thread.
The CCB subsystem uses an internal thread to handle asynchronous actions. This option defines the priority at which this thread is scheduled. To avoid resource starvation issues it should normally be a higher priority than the thread implementing the CCB client-application.
The common CCB server support is enabled by the CYGPKG_IO_CCB_MASTER option. When enabled it provides access to the following relevant options.
This option specifies the maximum number of slave devices supported across all of the physical CCB ports present. This is used to avoid the need for dynamic allocation, but does mean that the value may need to be tuned to reflect the application and variant/platform usage. The maximum of 253 reflects the total unit bus limit. The master will ignore address acquisition requests when the pool of slave descriptors is exhausted.
The default value of 1 reflects the expected use case of a single physical interface (port) with only a single slave device connected to that RS-485 bus. If the implementation provides multiple hardware ports, or expects multiple slaves per hardware port then this configuration option should be updated accordingly.
This option specifies the maximum length of the per-slave unique identifiers supported. The default is to accept all slaves by using the maximum possible length (this option includes space for the NUL-terminator). For targets with limited memory resources, or where the application is limited to a known set of device identifier lengths, this value can be tuned to save on the run-time memory footprint. Slave devices with identifiers longer than this option will be ignored.
If a message has not been received from an assigned address for the period of time (in seconds) specified by this option then the master CCB stack will issue a PING request to the slave. After the fixed number of retries (CYGNUM_IO_CCB_MASTER_SLAVE_POLL_ATTEMPTS) without a response a slave is considered disconnected.
Note: An eCos CCB package extension disables the slave polling if this option is set to zero (0). Such a configuration would not be conformant with the CCB protocol definition.
This option defines the period (in seconds) that the master CCB stack will wait between PING requests. A slave is declared disconnected if no response is received after CYGNUM_IO_CCB_MASTER_SLAVE_POLL_ATTEMPTS.