LCAP: Unterschied zwischen den Versionen
Aus LaborWiki
(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
| ** 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 | 0 () |
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
- to devices -> ping request or ack
- 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
- from normal device -> request ping
- requesting from normal devices
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