LCAP: Unterschied zwischen den Versionen

Aus LaborWiki
Wechseln zu: Navigation, Suche
(added info box)
Zeile 17: Zeile 17:
* 4 Bit Data Length
* 4 Bit Data Length
* 15 Bits CRC
* 15 Bits CRC
** If CRC mismatches, an error frame is generated
(by which receiving node? all? id-matched ones?)
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
* Remote Transmission Request Flag

Version vom 5. November 2011, 15:45 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




CAN 2.0B Protocol Features

  • 11 + 18 = 29 Bits Identifier
  • 8 Byte Data
  • 4 Bit Data Length
  • 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)
  • Remote Transmission Request Flag
  • Frame types:
    • Data
    • Remote Request
    • Error
    • Overload

LCAP Basic Message Format (Draft)

  • 8 Bit Device or Topic Address
  • Message ID Allocation
    • 1 Bit DST Type (1 = Device, 0 = Topic)
    • 8 / 10(12?) Bit DST Device / 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
    • 2 Bit reserved for future use (encryption flags or stuff)
must be zero
    • 8 Bytes Data
  • 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

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