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 and CAN FD (ISO 16845), 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, enable the use of CAN FD, 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
• Enable use of CAN FD
• CAN FD Maximum payload length to support

There must be one CAN definition block for each CAN bus used in the applicaiton. To enable MotoTune protocol on a CAN Channel, use the MotoTune CAN Definition Block. It is usually 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 (Up to 8 bytes in Classic CAN, up to 64 bytes in CAN FD)
• 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.  

Examples for the message definition format can be found in motohawk_can_example.m and motohawk_can_fd_example.m.

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

use_fd - enable use of CAN FD features

use_brs - enable use of the CAN FD Fast Data Baudrate

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, or 0 to 64 when use_fd was true.

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)

Bit Notation
Bit notation is as follows, regardless of the actual length of the message payload. This notation somewhat favors BIG_ENDIAN-format fields, but LITTLE_ENDIAN fields may be represented without any problem. The rule is, always set the start_bit to the LSB of the FIELD. Using this notation, the LSB of a LITTLE_ENDIAN field will appear to be in the 'middle' of the field.

Here is the bit ordering for Classic CAN messages:

Here is the bit ordering for CAN FD messages:

Note that a CAN FD message configured to send 8 bytes will be sending bytes B0 to B7 at bit offset numbers 448 to 511. This is different from a Classic CAN message sending the same 8 bytes which are B0 to B7, but with bit offset numbers of 0 to 64.

Because of this a constant conversion can be made from Classic CAN to CAN FD positions by adding a constant value of 448.

Compatibility with Simulink CAN Pack/Unpack

Since MATLAB R2017b, the Simulink blocks to Pack and Unpack CAN messages are compatible for use with MotoHawk. The Simulink Pack and Unpack blocks work directly with Vector CAN Db files. In version R2017b, Mathworks have added an option to output the CAN Message fields as a signal bus. This is enabled by the option "Output as bus." If this option is checked, the output of the CAN Pack block can be connected to the input of the MotoHawk CAN Send RAW block through the use of a bus selector.

More information about the Simulink Pack block can be found here:

http://www.mathworks.com/help/xpc/io_ref/canpack.html

CAN Info Get

This block allows the application to gain knowledge about how the CAN Bus is behaving. This block can be used to answer questions such as "Is the bus active?" and "Is the application overrunning the transmit queue?".

CAN INFO GET