Trait Drivable

pub trait Drivable: Sized {
    const CLASS: Class;
    const HAS_READ: bool = false;
    const HAS_WRITE: bool = false;

    // Provided methods
    fn read(self) -> Result<Phydat, Error> { ... }
    fn write(self, _data: &Phydat) -> Result<u8, Error> { ... }
}

Available on riot_module_saul only.

API through which SAUL operations are done

This is typically implemented on a &T (where T is what the Driver and Registration is for), but can be alternatively implemented on a newtype around such pointers to drive various aspects of a device.

Required Associated Constants

const CLASS: Class

Sensor class (type)

Provided Associated Constants

const HAS_READ: bool = false

Set to true if read is implemented.

Doing this on the type level (rather than having read and write return a more differentiated error) allows the driver to point to the shared riot_sys::saul_read_notsup / riot_sys::saul_write_notsup handler rather than to monomorphize a custom erring handler for each device.

const HAS_WRITE: bool = false

Set to true if write is implemented.

Provided Methods

fn read(self) -> Result<Phydat, Error>

Read the current state

fn write(self, _data: &Phydat) -> Result<u8, Error>

Set the state of an actuator, or reconfigure a sensor

A &self is passed in on write because there could be concurrent access from multiple SAUL users. One option of handling this is to implement Drivable for Mutex<T>.

Note that due to the way SAUL is structured, the drivable can not know the number of entries which the user intended to set. The Drivable trait always builds the Rust Phydat (which contains a length) with the maximum available length (some of which may contain uninitialized data, which is OK as i16 has no uninhabited values), and the writer needs to return how many of the entries it actually used.

Dyn Compatibility

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.

Implementors