Short answer is no, look at table in this ap note -
http://www.cypress.com/documentation/application-notes/an92584-designing-low-power-and-estimating-battery-life-ble AN92584 - Designing for Low Power and Estimating Battery Life for BLE Applications
In the scheme of things if you are keeping an LED alive the psoc
in other higher functional sleep modes still a fractional part of LED
current. Just a thought.
If you are doing two LED at 10mA each that you keep updating PWM values all the time (for fades), the 1mA is negligible anyway.
But with a single LED you could run it at 2mA and with 10% duty blinking rate it will use less than the PROC.
And if you PWM something else as the "LED dimmer" IC have push-pull so it should be able to be connected to anything that is less current draining. And strange that Cypress did not include away of using 32K clk to the pwm as to keep it running when at 1.3uA sleep.
I am going through the same thing and I agree that it would be nice to keep a 32khz PWM going in deep sleep.
I have a green LED that is too bright at 10ua, that is with a 500k series resistor (used in a dark room). I can still see it at PWM down to about 5% but can't figure out how to adjust brightness while in deep sleep, which my processor is most of the time.
Putting in much more than 500k resistor make it unreliably work so need PWM.
1000ua to get PWM is silly for me when I am adjusting 10ua.
This is a completely side conversation but I am curious about LEDs that can
produce any significant light at 10 uA. What part number are you using ?
Question, you want to adjust brightness while in deep sleep, what is the
controlling input being used to drive the brightness requirements, some
other sensor ...?
Yep, I was amazed too and I just went back and measured the series resistance at 500kohm :)
But it is a dark room application and very close to your eye so it has to be very dim.
It is just an RGB LED CLVBA-FKA-CAEDH8BBB7A363.
I am sorry I said I wanted to change brightness during deep sleep. I just want to set it every short awake cycle (50 msec apart) and have it stay fixed brightness during deep sleep.
Then use a CTBM, configed as an OpAmp V to I source, with a holding cap on V side,
and PWM out integrated to provide DC into V to I source with LED as load.
Wow that is a mouthful and totally greek to me :)
Best I can do right now is to maybe see that would be limited to PSoC 4 devices, correct?
I'll come back to this after I figure out how to program my PRoC.
A V to I converter. Attached.
If you take the PWM output and pass it to a LPF, simple RC, that will convert Duty Cycle
to DC value. Then attach that to OpAmp V to I. When you go to sleep tristate the output
pin of PWM to the LPF. Then the cap in the LPF will act as a S/H while you are sleeping.
Of course you have to do an error analysis, leakage, etc. to get at values. The LPF is
designed to control PWM ripple, see attached also.
Now I see :).
So you think a 5% PWM cell volts directly on the 500k resistor can be simulated with a variable current source set to almost no current.
It may have issues with the funky behavior I sorta remember seeing when I put really big series resistors in.
I will give it a try at some point, but now my prototype will have to just go with the 500k resistor and no adjustment.
Looks like a fair bit of board space to do this though.
I agree board space is impacted for sure, maybe 6 passives, 4 R's for the
OpAmp and R & C for LPF. Solution certainly not elegant. But if you
need to handle wide range of ambient light when going to sleep might
be a workable solution.
In deep-sleep the 32K signal can be sent to WCO OUT , at least you get it down by 50% using this squarewave.
With a XOR gate you can get any fixed duty rate you want as you would use it as a de-tuned freq doubler.
If you tuned it so it have 10% duty at 32K, when mcu is awake you can send faster PWM so it should be possible to get 10-99% while fully awake.
Be very careful using the freq doubler with the RC network. Its PW tolerance
is quite poor due to CMOS Vth typically 40-50% variation. Additionally if the
rise time slow at cap node input to XOR, you could get oscillation.
A better method would be http://www.eetimes.com/document.asp?doc_id=1230513