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

zoul/remote-revb: initialize unused pins to minimize current draw (WIP) #1920

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

alignan
Copy link
Member

@alignan alignan commented Nov 3, 2016

This is a work in progress to reduce the current draw from pins not used, please feel free to drop any comment or suggestion!

Testing with the examples/zolertia/zoul/zoul-demo with the following changes:

  • NETSTACK_MAC.off(1); in L128 commented out
  • PROCESS_YIELD(); in L145 changed to PROCESS_WAIT_EVENT_UNTIL(0)
  • NullRDC commented out in project-conf.h

So far in PM2 the current drops from 2.73mA to 0.672mA, but some work is still required. There is around 500uA consumed by the XTAL oscillator (32KHz), as gatting the pads reduces the current consumption to 50uA. Dropping to PM3 yields around 32uA.

The values are measured on the battery input of the RE-Mote.

@alignan alignan changed the title zoul/remote-revb: initialize unused pins to minimize current draw zoul/remote-revb: initialize unused pins to minimize current draw (WIP) Nov 3, 2016
@alignan
Copy link
Member Author

alignan commented Nov 3, 2016

note to self: Scheduling a rtimer spikes the current consumption to almost 8mA

@bthebaudeau
Copy link
Member

Yes, a tickless implementation would help (as previously discussed).

#define CLEAR(x, y, z) GPIO_SOFTWARE_CONTROL(GPIO_PORT_TO_BASE(x), GPIO_PIN_MASK(y)); \
ioc_set_over(x, y, z); \
GPIO_SET_OUTPUT(GPIO_PORT_TO_BASE(x), GPIO_PIN_MASK(y)); \
GPIO_CLR_PIN(GPIO_PORT_TO_BASE(x), GPIO_PIN_MASK(y));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do/while(0) or a GCC compound statement ({}) would be better.

GPIO_SET_OUTPUT(GPIO_PORT_TO_BASE(x), GPIO_PIN_MASK(y)); \
GPIO_SET_PIN(GPIO_PORT_TO_BASE(x), GPIO_PIN_MASK(y));

#define INPUT(x, y, z) GPIO_SOFTWARE_CONTROL(GPIO_PORT_TO_BASE(x), GPIO_PIN_MASK(y)); \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

z is unused.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean that z should be used with ioc_set_over(), not that it should be removed.


INPUT(GPIO_D_NUM, 0x03, IOC_OVERRIDE_DIS); /* RTCC interrupt */
CLEAR(GPIO_D_NUM, 0x04, IOC_OVERRIDE_DIS); /* LED */
CLEAR(GPIO_D_NUM, 0x05, IOC_OVERRIDE_DIS);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IOC_OVERRIDE_DIS is fine for the outputs, but it's not for the inputs (besides the issue with the last parameter of INPUT()), unless the pin is always driven externally, whether it is by the output of another chip or by an external pull resistor, etc.

Except for PC0-3, all the pins are set as GPIO inputs with internal pull-up resistors by the CC2538 after reset, which is already optimal for power consumption, unless there are external components forcing a low level on the pin or enabled by a high level on an input of theirs.

Also, all the components of the board could be switched off by default, and only enabled when needed (dynamically), but this sometimes lengthens the access times because of an additional wake-up time.

The sleep modes could be better used.

The µDMA and interrupts should be used instead of polling where possible.

The system frequencies could be tuned according to the application requirements, even dynamically.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the pointers!, I will fix the INPUT macro left-over

alexrayne pushed a commit to alexrayne/contiki that referenced this pull request Jul 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants