NAME

Device::Serial::MSLuRM - communicate Multi-drop SLµRM over a serial port

SYNOPSIS

use v5.36;
use Device::Serial::MSLuRM;

my $slurm = Device::Serial::MSLuRM->new(
   dev  => "/dev/ttyUSB0",
   baud => 19200,
);

$slurm->run(
   on_notify => sub ($node_id, $payload) {
      printf "NOTIFY(%d): %v02X\n", $node_id, $payload;
   }
)->await;

DESCRIPTION

This variant of 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.

METHODS

run

$run_f = $slurm->run( %args );

Starts the receiver run-loop, which can be used to wait for incoming NOTIFY packets. This method returns a future, but the returned future will not complete in normal circumstances. It will remain pending while the run-loop is running. If an unrecoverable error happens (such as an IO error on the underlying serial port device) then this future will fail.

Takes the following named arguments:

on_notify => CODE
$on_notify->( $node_id, $payload )

Optional. Invoked on receipt of a NOTIFY packet.

Note that unlike in the single-peer case, a multi-drop controller cannot reset all the nodes before starting this, as it does not know the full set of nodes that need resetting.

recv_packet

( $pktctrl, $addr, $payload ) = await $slurm->recv_packet;

Waits for and returns the next packet to be received from the serial port. Note that in a multi-drop scenario this packet may well be a reflection of one sent by the controller, depending on how the serial port adapter works.

send_packet

await $slurm->send_packet( $pktctrl, $addr, $payload );

Sends a packet to the serial port.

send_notify

await $slurm->send_notify( $node_id, $payload );

Sends a NOTIFY packet.

Will automatically "reset" first if required.

request

$data_in = await $slurm->request( $node_id, $data_out );

Sends a REQUEST packet to the node, and waits for a response to it.

If the peer responds with an ERR packet, the returned future will fail with an error message, the category of slurm, and the payload body of the ERR packet in the message details:

$f->fail( $message, slurm => $payload );

If the peer does not respond at all and all retransmit attempts end in a timeout, the returned future will fail the same way but with undef as the message details:

$f->fail( $message, slurm => undef );

Will automatically "reset" first if required.

AUTHOR

Paul Evans <leonerd@leonerd.org.uk>