WAITPNE running at RCSLOW
Mag748
Posts: 269
Hello,
I have a project that requires low power consumption, as well as being always on and ready to spring to action.
I have figured out that I must have the prop running at all times as the boot up period is too long.
Currently, I have the prop go into RCFAST and then run a WAITPNE command until a user presses a button, at which point the prop uses the CLOCK object to speed up to XTAL + PLL mode.. The prop consumes about 740uA during the waitpne command. This is still a little high for my runtime requirements.
When I try switching to RCSLOW during the WAITPNE command, the consumption goes down to 20uA! (very good!) Unfortunately, there is an issue running at this slow speed. The prop does not recognize the button being pressed until many hundreds of milliseconds after the fact, at which point the prop speeds up and does its task.
Is this delay due to the extremely slow clock cycle as well as the many commands that must be executed in order to switch to the high clock freq?
Is there any way to obtain the 20uA power consumption while reducing the time the prop comes back to life?
I have attached the code I am using for this test for your reference.
Sincerely,
Marcus.
RCSlowTest.spin
P.S. My current measurements are taken from a 6V supply before being regulated to 3.3V with the Microchip MCP1702.
I have a project that requires low power consumption, as well as being always on and ready to spring to action.
I have figured out that I must have the prop running at all times as the boot up period is too long.
Currently, I have the prop go into RCFAST and then run a WAITPNE command until a user presses a button, at which point the prop uses the CLOCK object to speed up to XTAL + PLL mode.. The prop consumes about 740uA during the waitpne command. This is still a little high for my runtime requirements.
When I try switching to RCSLOW during the WAITPNE command, the consumption goes down to 20uA! (very good!) Unfortunately, there is an issue running at this slow speed. The prop does not recognize the button being pressed until many hundreds of milliseconds after the fact, at which point the prop speeds up and does its task.
Is this delay due to the extremely slow clock cycle as well as the many commands that must be executed in order to switch to the high clock freq?
Is there any way to obtain the 20uA power consumption while reducing the time the prop comes back to life?
I have attached the code I am using for this test for your reference.
Sincerely,
Marcus.
RCSlowTest.spin
P.S. My current measurements are taken from a 6V supply before being regulated to 3.3V with the Microchip MCP1702.
Comments
I too have very low power requirements. Typically I can get the prop's consumption down to about 10 uA, with a single cog running and in one of the WAIT states. To get down to that level, it is also important to have all your I/O settings properly dealt with, and none of them floating.
I suspect you are operating a Spin program, and, while the change on the pin is immediately acted on, the Spin interpreter takes many cycles to execute its functions. I believe you will find the assembly approach much more responsive to switching back to the higher speed oscillator.
Cheers,
Peter (pjv)