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

attachInterrupt() current consumption #153

Closed
d00616 opened this Issue Apr 26, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@d00616
Copy link
Contributor

d00616 commented Apr 26, 2017

When the MCU goes into sleep mode after attachInterrupt() it consumes 1mA. This is too much for a battery powered application.

I prefer to switch from Config Channels to Pin Sense. This allows sleeping with uA current. Pin Sense is not so flexible like Config Channels. This requires a logic to find out what pin was changed. Falling and Rising detection is easily possible. Pin change needs some logic.

Switching to Pin Sense allows monitoring of more Pins than Config Channels.

If it not possible to switch to pin sense, I need handling of NRF_GPIOTE->EVENTS_PORT, so I can implement my own routine.

When it is acceptable to switch to Pin Sense, I create a Pull Request.

Btw. I think the actual implementation will fail when multiple pins are inserted and removed in different order.

@sandeepmistry

This comment has been minimized.

Copy link
Owner

sandeepmistry commented May 8, 2017

@d00616 how are you making the board go to sleep?

@d00616

This comment has been minimized.

Copy link
Contributor Author

d00616 commented May 8, 2017

@sandeepmistry I use the __WFE(); __SEV(); __WFE(); sequence.

When GPIOTE channels are disabled, I measure a sleeping current around 3uA. When enabled the current is around 950uA. -> https://devzone.nordicsemi.com/question/2471/gpio-wakeup-low-power-workarounds/

@d00616

This comment has been minimized.

Copy link
Contributor Author

d00616 commented Jul 2, 2017

Hello @sandeepmistry it seems the high current consumption is a nRF51 specific problem documented as PAN #39. It's marked as fixed in PAN v 3.0 and later: http://infocenter.nordicsemi.com/pdf/nRF51822-pan_v3.0.pdf

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.