LCAP: Unterschied zwischen den Versionen

Aus LaborWiki
Wechseln zu: Navigation, Suche
(temp)
(can features we'll use)
Zeile 15: Zeile 15:
The [http://en.wikipedia.org/wiki/Controller_area_network CAN2.0B standard] is the wire protocol used by the LCAP protocol.
The [http://en.wikipedia.org/wiki/Controller_area_network CAN2.0B standard] is the wire protocol used by the LCAP protocol.


=== CAN 2.0B Frame Features===
=== Frame Format ===
* 11 + 18 = 29 Bits identifier
* 11 + 18 = 29 Bits identifier
* Remote Transmission Request flag
* Remote Transmission Request flag
* 4 Bit Data Length Code
* 4 Bit Data Length Code
* 0..8 Byte Data
* 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
* ACK slot
* ACK Slot (any receiver may ack, though)
* Frame types:
* Frame types:
** Data
** Data
** Remote Request
** Remote request
** Error
** Error
** Overload
** 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 ===
=== CAN2.0B Frame Logical View ===

Version vom 16. Oktober 2012, 23:53 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.

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.

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