LED notification

[Kishore]

On Saturday 11 Oct 2008 7:25:38 pm Sam Kuper wrote:
> 2008/10/11 Andy Green <andy at openmoko.com>
>
> > Well you can simply wake and do "event" type actions like vibrate and
> > flash LEDs then, the stimulus you are responding to like incoming call
> > will be a CPU wake event so that lot will work.
> >
> > What can't be done (because of a completely Linux-centric POV in the
> > design) is anything while the CPU is off in suspend.  We can leave a LED
> > on during suspend, but there is no intelligence to flash it or whatever.
>
> So while the CPU is awake, it can set the state of the LEDs, etc, and then
> when it suspends, that state will remain unchanged?
>
> That actually doesn't sound *so* limiting.
>
> I guess that ultimately it would be nice if the states that you could leave
> the indicators in included cyclic states - "flash once every 2 seconds",
> for instance. This could perhaps be handled by a *very* basic
> microcontroller to which the CPU would devolve responsibility for managing
> the indicators. This would increase the richness of the hardware UI &
> provide developers/users with many more options for how the phone would
> behave in the suspend state.
>
> This is evidently the sort of thing the I2C LED drivers you mentioned above
> would be used for, but by "indicators", I'm thinking of not just the LEDs
> but also the vibrator, screen backlight & speakers. So something like a QFN
> PIC might be more appropriate than just an LED driver (although maybe an
> LED driver could be interfaced to non-LED indicators; I'm not sure).
>
> It's great to hear OpenMoko might introduce this sort of extra circuitry
> into the next generation of OM phones. It would be awesome if it was
> implemented as a retrofittable PCB for the FR, though I guess this would be
> pretty hard to achieve.
>
> > So overall it's not quite as bad as it sounded I hope.
>
> No, it isn't. I'm still not totally sure I want to spend ~400GBP on the
> FR+debug board just yet, but I'm much closer to doing so.
>
> Thanks for your quick reply,

In addition, i would recommend a look a look at multimedia functions. If the 
device were to play music (mp3) if there were ways to be more power efficient. 
Currently, i think this would consume a lot of power.

For the LED's, does the processor support PWM output in hardware? With the 
many smaller processors that i use, the PWM output continues to be active when 
the processor is in power saving mode. Of course, even the PWM output stop 
when the processor is in the "power down" mode.

This is just a thought. I have not seen the processor datasheet yet. But i 
agree with Sam and think that using one of the ultra low power micron 
controller such as one of the AVR pico series will allow greater flexibility 
with the ability to make it function like the device BIOS as well and upgrade 
its firmware if and when necessary. This could also help the battery charging 
problem when powered down!
-- 
Cheers!
Kishore