C28x CAN Calibration Protocol

Implement CAN Calibration Protocol (CCP)

  • Library:
  • Embedded Coder Support Package for Texas Instruments C2000 Processors / C2803x

    Embedded Coder Support Package for Texas Instruments C2000 Processors / C2805x

    Embedded Coder Support Package for Texas Instruments C2000 Processors / C2806x

    Embedded Coder Support Package for Texas Instruments C2000 Processors / C280x

    Embedded Coder Support Package for Texas Instruments C2000 Processors / C281x

    Embedded Coder Support Package for Texas Instruments C2000 Processors / C2833x

    Embedded Coder Support Package for Texas Instruments C2000 Processors / C2834x

    Embedded Coder Support Package for Texas Instruments C2000 Processors / F28004x

Description

The CAN Calibration Protocol block provides an implementation of a subset of the Controller Area Network (CAN) calibration protocol (CCP) version 2.1. CCP is a protocol for communicating between the target processor and the host machine over a CAN. A calibration tool (see Compatibility with Calibration Packages) running on the host can communicate with the target, allowing remote signal monitoring and parameter tuning.

This block processes a command receive object (CRO) and outputs the resulting data transmission object (DTO) and data acquisition (DAQ) messages.

For more information about CCP, refer to ASAM Standards: ASAM MCD: MCD 1a at the Association for Standardization of Automation and Measuring Systems (ASAM) website: https://www.asam.net.

Using the DAQ Output

Note

The CCP DAQ list mode of operation is only supported with Embedded Coder®. If Embedded Coder is not available, then custom storage classes canlib.signal are ignored during code generation, which means that the CCP DAQ list mode of operation cannot be used.

You can use the CCP polling mode of operation with or without Embedded Coder.

The DAQ output is the output for CCP DAQ lists that have been set up. You can use the ASAP2 file generation feature of the real-time target to:

  • Set up signals to be transmitted using CCP DAQ lists.

  • Assign signals in your model to a CCP event channel automatically (see Generate an ASAP2 File (Simulink Coder)).

After these signals are set up, event channels periodically fire events that trigger the transmission of DAQ data to the host. When this occurs, CAN messages with the CCP/DAQ data appear in the DAQ output, along with an associated function call trigger.

The calibration tool (see Compatibility with Calibration Packages) must use CCP commands to assign an event channel and data to the available DAQ lists. Based on the assignment, the calibration tool interprets the synchronous response.

Using DAQ lists for signal monitoring has these advantages over the polling method:

  • The host does not need to poll for the data. Network traffic is halved.

  • The data is transmitted at the update rate that matches the signal, reducing network traffic.

  • Data is consistent. The transmission takes place after the signals have been updated, reducing interruptions while sampling the signal.

Parameters

expand all

The station address is interpreted as a uint16 data type. It is used to distinguish between different targets. By assigning unique station addresses to targets sharing the same CAN bus, a single host can communicate with multiple targets.

If your processor has more than one module, select the module this block configures.

The CAN message identifier of the command receive object (CRO) message you want to process.

The incoming message type of the command receive object.

The CAN message ID used for DTO and DAQ message outputs.

The message type to be transmitted by DTO and DAQ outputs.

ODTs are shared equally between all available DAQ lists. You can choose a value in the range of 0 to 254, depending on the number of signals you log simultaneously. You must allocate at least one ODT per DAQ list, or your build may fail. The calibration tool gives an error message if there are too few ODTs for the number of signals you specify for monitoring. However, too many ODTs can make the sample time overrun. If you choose more than the maximum number of ODTs (254), the build fails.

A single ODT uses 7 bytes of memory. Using all 254 ODTs requires 1778 bytes or more of memory, a large proportion of the available memory on the target. To conserve memory on the target, the default number is low, allowing DAQ list signal monitoring with reduced memory overhead and processing power.

As an example, if you have five different rates in a model, and you are using three rates for DAQ, this creates three DAQ lists. You must ensure that you have at least three ODTs. ODTs are shared equally among DAQ lists, and therefore, you end up with one ODT per DAQ list. With less than three ODTs for three DAQ lists, the behavior is undefined.

Taking this example further, say you have three DAQ lists with one ODT each, and you are monitoring signals in a calibration tool. If you try to assign too many signals to a particular DAQ list, thereby requiring more space than 7 bytes, the calibration tool reports an error.

The sample time for CRO messages. To execute this block asynchronously, set this parameter to -1.

More About

expand all