My favorites | Sign in
Project Home Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
CanCommunicationProtocol  
This page describes the CAN Communication Protocol.
thaNodeSoftware, thaConfigurator
Updated Apr 17, 2011 by Tien1...@gmail.com

CAN Communication Protocol

1. Introduction

The cable based communication is using CAN with following configuration:

  • Extended frame format with 29 identifier bits
  • Baudrate 125 kbit/s

To make the communication easy and efficient a CAN Communication Protocol is defined. The 29 bit identifier contains some communication data, like MessageType, SenderNodeId or ReceiverNodeId. The following chapters describe the protocol parts.

2. Protocol content of 29 bit CAN ID

The following table shows the structure of 29 bit CAN ID.

3. Protocol content of 8 CAN data bytes

The following table shows the structure of CAN data bytes.

4. Parts of CAN Communication Protocol

4.1. MessageType

  • Description: The MessageType describe the kind of content of the message.
  • Bit length: 3 address bits (8 different MessageTypes)
  • Bit position: 28-26
  • Coding:
    000b = Event,
    001b = StartRoutine,
    010b = WriteData,
    011b = ReadData,
    100b = RoutineResult,
    100b = DataResponse,
    101b = Log,
    111b = TransferData

4.1.1. MessageType: Event

This MessageType is used to send an Event. Events are the most used messages. For each event like an PushButton or an update of an temperature value an Event is sent. Normaly the BroadcastMessage (ReceiverNodeID = 0) is used for Events. The ID of the Event is defined by the !EventID in the first two CAN data bytes. This MessageType has the highest priority.

4.1.2. MessageType: StartRoutine

This MessageType is used to start a routine. If the request is send with a PeerToPeerMessage only the ReceiverNode start the routine and send a response by using the MessageType RoutineResult to the SenderNode. If sending with a BroadcastMessage all nodes start the routine an send the response.

4.1.3. MessageType: WriteData

This MessageType is used to write data into nodes. If the request is send with a PeerToPeerMessage the data will be written only into the ReceiverNode. If sending with a BroadcastMessage the data can be written to all nodes at one time. After written the data the ReceiverNodes send a response.

4.1.4. MessageType: ReadData

This MessageType is used to read data from nodes. If the request is send with a PeerToPeerMessage only the ReceiverNode send a response to the SenderNode. If sending with a BroadcastMessage all nodes send a response.

4.1.5. MessageType: RoutineResult

This MessageType is used as the answer of a StartRoutine request. It is only used with PeerToPeerMessages back to the node which starts the routine.

4.1.6. MessageType: DataResponse

This MessageType is used as the answer of WriteData or ReadData request. It is only used with PeerToPeerMessages back to the node which start the writing or reading data.

4.1.7. MessageType: Log

This MessageType is used to send a Log information. This can be a Error Message or some other stuff for logging, it can be also a alive message or the temperature of the Node. The receiver is normaly a central node which trace all the log messages to a mass storage like an SD card.

4.1.8. MessageType: TransferData

This MessageType is used to transfer huge amount of payload. This is needed by example for reprogramming. To initiate the transfer data it is needed to send a StartRoutine message befor sending the TransferData message. For more information look the TransferData Wiki page. For this MessageType all the CAN data bytes can be used for the application, no ContentID is needed. This MessageType has the lowest priority.

4.2. SenderNodeID

  • Description: Unique ID of Sender Node. The wide range allows clusters e.g. to seperate floors and rooms. But this is not defined by this protocol it must be defined by application.
  • Bit length: 13 address bits (max. 8191 Nodes)
  • Bit position: 13-25
  • Coding:
    0d = WakeUp
    1d - 8191d = project dependent (Note: use low IDs for important nodes)

4.3. ReceiverNodeID

  • Description: Unique ID of Receiver Node or the marker for an Broadcast Message.
  • Bit length: 13 address bits (max. 1024 Nodes)
  • Bit position: 0-12
  • Coding:
    0d = BroadcastMessage
    1d - 8191d = PeerToPeerMessage. NodeID is project dependent (Note: use low IDs for important nodes)

If the ReceiverNodeID is 0 then message is marked as an BroadcastMessage. BroadcastMessages are used for the normal communication like PressButtonEvents. Furthermore the BroadcastMessages are used to reprogramming more than one nodes at the same time by using the TransferData MessageType.

If the ReceiverNodeID holds an NodeID the Message is an PeerToPeerMessage. PeerToPeerMessages are used for Point-To-Point connections. For example for Diagnosis or Reprogramming only one node. PeerToPeerMessages also used for normal communication if a message must be send only from one node to an other.

4.4. ContentID

Regarding the MessageType the first two bytes of CAN data are used to describe the content of the message. Following the different !ContentIDs will be describe:

4.4.1 EventID

  • Description: The !EventID describes which data should be sent by an Event.
  • Byte length: 2 CAN data bytes (max. 0xFFFF EventIDs)
  • Byte position: 0-1
  • Coding:
    0x0000 - 0xFFFF = tbd, see Wiki EventIDs pages

4.4.2 !DataID

  • Description: The !DataID describes which data should be read or write. The RecordID 0xFFFF is reserved as an flag for a NegativeResponse.
  • Byte length: 2 CAN data bytes (max. 0xFFFE DataIDs)
  • Byte position: 0-1
  • Coding:
    0x0000 - 0xFFFE = tbd, see Wiki DataIDs pages

4.4.3 !RoutineID

  • Description: The !RoutineID describes which routine should be start. The RecordID 0xFFFF is reserved as an flag for a NegativeResponse.
  • Byte length: 2 CAN data bytes (max. 0xFFFE RoutineIDs)
  • Byte position: 0-1
  • Coding:
    0x0000 - 0xFFFE = tbd, see Wiki RoutineIDs pages

4.4.4 !LogID

  • Description: The !LogID describes which data should be send by an Log.
  • Byte length: 2 CAN data bytes (max. 0xFFFF LogIDs)
  • Byte position: 0-1
  • Coding:
    0x0000 - 0xFFFE = tbd, see Wiki LogIDs pages

4.6. Payload

4.5.1. Payload for TransferData

Content:

D0..7
Payload

Description:

  • Payload is the service specific data.

4.5.3. Payload for MessageType Event / Log

Content:

D0..1 D2..7
EventID Payload

Description:

  • EventID is the ID of the Event according to EventIDs
  • Payload is the service specific data - see the service specification for details

Hier gehts weiter...

4.5.2. Payload for Request of WriteData / ReadData

Content:

D0..1 D2..7
RecordID Payload

Description:

  • RecordID is the ID of the request according to RecordIDs
  • Payload is the service specific data - see the service specification for details

4.5.4. Payload for Response of ReadData / WriteData / StartRoutine

Content for positive response:

D0..1 D2..7
RecordID Payload

Description:

  • RecordID is the reflected RecordID of the request.
  • Payload is the service specific response data - see the service specification for details

Content for negative response:

D0..1 D2..3 D4 D5..D7
0xFFFF NegativeResponseFlag RecordID ErrorStatus Not used or internal debug data for development.

Description:

  • NegativeResponseFlag is the flag to sign an error at processing Read / WriteData or at processing a Routine.
  • RecordID is the reflected RecordID of the request.
  • NegativeResponseCode is a code to give a hint to the reason of error - see the service specification for details

Powered by Google Project Hosting