esp-idf-hal icon indicating copy to clipboard operation
esp-idf-hal copied to clipboard

Published 20 hours ago • verified publisher icon esp-rs

Next

Open ivmarkov opened this issue 3 years ago • 1 comments
trafficstars

ivmarkov avatar Aug 05 '22 13:08 ivmarkov

I've been following this branch with my project and right now the only issue I am having is that when calling .into_output() or .into_input() on a new ("disabled") PinDriver, the original PinDriver (the "disabled" one), gets dropped AFTER the pin is configured to input/output. The result is that the pin is reset to input w/ pull-up during drop() of the "disabled" PinDriver.

I've even run the blinky example and seen that this was the case.

mertzt89 avatar Aug 31 '22 19:08 mertzt89

I've been following this branch with my project and right now the only issue I am having is that when calling .into_output() or .into_input() on a new ("disabled") PinDriver, the original PinDriver (the "disabled" one), gets dropped AFTER the pin is configured to input/output. The result is that the pin is reset to input w/ pull-up during drop() of the "disabled" PinDriver.

I've even run the blinky example and seen that this was the case.

Good point! Let me look into this.

ivmarkov avatar Sep 06 '22 13:09 ivmarkov

I've been following this branch with my project and right now the only issue I am having is that when calling .into_output() or .into_input() on a new ("disabled") PinDriver, the original PinDriver (the "disabled" one), gets dropped AFTER the pin is configured to input/output. The result is that the pin is reset to input w/ pull-up during drop() of the "disabled" PinDriver. I've even run the blinky example and seen that this was the case.

Good point! Let me look into this.

I think I fixed this now. Also, I've implemented PinDriver constructors that put the pin directly into the desired state. E.g. you can now use PinDriver::input(...)? instead of doing the PinDriver::new(...)?.into_input()? weird dance.

PinDriver::new is therefore now retired as well.

ivmarkov avatar Sep 06 '22 15:09 ivmarkov

I've been following this branch with my project and right now the only issue I am having is that when calling .into_output() or .into_input() on a new ("disabled") PinDriver, the original PinDriver (the "disabled" one), gets dropped AFTER the pin is configured to input/output. The result is that the pin is reset to input w/ pull-up during drop() of the "disabled" PinDriver. I've even run the blinky example and seen that this was the case.

Good point! Let me look into this.

I think I fixed this now. Also, I've implemented PinDriver constructors that put the pin directly into the desired state. E.g. you can now use PinDriver::input(...)? instead of doing the PinDriver::new(...)?.into_input()? weird dance.

PinDriver::new is therefore now retired as well.

I tested your changes and they work correctly. Thanks!

mertzt89 avatar Sep 06 '22 22:09 mertzt89