LCAP: Unterschied zwischen den Versionen

Aus LaborWiki
Wechseln zu: Navigation, Suche
(new protocol header)
(temp)
Zeile 54: Zeile 54:
  
 
== LCAP ==
 
== 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.
 +
 +
[http://www.das-labor.org/trac/browser/microcontroller/src-atmel/automatization2.0/lib/netvar/ netvar]
  
 
=== LCAP Basic Message Format (Draft) ===
 
=== LCAP Basic Message Format (Draft) ===
* 8 Bit Target Address
 
** There may be virtual topic devices
 
 
* CAN2.0B Message ID Bit-Allocation (29Bit from left to right in [std-ident:ext-ident])
 
* CAN2.0B Message ID Bit-Allocation (29Bit from left to right in [std-ident:ext-ident])
 
** 8 Bit target address
 
** 8 Bit target address
** 8 Bit subtype
+
** 10 Bit subaddress
 
** 8 Bit source device
 
** 8 Bit source device
 
** 1 bit (R)ACK flag
 
** 1 bit (R)ACK flag
Zeile 67: Zeile 69:
 
*** DLC < 8 && long packet -> stop
 
*** DLC < 8 && long packet -> stop
 
*** DLC == 8 && long packet -> sequence bit (toggle)
 
*** DLC == 8 && long packet -> sequence bit (toggle)
** 1 Bit cryptoflag
+
** 1 Bit reserved
** 2 Bit unallocated
 
 
* 4 Bit DLC (Data Length Code)
 
* 4 Bit DLC (Data Length Code)
 
* 0..8 Bytes Data
 
* 0..8 Bytes Data
Zeile 74: Zeile 75:
 
=== 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
+
* 0xFF is the broadcast address
** for devices this addresses all devices
 
** for topics, this is the system topic
 
 
* request messages
 
* request messages
 
** requesting from normal devices
 
** requesting from normal devices
Zeile 112: Zeile 111:
  
 
Explanations will follow soon! ;-)
 
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 16. Oktober 2012, 23:17 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. 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