can_utils/
interface.rs

1//! The `interface` module holds various types for modeling parts of a CAN interface.
2
3/// The intended behavior of a CAN filter.
4pub enum MessageFilterType {
5  /// Signifies a filter that includes traffic it matches.
6  MatchMeansAccept,
7  /// Signifies a filter that excludes traffic it matches.
8  MatchMeansIgnore,
9}
10
11/// A filter that the hardware might apply to incomming traffic.
12pub struct MessageFilter {
13  /// The CAN id (or common subset of a CAN idea if a mask is specified) to filter or select.
14  pub id: u32,
15  /// Incomming CAN ids are masked with this mask (if present) before being compared against id.
16  pub mask: Option<u32>,
17  /// The intent of this filter, is it a "forward if" or a "forward unless"?
18  pub filter_type: MessageFilterType,
19}
20
21/// The 3 fault confinement states as described in the CAN 2.0 spec.
22pub enum FaultConfinementState {
23  /// Errors are so few that this interface tells the whole bus when they happen.
24  ErrorActive,
25  /// Errors are numerous enough that informing the bus of them isn't allowed, but regular Rx
26  /// and Tx can still work.
27  ErrorPassive,
28  /// There are so many bus errors that we're effectively not connected, Rx and Tx are disabled.
29  BusOff,
30}
31
32/// Operation Modes describe what the interface is currently doing.
33pub enum InterfaceOperationMode {
34  /// The interface is currently receiving a message from the bus.
35  Receiver,
36  /// The interface is currently transmitting a message from the bus.
37  Transmitter,
38  /// The interface is waiting to sync with the bus (detect 11 consecutive recessive bits).
39  ///
40  /// NOTE: this state was never described in the CAN 2.0 spec, only the CAN FD spec, so
41  /// documentation not written with CAN FD in mind may not talk about how to detect it.
42  /// That said, it is applicable to regular CAN hardware, they have this state for the same
43  /// reason CAN-FD does, so people implementing `CanInterface` for non-FD hardware may have
44  /// to do some thinking.
45  Integrating,
46  /// The interface ready and waiting to either transmit or receive.
47  ///
48  /// NOTE: this state was never described in the CAN 2.0 spec, only the CAN FD spec, so
49  /// documentation not written with CAN FD in mind may not talk about how to detect it.
50  /// That said, it is applicable to regular CAN hardware, they have this state for the same
51  /// reason CAN-FD does, so people implementing `CanInterface` for non-FD hardware may have
52  /// to do some thinking.
53  Idle,
54}
55
can_utils/interface.rs

can_utils/
interface.rs
