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.

CAN 2.0B Frame Features

• 11 + 18 = 29 Bits identifier
• Remote Transmission Request flag
• 4 Bit Data Length Code
• 0..8 Byte Data
• 15 Bits CRC
  • If CRC mismatches, an error frame is generated
 by a receiving node 
and the frame is repeated
• ACK Slot (any receiver may ack, though)
• Frame types:
  • Data
  • Remote Request
  • Error
  • Overload

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.

netvar

LCAP Basic 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

LCAP Basic Message Semantics (Draft)

• if reserved bits are not zero, the message must be ignored
• 0xFF is the broadcast address
• request messages
  • 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