The CAN ExtendId implementation provides the standard_id() method:
impl ExtendedId {
...
/// Returns the Base ID part of this extended identifier.
pub fn standard_id(&self) -> StandardId {
// ID-28 to ID-18
StandardId((self.0 >> 18) as u16)
}
}
However, contrary to what its misleading name suggests, and despite the fact that it returns a StandardId, this method is not about creating a StandardId from an ExtendedId (converting an ExtendedId into a StandardId): as its documentation rightfully states, it's about extracting its Base ID.
Therefore, standard_id() should really be named base_id().
Additionally, the included comment is wrong (there are no such things as a CAN ID-28 and ID-18).
Lastly, as we have at our disposal the following const method (i.e. zero run-time overhead):
/// Returns this CAN Identifier as a raw 32-bit integer.
pub const fn as_raw(&self) -> u32 {
self.0
}
We should use it to make base_id() implementation-agnostic (rather than relying on self.0).
Altogether, it should look like this:
/// Returns the Base ID part of this extended identifier.
pub fn base_id(&self) -> StandardId {
// Extract the 11 most significant bits from this 29-bit identifier
StandardId((self.as_raw() >> 18) as u16)
}
The CAN
ExtendIdimplementation provides thestandard_id()method:However, contrary to what its misleading name suggests, and despite the fact that it returns a
StandardId, this method is not about creating aStandardIdfrom anExtendedId(converting anExtendedIdinto aStandardId): as its documentation rightfully states, it's about extracting its Base ID.Therefore,
standard_id()should really be namedbase_id().Additionally, the included comment is wrong (there are no such things as a CAN
ID-28andID-18).Lastly, as we have at our disposal the following
constmethod (i.e. zero run-time overhead):We should use it to make
base_id()implementation-agnostic (rather than relying onself.0).Altogether, it should look like this: