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

Enable pull-up resistor in OneWire library #1226

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

luelista
Copy link
Contributor

Enable the internal pull-up resistor for the GPIO used by OneWire library. OneWire requires by its design a pull-up resistor, and if the internal one is not enabled an external resistor would be required.

@slaff slaff requested a review from anakod August 21, 2017 05:47
@slaff
Copy link
Contributor

slaff commented Aug 21, 2017

@ADiea @avr39-ripe Can you check this PR?

@@ -124,7 +124,7 @@ OneWire::OneWire(uint8_t pin)

void OneWire::begin()
{
pinMode(pin, INPUT);
pinMode(pin, INPUT_PULLUP);
noPullup(pin);
Copy link
Contributor

Choose a reason for hiding this comment

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

This looks like it will disable the pullup. To me this looks put here on purpose maybe the Arduino way is not to enable pullups?. Also be aware that if you enable pullups and also have pullups they will go in parallel making the equivalent smaller in value that together with line capacitance might not be appropiate for given sck frequency.
I would not touch lib code if it is working an tested as it probably is consistent with Arduino way. After onewire::begin you can manually set the pins to pullup in your client code.

@ADiea
Copy link
Contributor

ADiea commented Aug 21, 2017

I am not sure what is the default Arduino behavior here but I guess the default way is to disable pullups because there is a specifically disable pullups in the begin().

I would not enable them by default to not interfere with already present external pullups. If your application requires pullups internally I would advise of setting sda/sck pullups after ::begin() function is called. This will ensure everyone else is not affected by the change :)
Best regards

@@ -112,7 +112,7 @@
#define IO_REG_TYPE uint16_t
#define IO_REG_ASM
#define DIRECT_READ(base, mask) (digitalRead(mask) ? 1 : 0)
#define DIRECT_MODE_INPUT(base, mask) pinMode(mask, INPUT)
#define DIRECT_MODE_INPUT(base, mask) pinMode(mask, INPUT_PULLUP)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the really interesting change

@luelista
Copy link
Contributor Author

Hi @ADiea,
it is not possible to do it only in my application, without changing the library. The really important change is the one I highlighted above. The OneWire protocol is implemented by the library switching between Input and Output Mode all the time. If I would just change it to INPUT_PULLUP after my call to Onewire::begin(), it would be overwritten in no time. The change in the begin function is not important, the change in the headers is.

@luelista
Copy link
Contributor Author

luelista commented Aug 21, 2017

Ok, I've read up on the topic and I agree now that it's probably not good to change it unconditionally:

However, it works pretty well with the internal pull-up if the sensor is close to the controller, therefore I'd like to change the PR to make it configurable. Is that something you'd merge?

@uzi18
Copy link

uzi18 commented Aug 21, 2017 via email

@luelista
Copy link
Contributor Author

luelista commented Sep 5, 2017

Thinking more about this, I don't see a problem with just enabling the internal pull-ups all the time. If a "stronger" pull-up is needed in an application, we can just put an external pull-up resistor. It will be in parallel to the internal pull-up, lowering the resistance, which should not hurt.

Therefore I think it would help in many applications where the sensor is close to the ESP, making the external pull-up unnecessary, while being no problem in the applications where an external pullup is used.

@mikee47 mikee47 force-pushed the develop branch 2 times, most recently from 7b19c1b to 295a5f3 Compare February 22, 2021 15:50
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.

5 participants