| Target Support Package™ TC2 | |
c280xdspchiplib, c281xdspchiplib, and c2833xdspchiplib in Target Support Package™ TC2 software
The CAN Calibration Protocol block provides an implementation of a subset of the CAN Calibration Protocol (CCP) Version 2.1. CCP is a protocol for communicating between the target processor and the host machine over CAN. In particular, 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 on CCP, refer to ASAM Standards: ASAM MCD: MCD 1a on the Association for Standardization of Automation and Measuring Systems (ASAM) website at http://www.asam.de.
Note The CCP Data Acquisition (DAQ) List mode of operation is only supported with Real-Time Workshop® Embedded Coder. If Embedded Coder is not available then custom storage classes canlib.signal are ignored during code generation: this means that the CCP DAQ Lists mode of operation cannot be used. You can use the CCP Polling mode of operation with or without Real-Time Workshop Embedded Coder. |
The DAQ output is the output for any CCP Data Acquisition (DAQ) lists that have been set up. You can use the ASAP2 file generation feature of the Real-Time (RT) target to
Set up signals to be transmitted using CCP DAQ lists.
Assign signals in your model to a CCP event channel automatically (see Generating ASAP2 Files).
Once these signals are set up, event channels then periodically fire events that trigger the transmission of DAQ data to the host. When this occurs, CAN messages with the appropriate CCP/DAQ data appear on 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, and interpret the synchronous response.
Using DAQ lists for signal monitoring has the following advantages over the polling method:
There is no need for the host to poll for the data. Network traffic is halved.
The data is transmitted at the correct update rate for the signal. Therefore, there is no unnecessary network traffic generated.
Data is guaranteed to be consistent. The transmission takes place after the signals have been updated, so there is no risk of interruptions while sampling the signal.
Note Target Support Package TC2 software does not currently support event channel prescalers. |
The station address of the target. The station address is interpreted as a uint16. It is used to distinguish between different targets. By assigning unique station addresses to targets sharing the same CAN bus, it is possible for a single host to communicate with multiple targets.
Choose module eCAN_A or eCAN_B.
Specify the CAN message identifier for the Command Receive Object (CRO) message you want to process.
The incoming message type. Select either Standard(11-bit identifier) or Extended(29-bit identifier).
The message identifier is the CAN message ID used for Data Transmission Object (DTO) and Data Acquisition (DAQ) message outputs.
The message type to be transmitted by the DTO and DAQ outputs. Select either Standard(11-bit identifier) or Extended(29-bit identifier).
The default number of Object Descriptor Tables (ODTs) is 8. These ODTs are shared equally between all available DAQ lists. You can choose a value between 0 and 254, depending on how many signals you log simultaneously. You must make sure you allocate at least 1 ODT per DAQ list, or your build will fail. The calibration tool will give an error message if there are too few ODTs for the number of signals you specify for monitoring. Be aware that too many ODTs can make the sample time overrun. If you choose more than the maximum number of ODTs (254), the build will fail.
A single ODT uses 56 bytes of memory. Using all 254 ODTs would require over 14 KB 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, then this will create three DAQ lists and you must make sure you have at least three ODTs. ODTs are shared equally among DAQ lists and, therefore, you will end up with one ODT per DAQ list. With less than three ODTs, you get zero ODTs per DAQ list and the behavior is undefined.
Taking this example further, say you have three DAQ lists with one ODT each, and start trying to monitor signals in a calibration tool. If you try to assign too many signals to a particular DAQ list (that is, signals requiring more space than seven bytes (one ODT) in this case), then the calibration tool will report this as an error.
The sample time for CRO messages.
The following CCP commands are supported by the CAN Calibration Protocol block:
CONNECT
DISCONNECT
DNLOAD
DNLOAD_6
EXCHANGE_ID
GET_CCP_VERSION
GET_DAQ_SIZE
GET_S_STATUS
SET_DAQ_PTR
SET_MTA
SET_S_STATUS
SHORT_UP
START_STOP
START_STOP_ALL
TEST
UPLOAD
WRITE_DAQ
The above commands support
Synchronous signal monitoring via calibration packages that use DAQ lists
Asynchronous signal monitoring via calibration packages that poll the target
Asynchronous parameter tuning via CCP memory programming
This CCP implementation has been tested successfully with the Vector-Informatik CANape calibration package running in both DAQ list and polling mode, and with the Accurate Technologies, Inc., Vision, calibration package running in DAQ list mode. (Accurate Technologies, Inc., Vision does not support the polling mechanism for signal monitoring).
| C280x/C2833x ADC | C280x/C2833x eCAN Receive | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |