LCAP: Unterschied zwischen den Versionen

Aus LaborWiki
Wechseln zu: Navigation, Suche
(documentation!)
Zeile 12: Zeile 12:
}}
}}


== CAN 2.0B Protocol Features==
== CAN2.0B ==
* 11 + 18 = 29 Bits Identifier
The [http://en.wikipedia.org/wiki/Controller_area_network CAN2.0B standard] is the wire protocol used by the LCAP protocol.
* 8 Byte Data
 
* 4 Bit Data Length
=== 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
* 15 Bits CRC
** If CRC mismatches, an error frame is generated
 by a receiving node 
and the frame is repeated
** If CRC mismatches, an error frame is generated
 by a receiving node 
and the frame is repeated
* ACK Slot (any receiver may ack, though)
* ACK Slot (any receiver may ack, though)
* Remote Transmission Request Flag
* Frame types:
* Frame types:
** Data
** Data
Zeile 26: Zeile 29:
** Overload
** Overload


== LCAP Basic Message Format (Draft) ==
=== CAN2.0B Frame Logical View ===
 
The following C struct describes the logical view of a CAN2.0B frame.
 
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 ==
 
=== LCAP Basic Message Format (Draft) ===
* 8 Bit Device or 10/12 bit Topic Address
* 8 Bit Device or 10/12 bit Topic Address
* CAN2.0B Message ID Bit-Allocation (from left to right in [std-ident:ext-ident])
* CAN2.0B Message ID Bit-Allocation (from left to right in [std-ident:ext-ident])
Zeile 43: Zeile 73:
** Implicit 0..8 Bytes Data
** Implicit 0..8 Bytes Data


== LCAP Basic Message Semantics (Draft) ==
=== LCAP Basic Message Semantics (Draft) ===
* if reserved bits are not zero, the message must be ignored
* if reserved bits are not zero, the message must be ignored
* 0x(3)FF is the broadcast address
* 0x(3)FF is the broadcast address
Zeile 66: Zeile 96:
**** rack bit not set -> any device may answer
**** rack bit not set -> any device may answer
*** from broadcast address -> ignore
*** 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 ==
== 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
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

Version vom 6. November 2011, 01:30 Uhr

         
LCAP

Release status: experimental [box doku]

Description Das Labor CAN Automation Protocol
Author(s)  Hansinator
Last Version  ()
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.

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

LCAP Basic Message Format (Draft)

  • 8 Bit Device or 10/12 bit Topic Address
  • CAN2.0B Message ID Bit-Allocation (from left to right in [std-ident:ext-ident])
    • 1 Bit DST Type (1 = Device, 0 = Topic)
    • 8 Bit DST Device or 10/12 Bit Topic
    • in case of device + 2 Bits:
      • 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)
    • 8 Bit SRC Device
    • 8 Bit sub-protocol (if topic addressing is 12 Bit this is 6 Bit in topic mode then)
    • 2 Bit reserved for future use (encryption flags or stuff)
must be zero
    • Implicit 4 Bit DLC
    • Implicit 0..8 Bytes Data

LCAP Basic Message Semantics (Draft)

  • if reserved bits are not zero, the message must be ignored
  • 0x(3)FF is the broadcast address
    • for devices this addresses all devices
    • for topics, this is the system topic
  • 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