LCAP

         

LCAP Release status: experimental [box doku]
Description	Das Labor CAN Automation Protocol
Author(s)	Hansinator
Last Version	0 ()
Platform	AVR, PC
License	GPLv2+
Download	SVN, browse

CAN2.0B

The CAN2.0B standard is the wire protocol used by the LCAP protocol.

Frame Format

• 11 + 18 = 29 Bits identifier
• Remote Transmission Request flag
• 4 Bit Data Length Code
• 0..8 Byte data
• 15 Bits CRC
• ACK slot
• Frame types:
  • Data
  • Remote request
  • Error
  • Overload

Protocol Features

When a CRC error is detected, an error frame is generated by a receiving node 
and the frame is repeated. An ack is generated during the ack slot by at least one receiving node, whether it accepts or discards the message. Messages with lower-valued identifier fields (LSB first) have higher priority. Message collisions may be detected by a lower-priority transmitting node by measuring the bus during identifier transmission, As message identifiers must be unique per device (no two or more devices may send a frame having the same identifier), any collision must result in a different identifier measured by the lower-priority transmitter. In this case the lower-priority message is suppressed and transmission is automatically repeated after the higher-priority message is delivered. A device may send a remote request frame to request a frame with the given identifier.

CAN2.0B Frame Logical View

The following C struct describes the logical view of a CAN2.0B frame. If you're interested in the wire format, check out Wikipedia.

typedef struct
{
  uint32_t id;
  uint8_t dlc;
  uint8_t data[8];
} can_message;

The field "id" is assumed to have the following structure:

• Bit 28:18 -> 11 Bit CAN Standard Identifier
• Bit 17:00 -> 18 Bit CAN Extended Identifier
• (Bit intervals are inclusive)

The field "dlc" is assumed to have the following structure:

• Bit 4 -> Remote Transmission Request (RTR) flag
• Bit 3:0 -> CAN Data Length Code (DLC)

The field data contains 0 to 8 data bytes.

Note: The RTR flag is not present when using the current labor can mcp2515 driver!

LCAP

The LCAP attempts to improve upon the original LAP by simplifying adressing. There is a single subaddress data field instead of a separate source and target port. It provides additional header bits for an acknowledge, very basic long packet transmission, and possible future extensions such as crypto. The standard addressing mode supports virtual devices as target addresses, which may be used for multicast communication to implement a topic based messaging scheme, like netvar.

As the CAN bus is a cooperatively shared medium, no care is taken to prevent bus service disruption such as message flooding. In theory, any node could transmit any message(s) to overload the bus or otherwise disrupt communication.

Message Format (Draft)

• CAN2.0B Message ID Bit-Allocation (29Bit from left to right in [std-ident:ext-ident])
  • 8 Bit target address
  • 10 Bit subaddress
  • 8 Bit source device
  • 1 bit (R)ACK flag
  • 1 bit long packet start or sequence bit
    • DLC == 8 && set -> start long packet
    • DLC < 8 && long packet -> stop
    • DLC == 8 && long packet -> sequence bit (toggle)
  • 1 Bit reserved
• 4 Bit DLC (Data Length Code)
• 0..8 Bytes Data

The device source address satisfies the CAN requirement that each message identifier may only be sent by a single device. The DLC field is used in conjunction with the long packet flag to produce special meanings.

Protocol Description

(still to be revised)

• Adressing
  • Every device should have an unique address
  • Source address must be a real device
  • Target address may be a virtual multicast address for which there is no device address
  • 0xFF is the broadcast address
  • 0x00 is reserved as the system topic address
  • Sub-address allocation & usage is free and depends on each target implementation,
    except for the system topic
• Flags
  • If reserved bits are not zero, the message must be ignored
  • An ACK flag denotes
• Special request frames
  • requesting from normal devices
    • to devices -> ping request or ack
      • ping is answered with an ack data frame if
the requested sub-protocol is understood
      • if the rack bit is set, this is an ack packet
    • to topics -> request device to publish topic data
  • requesting from broadcast device address
    • to devices -> ignore
    • to topics -> any device may answer
      • may be useful as a sync for freshness counter stuff
  • request to system topic
    • request service, either from any master or a specific one, depending on the src address
    • if broadcast address is src address, all masters may try to answer, but must abort if they lost bus arbritation (higher priority system master overrides)
  • request to broadcast address
    • from normal device -> request ping
      • rack bit set -> request from all devices (all devices must answer)
      • rack bit not set -> any device may answer
    • from broadcast address -> ignore

LCAP Frame Logical View (draft)

The following C struct describes the logical view of an LCAP message.

typedef enum { dst_topic = 0x0, dst_device = 0x1, req_topic = 0x2, req_device = 0x3 }  lcap_type_t;

typedef struct {
  lcap_type_t dst_type;
  union { struct { uint8_t dst_addr, flags; }; uint16_t dst_topic; };
  uint8_t src_addr;
  uint8_t sub_addr;
  uint8_t len;
  uint8_t *data[];
} lcap_msg_t;

Explanations will follow soon! ;-)

Ideas

Configure can chip to use rec buffer 0 for device messages, having one filter set to device address and the other to broadcast use rec buffer 1 for topic messages, supporting pre-filtering of 4 topics or groups