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

ESP32-C3 GPIO's is_set_high and is_set_low functions always return false/true respectively #17

Closed
jessebraham opened this issue Dec 3, 2021 · 5 comments · Fixed by #18

Comments

@jessebraham
Copy link
Member

This is a strange issue, as I have had this working before.

My application runs as expected, with the exception that the LED does not blink. The loop index is printed over serial for each iteration of the loop as intended. I have confirmed my hardware and test setup are okay by flashing the blinky example from esp-idf, which worked as expected.

I have added the minimal project to a repository, generated from esp-idf-template:
https://github.com/jessebraham/esp32c3-idf-hal-test

Rust nightly version is quite new:

λ rustc +nightly --version
rustc 1.59.0-nightly (48a5999fc 2021-12-01)

I'm hoping I'm missing something silly here, but I have tried using multiple GPIOs, tried resetting the pin first, all to no avail.

@ivmarkov
Copy link
Collaborator

ivmarkov commented Dec 3, 2021

Looking into it...

@ivmarkov
Copy link
Collaborator

ivmarkov commented Dec 3, 2021

Will continue tmr after wrestling with it for an hour and then realizing I've not connected it to the Amp, but to the (switched off) lab power supply. My suspicion is that the toggle method implementation is broken. If that's the case, I'm not even sure how we would fix it, but we'll see.

@jessebraham
Copy link
Member Author

Thank you for looking into it. I apologize, I should have spent more time on this before posting. It does indeed seem like the toggle function is the issue, as when I switched to using a flag and set_high/set_low the LED now flashes.

toggle relies on is_set_high and is_set_low, and after a quick test I've determined that is_set_high is always returning false and is_set_low is always returning true.

@jessebraham jessebraham changed the title Unable to use GPIO on ESP32-C3 ESP32-C3 GPIO's is_set_high and is_set_low functions always return false/true respectively Dec 3, 2021
@ivmarkov
Copy link
Collaborator

ivmarkov commented Dec 4, 2021

Thank you for looking into it. I apologize, I should have spent more time on this before posting. It does indeed seem like the toggle function is the issue, as when I switched to using a flag and set_high/set_low the LED now flashes.

toggle relies on is_set_high and is_set_low, and after a quick test I've determined that is_set_high is always returning false and is_set_low is always returning true.

No need to apologize, sorry for putting in something without actually testing. is_set_low/is_set_high do not work because they are using APIs, which only work when the pin is configured for input mode and report the input level, not the output one.

Now, the little drama is, I don't see an API in esp-idf-sys which reports the output level of the pin. Hence why in their example they just use a state variable. However, I do think output level can be reported based on the hardware state, as done here. That is - if I disregard the comment which mentions something about a 'stateless' register, which does sound a bit worrying though.

What I can do is to temporarily remove the support for embedded-hal-'s StatefulOutputPin and ToggleableOutputPin traits, until we have support for the former one using an esp-idf-sys API. I don't think emulating those with a Rust variable is a good idea. And open an issue in ESP-IDF for that new API, which would report the state of the output pin register bit.

@ivmarkov
Copy link
Collaborator

ivmarkov commented Dec 4, 2021

OK so this is useful info.

However and as expected, bindgen is not intelligent enough (yet) to generate macro expansions for functional macros, so GPIO_REG_READ is nowhere to be seen in the bindgen output. Let me try to upgrade bindgen, and then try some of the workarounds described in that bindgen issue above...

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 a pull request may close this issue.

2 participants