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

Open drain pin emulation #39

Open
rumatoest opened this issue Oct 17, 2019 · 3 comments
Open

Open drain pin emulation #39

rumatoest opened this issue Oct 17, 2019 · 3 comments

Comments

@rumatoest
Copy link
Contributor

Hello.

I've spent some time trying link my HAL based driver for DHT sensors with rppal.

I think that rppal missing mostly 2 things right now:

  • software implementation of open drain pin
  • latest embedded-hal implementation for v2 traits

BTW I can create pull request if you are OK with open drain pin emulation

@golemparts
Copy link
Owner

Thanks for the suggestions! Sorry for the delayed response. digital::v2 traits have been implemented, and will be part of the next release.

Software-based open drain emulation sounds like it could be useful to have. This shouldn't be hard to implement using IoPin. I'll add it to the list for the next release as well. I appreciate the PR offer, but I prefer to give it a go myself first since it's a relatively small addition. If I run into any issues I'll give you a shout for some help. 😄

@David-OConnor
Copy link

This seems to be required for compatibility with the popular DS18B20 sensor as well, on the OneWire protocol.

@LeCyberDucky
Copy link

Howdy, I'd like to chime in here, as I'm looking for exactly this functionality. I'm not entirely sure whether any progress has been made here, but I'd like to add the following:

I've been looking at using an IoPin to simulate open drain, by switching between an input pin and a low output pin. When switching to output, I would like to set the level to low beforehand, to ensure that I don't start out in an undesirable state. The IoPin documentation, however, mentions that:

Depending on the mode, some methods may not have any effect. For instance, calling a method that alters the pin’s output state won’t cause any changes when the pin’s mode is set to Input.

This sounds like it's not possible to set the level beforehand. It seems like this problem has been looked into already in #88, but I believe that does not consider IoPin, meaning that I wouldn't be able to simply switch back and forth between input and low output.

What's the best way forward here? Am I overlooking some functionality that is already there?
If not, I'd be happy try implementing the needed functionality, in case that would be welcomed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants