Skip to content
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

Merged
merged 2 commits into from
May 20, 2024

Conversation

sjoerdsimons
Copy link
Contributor

No description provided.

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 {
Copy link
Owner

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 millivolts
  • max_voltage() -> MilliVolts where MilliVolts is some type representing voltage units (I'm assuming there must be some crate with these types already)
  • max_voltage_millivolts() -> u16

Copy link
Contributor Author

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)

Copy link
Owner

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 {
Copy link
Owner

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
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unnecessary u16::from here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indeed!

@fmckeogh fmckeogh merged commit dabad9d into fmckeogh:main May 20, 2024
2 checks passed
okhsunrog added a commit to okhsunrog/usb-pd-rs that referenced this pull request Jun 18, 2024
Add utility functions to access various part of source capabilities
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants