Documentation/API regarding default input pin pull up/down state

[jobafr]

Hi,

I'm currently in the process of porting some Arduino based ESP32 firmwares to Rust. On one device, we noticed that one of the input pins always read as high with the Rust firmware, even in situations where it should have been low, and where the Arduino based firmware reads it as low. After some digging, I found the PinDriver::set_pull method. By explicitly calling pin.set_pull(Pull::Floating) after creating the PinDriver object, we're now getting the desired behavior. Apparently, this is the default behaviour on Arduino (Our old Arduino based firmware just calls pinMode(PIN_XY, INPUT); and later digitalRead(PIN_XY), relying on the default as well, which apparently seems to be the equivalent of Pull::Floating).

If putting the pin into pull-up mode by default is a deliberate decision, where is stuff like this documented, and why does it differ between the Rust toolchain and the Arduino one?

As a side note, I was, in contrast, pleasantly surprised by the ADC API in esp-idf-hal, where there's no default attenuation for the ADC, and instead one has to explicitly choose one of the available attenuation settings by using a const generic. Being forced to choose the right option instead of accidentally relying on an arbitrary default seems like the better API design choice and would have saved us several hours of debugging.

[ivmarkov]

Here, the whole saga so far, for your education and entertainment :)

Seriously speaking, we were just discussing we plan to fix this to follow the "Arduino" model shortly after the new release of the esp-idf-* crates, which is happening as we speak.

[ivmarkov]

Also related I think

[ivmarkov]

BTW you might want to join the matrix chat: https://matrix.to/#/#esp-rs:matrix.org

[jobafr]

Thanks for the pointers! Between the three different issue threads and the matrix channels, what is the preferred communication channel for this?

[noahbliss]

Thanks for the pointers! Between the three different issue threads and the matrix channels, what is the preferred communication channel for this?

Probably the issue here: #343

[ivmarkov]

Yes either this or the PR link.

[Vollbrecht]

We changed the default behavior on transition and dropping, and its included in the latest point-release. I hope that solves the issue. In hardware terms the default now means every gpio register is set to its 0 value on drop and transition and in the transition case gets set to whatever the new state is. Here is the code

Closing it, feel free to add stuff and reopen it if you are not satisfied.