Crate flipdot_core

source ·
Expand description

Core types for describing communication with Luminator flip-dot and LED signs.

For the basic task of sign communication, you likely want to use the high-level API in the flipdot crate instead.

However, flipdot_core is useful for crates that want to interact with the sign protocol at a lower level than the flipdot crate, or who want to provide their own SignBus implementations for use by flipdot.

Tested with a MAX3000 90 × 7 side sign. Should work with any flip-dot or LED sign that uses the 7-pin circular connector, but no guarantees.

Intended only for hobbyist and educational purposes. Not affiliated with Luminator in any way.

§Examples

use flipdot_core::{Address, Message, Operation, PageFlipStyle, SignBus, SignType, State};

// Assume we have a helper function to obtain a SignBus.
let mut bus: Box<dyn SignBus> = get_bus();

// Discover the sign and verify that is has not yet been configured.
let message = Message::Hello(Address(3));
let response = bus.process_message(message)?;
assert_eq!(Some(Message::ReportState(Address(3), State::Unconfigured)), response);

// Request that the sign receive the configuration data and verify that it acknowledges.
let message = Message::RequestOperation(Address(3), Operation::ReceiveConfig);
let response = bus.process_message(message)?;
assert_eq!(Some(Message::AckOperation(Address(3), Operation::ReceiveConfig)), response);

Structs§

Enums§

  • Errors related to reading/writing Frames of data.
  • High-level representation of a sign bus communication message.
  • Operations that can be requested of a sign, which trigger actions and/or state changes.
  • Errors relating to Pages.
  • Whether the sign or controller (ODK) is in charge of flipping pages.
  • The configuration information for a particular model of sign.
  • Errors related to SignTypes.
  • Possible states that a sign can be in during operation.

Traits§

  • Abstraction over a bus containing devices that are able to send and receive Messages.