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

gpio port not actually Floating #213

Closed
daschl opened this issue Sep 6, 2020 · 7 comments · Fixed by #220
Closed

gpio port not actually Floating #213

daschl opened this issue Sep 6, 2020 · 7 comments · Fixed by #220
Assignees
Labels
bug Something isn't working

Comments

@daschl
Copy link

daschl commented Sep 6, 2020

Hi,

I'm not sure if this is expected, but it at least looks "weird" to me. The issue is that my Input, even though marked as Floating, doesn't work out of the box, only if I call into_floating_input explicitly on it.

So, consider this code:

let peripherals = Peripherals::take().unwrap();
let port1 = p1::Parts::new(peripherals.P1);
let external_temp_sensor = Tsic::new(port1.p1_08.into_floating_input().degrade());

This work as expected (my Tsic takes Pin<Input<Floating>> as an argument). But if I do it like this, it compiles, but I'll never get the high and low states of the pin:

let peripherals = Peripherals::take().unwrap();
let port1 = p1::Parts::new(peripherals.P1);
let external_temp_sensor = Tsic::new(port1.p1_08.degrade());

Would it be possible that the port on the peripheral is neither Floating, nor PullDown or PullUp but it would always have to be turned into one of these types? This would make it explicit that it needs to be called, I couldn't figure out why my sensor didn't work and only stumbled on this by trial and error. Or is there something else going on that I'm missing?

@jonas-schievink
Copy link
Contributor

Hmm, what does the datasheet say? Maybe not every pin starts in floating input mode?

@daschl
Copy link
Author

daschl commented Sep 6, 2020

@jonas-schievink I couldn't locate it in the datasheet. Sorry forgot to mention it's the 52840 DK and the pin I use is P1.08

@jonas-schievink jonas-schievink added the bug Something isn't working label Sep 11, 2020
@jonas-schievink
Copy link
Contributor

Oh, I see the problem. The PIN_CNF registers are all initialized with INPUT set to Disconnect, so whatever is on the pin doesn't actually get sampled into the input buffer. Calling into_floating_input explicitly connects the input buffer.

@jonas-schievink
Copy link
Contributor

This seems to be the case for every nRF chip. I wonder why nobody hit this before.

I think the proper fix would be to introduce a new "Disconnected" or "Reset" pin state and make every pin start in this state.

@jonas-schievink
Copy link
Contributor

@daschl Can you try out #220? That should fix this issue.

@daschl
Copy link
Author

daschl commented Sep 11, 2020

I won’t be able to test it over the weekend, but next week I’ll give it a try. From looking at the change it makes a lot of sense to me.

@daschl
Copy link
Author

daschl commented Sep 14, 2020

Got it tested, works great - thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants