-
Notifications
You must be signed in to change notification settings - Fork 198
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
Inverting GPIOs #178
Comments
I think in general if the hardware supports it we will accept PRs, so go nuts :) Just as a note I am in the process of completely rewriting the |
We have everything needed to do that in
Only thing we are missing is a way to expose it in the API. That is everywhere we want to have this feature we need a special constructor for the peripheral driver that allows to specify if a pin should be inverted or not. |
@bjoernQ How we can invoke the inversion? E.g. here it's used in SmartLED which should have inverted signal: https://github.com/georgik/esp32-buddy-rs/blob/feature/update-hal-2023-05/examples/rainbow.rs#L89
Should be just GPIO25 womehow wrapped or do we need to make whole driver inverted? |
Pins get passed into the drivers and the drivers configure the pins accordingly (e.g. here esp-hal/esp-hal-common/src/pulse_control.rs Lines 761 to 763 in 7b3e19c
In this case we would need to call This then needs to be reflected in the user-facing API (e.g. alternative constructors with an option to invert a pin) |
Why?
Today I came across a SPI device that has an inverted CS line. With the current HAL implementation, this situation cannot easily be handled: The
SpiDevice
trait as implemented onSpiBusDevice
requires an IO that implements theOutputPin
trait from theesp-hal
, hence something likeinverted-pin
doesn't work. This leaves me with having to foregoSpiBusDevice
in favor of manually handling the CS line which isn't nice.What to do about it?
The esp32 has hardware support for inverting both input and output GPIOs in hardware, via the
GPIO_FUNCx_(OUT|IN)_INV_SEL
bit.Hence, I think it would be possible to add GPIO inversion at zero cost by extending the
Pin
trait fromesp-hal
. What are your thoughts on this? Would you accept a PR that implements this?The text was updated successfully, but these errors were encountered: