Configuring clocking in your system

Configure board clocking in your system in one of two ways. Choose only one of these configuration methods across all boards on the CT bus. Otherwise, the two methods interfere with one another, and board clocking does not operate properly.

Method

Details

Using clockdemo application model

Create an application that assigns each board its clocking mode, monitors clocking changes, and re-configures clocking if clock fallback occurs.

A sample clocking application, clockdemo, is provided with Natural Access. clockdemo provides a robust fallback scheme that suits most system configurations. clockdemo source code is included, allowing you to modify the program if your clocking configuration is very complex. For more information, refer to Running clockdemo.

Note: Most clocking applications (including clockdemo) require all boards on the CT bus to be started in standalone mode.

Using board keywords (with or without application intervention)

This method is documented in Configuring the primary clock master, Configuring the secondary clock master, and Configuring clock slaves and standalone boards. Unlike the clockdemo application, which allows several boards to take over mastery of the clock in a fallback situation, the board keyword method allows you to specify only a fixed primary and secondary master. For this reason, the board keyword method is best used only if you do not want to implement clock fallback in your system, or in test configurations where clock reliability is not a factor.

The board keyword method does not create an autonomous clock timing environment. An application must still intervene when clock fallback occurs to reset system clocking before other clocking changes occur. If both the primary and secondary clock masters stop driving the clocks (and an application does not intervene), the boards default to standalone mode.