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 temp/vref controls #422

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

fuchsnj
Copy link

@fuchsnj fuchsnj commented Apr 25, 2022

Previously when an Adc is initialized, the temp/vref sensor was disabled. During an ADC read, the sensor has to be turned on and off, which significantly increases the time it takes for a read. Additionally, since there was no way to enable to sensor manually, I don't think it was possible to read VREF in DMA mode.

Now, there are 3 additional functions, enable_temp_vref, disable_temp_vref and is_temp_vref_enabled. These functions are optional, and will speed up reading from the ADC if it is enabled manually.

The read_aux function now also only enables the sensor if the temp or vref channel is being read.

I tested this with an STM32F103 (bluepill)

@TheZoq2
Copy link
Member

TheZoq2 commented Jun 13, 2022

Thanks for the PR, and sorry for the review delay! Looks good to me, I left a small note on the return value of enable_temp_vref for discussion.

Could you also add this change to CHANGELOG.md?

@fuchsnj
Copy link
Author

fuchsnj commented Jun 14, 2022

I'm not seeing the note on the enable_temp_vref function, but I don't have strong opinions on how the return value is decided.

The options:

  1. (current approach), return true if the function changed something, meaning the sensor was previously off.
  2. Returns if the sensor was previously on.

I'm fine switching the approach if that sounds better, the one I picked was mostly arbitrary.

@TheZoq2
Copy link
Member

TheZoq2 commented Jun 15, 2022

My question was more about if the function should return anything at all. Is there a use case for knowing if it was previously on (or off)?

@fuchsnj
Copy link
Author

fuchsnj commented Jan 4, 2023

My question was more about if the function should return anything at all. Is there a use case for knowing if it was previously on (or off)?

Possibly. If that's blocking this change I'm fine removing the return type though.

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.

None yet

2 participants