-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add utility functions to access various part of source capabilities #14
Conversation
Even though the SourceCapabilities message is just a list of 32 bit pdos, some properties are encoded in the first pdo (aka the mandatory vsafe 5v one). Moving to a newtype allows adding some utility functions to get the whole message capabilities directly on it. Signed-off-by: Sjoerd Simons <[email protected]>
The voltage/current/power values in the various pdos require translations to real numbers; Add utility functions for this and rename the field to raw_ to avoid accidentally using the wrong function. For clarity also suffix the function by the returned unit if it's not the standard unit. Also for consistency use max instead of maximum everywhere Signed-off-by: Sjoerd Simons <[email protected]>
} | ||
|
||
impl SPRProgrammablePowerSupply { | ||
pub fn max_voltage_mv(&self) -> u16 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand this is subjective, but I'm not loving the _mv
here. Which of the following do you think is best?
max_voltage() -> u16
, with a doc comment explaining the return value is in millivoltsmax_voltage() -> MilliVolts
whereMilliVolts
is some type representing voltage units (I'm assuming there must be some crate with these types already)max_voltage_millivolts() -> u16
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is uom
which is meant to have no_std functionality and has types for e.g. voltage; So i can have a look at that to see if that ends up being overkill or note..
fwiw I discounted the first option is it ends up being surprising if voltage doesn't give you volts.. The third option is also ok by me, it's just a bit more typing (with mv being a common shorthand)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like uom
, I'm happy to merge this commit as is, and I'll implement it.
u16::from(self.raw_min_voltage()) * 100 | ||
} | ||
|
||
pub fn max_current_ma(&self) -> u16 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as _mv
comment
|
||
impl EPRAdjustableVoltageSupply { | ||
pub fn max_voltage_mv(&self) -> u16 { | ||
u16::from(self.raw_max_voltage()) * 100 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unnecessary u16::from
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
indeed!
Add utility functions to access various part of source capabilities
No description provided.