MotoHawk:CAN Overview

CAN Overview

CAN= Controller Area Network.

MotoHawk doesn't define a protocol, but provides a set of blocks to access the CAN hardware of the module to implement a protocol.

MotoHawk CAN blocks support CAN 2.0B messages, with both standard (11 bit) and extended (29 bit) IDs.

CAN Definition Block

First the Bus must be Initialized for Use.

The CAN DEFINITION BLOCK is used to initialize the CAN hardware, set the baud rate, and configure the transmit queue size.   

Key parameters that can be set on the block include:

• Bus name
• Resource (Hardware Channel)
• Bit Timing - User can select a preset baud rate, or 'Custom' to set Prescalar, Propagation Segment, and RJW
• Transmit Queue Size
• Install MotoTune Protocol Checkbox - User selects whether to initialize MotoTune protocol on this CAN bus. If 'None' is selected for all Buses, the module cannot communicate with MotoTune, or be Reflashed via MotoTune. A bootkey would be needed to recover the module
• City ID - this is the "address" used by MotoServer port to communicate with the module

There must be one CAN definition block for each CAN bus used in the applicaiton. It is only needed to enable MotoTune protocol on one CAN channel. Most modules can program on any CAN bus, the ECM-565-128 can only program on CAN-1.

CAN Raw Blocks

 The Read CAN Raw Block and the Send CAN Raw Block can be used to recieve or send a CAN message without unpacking the content. 

In these blocks, the user would configure what raw message content is recieved or sent by the block. The messages can be filtered by address or message content.

Some terminology:

• ID: The address of the message
• Payload: The message content
• Masks: Which parts of the message to care about, or which to ignore

The ID and Payload use a 'MASK' to tell the MotoHawk model which parts of the ID or payload to care about, and which parts to ignore when filtering a message. The Mask can be defined in the CAN Send or CAN Recieve block mask, or left as the default.

As an example of filtering, lets say the user defines the message ID and ID Mask as follows and does not define any filtering based on payload:

CAN Recive Slot Properties and CAN Recive Slot Trigger

 The CAN Recieve Slot Properties Block can be used to set the filtering of the recieved message at runtime.  The CAN Slot Trigger Block is used to function call a subystem when a CAN message is recieved in the slot. 

The CAN message can be associated with a particular 'SLOT'. The Slot is defined by the MotoHawk CAN Recieve Slot Properties Block.

The CAN Recieve Block and its Slot Properties BLock are linked by SLOT NAME.

The filters set in the CAN Read and Send blocks can be made more restrictive by the use of a slot, but not less restricive.

A CAN Slot Trigger Block can also be used to function call a subystem when its CAN message is recieved. The SLOT name in this block must match the name specifid in the corresponding CAN Read block.

CAN Read and CAN Send Blocks

The CAN Read and Send Raw blocks are nice, but often more advanced data parsing is required. The MotoHawk CAN SEND and MotoHawk CAN READ blocks allow the user to set up more complex message struture using an .m file for the message definition.

CAN SEND

CAN READ

In the .m file, the user defines:

Message Name and Description

Name - Message Name Displayed on the block

Description - brief text used to document the message

Protocol - name of the protocol used

module - name of the source module

bus_name - name of the source CAN channel

CAN ID setup

ID - the message ID

IDEXT - either 'STANDARD' (11-bit) or 'EXTENDED' (29-bit)

IDMASK - indicates which bits of the ID are used for a recieve slot, and which are ignored (see above) default: (0xffffffff)

IDContent - can be used to set bit fields within message ID (optional, ex. source address of J1939 message can be added to the content of the ID

Transmit interval, message size, and contents

Interval - period in milliseconds, or -1 if sent asynchronously (default: -1)

Payload Size - size of the message from 0 to 8 bytes.

transmit: exact number of bytes to send.

receive: minimum number of bytes required.

Payload_value - Just as an ID has a value and mask, so can the payload.

For receives, this will result in a software filter that requires the bits set in the payload mask to be equal to those in the payload value.

For transmits, any bits set in the payload mask will be hard-coded to be the corresponding bits of the payload value.

Payload Mask - indicates which bits of the payload are relevant for a receive slot, or which bits will be hardcoded for transmits.

Payload (message) Contents

Name - message name displayed on the block

Units - units (of Simulink-model value) used in mask display

Start Bit - indicates the least-significant bit of the field, regardless of endian-ness

Bit Length - number of bits in the field

Byte Order - may be 'BIG_ENDIAN' or 'LITTLE_ENDIAN'.

Data Type - may be 'UNSIGNED', 'SIGNED', 'FLOAT32', or 'FLOAT64' (default: 'UNSIGNED')

Scale - scale factor.

- Since the same message description sructure is used for both transmits and receives, the scale factor should not be thought of as a gain. Instead, think of it as the units of the signal

Offset - offset applied to the field, in engineering units.

Minimum - minimum signal value. If the signal value on transmit is less than this value, the minimum value is sent instead.

Maximum - maximum signal value. If the signal value on transmit is greater than this value, the maximum value is sent instead.

Equation: (CAN_msg_field_value) * scale + offset = (Simulink_model_value)