view release on metacpan or  search on metacpan

doc/protocol.md  view on Meta::CPAN

7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
A NOTIFY message is a simple notification from one peer to the other, that does not yield a response.
 
A REQUEST message carries typically some sort of command instruction, to which the peer should respond with a RESPONSE or ERR packet. Replies to a REQUEST message do not have to be sent sequentially.
 
Topology
--------
 
There are two variants of the protocol, for different topology situations, which use different header formats.
 
* 3-byte header: Used between exactly two endpoints connected by a full-duplex asynchronous serial connection, such as RS-232 or TTL UART. In this situation, node IDs are not needed as a message transmitted by either node will only be received by the...
 
* 4-byte header: Used on an entire bus of two or more endpoints connected by a shared half-duplex asynchronous serial connection, such as RS-485. One endpoint is distinguished as being special; the "controller". This is typically a computer (or at le...
 
Packets
-------
 
Packets are variable-length over async serial at an application-defined baud rate. 8 bits are required. Parity checking is not required as higher-level checksumming is employed by the protocol.
 
Each packet consists of a SYNC byte (0x55), followed by a 3- or 4-byte header, a variable-length application data payload, and a final checksum byte.
 
The 3-byte header is used in full-duplex 2-node situations, and consists of a packet-control field, a length field, and a CRC which protects the header itself:

doc/protocol.md  view on Meta::CPAN

52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
A packet with PKTCTRL=0x12 and three body bytes ("ABC"):
 
```
  0x55 0x12 0x03 0x74 0x41 0x42 0x43 0x52
```
 
The PKTCTRL field itself is broken into two 4-bit sub-fields; the packet type occupies the upper 4 bits, the sequence number the lower 4. The above packet has packet type 0x10, sequence number 2, and the body bytes "ABC".
 
The ADDR field is broken into a single bit indicating direction, and a 7-bit field containing the node ID. The topmost bit of the ADDR field is 1 for messages transmitted by the controller to a node, and 0 for messages transmitted by nodes to the con...
 
The ADDR field gives a simple way for endpoints to filter received packets for interest; as on a shared bus system such as RS-485 each node will receive messages destined for others, and may also receive reflections of its own transmissions. The cont...
 
On a multi-drop system, after packets are filtered, the remaining packet semantics work the same as for the direct two-endopoint case described below. Some applications may wish to reserve a node ID number for broadcast purposes; typically zero or al...
 
Messages
--------
 
The packet type field indicates the type of message being conveyed. Regular messages use a non-zero packet type. In this case, the sequence number field contains an integer that is incremented for each new message. Transmitters may wish to transmit p...
 
When implementing the controller of a multi-drop system, remember that sequence numbers apply per node ID and each must be handled independently. Additionally, if nodes are expected to receive broadcast messages, they will have their own sequence num...

lib/Device/Serial/MSLuRM.pm  view on Meta::CPAN

36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
         printf "NOTIFY(%d): %v02X\n", $node_id, $payload;
      }
   )->await;
 
=head1 DESCRIPTION
 
This variant of L<Device::Serial::SLuRM> allows communication with a
collection of nodes using Multi-drop SLµRM over a serial port, such as over
an RS-485 bus.
 
The endpoint running with this module takes the role of the bus controller.
Currently this module does not support being a non-controller node.
 
=cut
 
use constant is_multidrop => 1;
 
=head1 METHODS
 
=head2 run