Crates.io | flipdot-core |
lib.rs | flipdot-core |
version | 0.7.1 |
source | src |
created_at | 2021-03-03 02:41:56.069759 |
updated_at | 2024-03-04 03:07:34.109164 |
description | Core types for describing communication with Luminator flip-dot and LED signs |
homepage | |
repository | https://github.com/alusch/flipdot |
max_upload_size | |
id | 362951 |
size | 99,953 |
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.
Here's an example of directly interacting with a SignBus
at the Message
level instead of using Sign
:
use flipdot_core::{Address, Message, Operation, 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);
Distributed under the MIT license.