LED notification

Sam Kuper sam.kuper at uclmail.net
Sat Oct 11 15:55:38 CEST 2008

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,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/community/attachments/20081011/501fa35e/attachment-0001.htm 

More information about the community mailing list