| Target Support Package™ FM5 | |
Target Support Package FM5/ MPC555 Driver Library/ CAN 2.0B Controller Module
The CAN Calibration Protocol (MPC555) 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 Command Receive Object (CRO) messages 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) Web site at http://www.asam.de.
You can see an example illustrating how to use the CAN Calibration Protocol (MPC555) block in the mpc555rt_ccp demo.
Note this block is entirely CAN triggered, and so is only designed for the Real-Time Target (CAN is disabled during PIL and SIL cosimulation.)
Note The CCP Data Acquisition (DAQ) List mode of operation is only supported with the Real-Time Workshop® Embedded Coder™ product. If this 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 software. |
The DAQ output is the output for any CCP DAQ lists that have been set up. You can use the ASAP2 file generation feature of the 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 Parameter Tuning and Signal Logging).
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.
It is the responsibility of the calibration tool (see Compatibility with Calibration Packages) to use CCP commands to assign an event channel and data to the available DAQ lists, and to 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 The Target Support Package™ FM5 product 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 A or B.
Specify the CAN message identifier for the incoming 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. It is also used for transmitting messages to the host during the software-induced CAN download (soft boot). See Extended Functionality.
The message type to be transmitted by the DTO and DAQ outputs. Select either Standard(11-bit identifier) or Extended(29-bit identifier).
Leave this check box selected to automatically set the FIFO queue length equal to the number of Object Descriptor Tables (ODTs) (recommended). Clear the check box to set the length of the FIFO queue manually.
Specify the FIFO queue length manually. This is enabled if you clear the check box to set the queue length automatically.
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 want to 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.
For more information on DAQ lists, see Data Acquisition (DAQ) List Configuration.
Sample time at which to check for incoming Command Receive Object (CRO) messages.
The following CCP commands are supported by the CAN Calibration Protocol (MPC555) 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. (Note that Accurate Technologies Inc. Vision does not support the polling mechanism for signal monitoring.)
The CAN Calibration Protocol (MPC555) block also supports the PROGRAM_PREPARE command. This command is an extension of CCP that allows the automatic download of new code into the target memory. This removes the requirement for a manual reset of the processor. On receipt of the PROGRAM_PREPARE command, the target will reboot and begin the CAN download process. This lets you download new application code to RAM or flash memory, or download new boot code to flash memory. See Downloading Boot or Application Code via CAN Without Manual CPU Reset.
Note The CAN message identifiers of the CCP messages incoming to the target (Command Receive Object (CRO) messages) and the messages outgoing from the target (Data Transmission Object (DTO) or DAQ) are specified in the block mask for the CAN Calibration Protocol (MPC555) block. These message identifiers are used as the CAN identifiers for the download process after a PROGRAM_PREPARE reboot. The type of CAN message used for this PROGRAM_PREPARE download process is always Extended (29-bit identifier). |
| Asynchronous Rate Transition | MIOS Digital In | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |