Post- GTA02

joerg joerg.twinklephone at gmx.de
Wed Mar 19 16:25:56 CET 2008


Am Mi  19. März 2008 schrieb Andy Green:
> >>  - Add a small lowpower MPU like TI MPS430 to manage everything
> >> seamlessly when main CPU is down.  Stuff like motion sensors, wake
> >> sources, battery management, maybe touchscreen, leds so there is an
> >> always-on "guiding hand" in the phone that is consistent and reliable
> >
> > Well sure a useful gadget, but hard to interface with the main cpu in a 
> > way 
> > that's not a bottleneck. Should G-meters be accessed by main cpu via this
> > MPU, or shall there be concurrent access. The first sacrifices flexibility
> > (If MPU can't do it, it can't be done), the second adds complexity to both 
> > hw & sw.
> > I'd prefer to have a main CPU, that's up to reasonable power and back to
> > suspend in a few milliseconds, plus a nice timer to periodically wake the
> > CPU, and all needed interupt lines well done, and intelligent 
> > peripherials. 
> > Alas i fear that's not easy to design.
> 
> Well that is kind of seeking to reduce the dead time (which will be
> hard), the MPU method eliminates the dead time and any inconsistency in
> behaviours. 

If mainCPU is awaking on one byte that has completed in uart. enters 
IRQ-handler to fetch the byte(s) from fifo, does an occasional string concat 
and some calculations etc, and goes to sleep again waiting for next IRQ, 
there will 0 dead time and overall power consumption might be less than that 
of the MPU in allways-on mode. But it's hard to design, given you don't 
create the chips from scratch.

> For the motion sensors, I imagine the MPU manages them 
> fully and we communicate with the MPU over SPI at 100sps if we really
> wanted or more likely  a lower rate.  Raw motion sensor traffic is only
> 600 bytes / sec (2 x XYZ bytes x 100sps) so this is fine -- currently
> motion sensors are quite expensive at 2 x 100Hz CPU interrupts and same
> rate event handling.  The MPU can do "integration" of motion for 100% of
> the samples over time as well even while the CPU is asleep, so it can
> approximate (not mega accurately, but the order of magnitude anyway) how
> far you moved and in what direction overall for arbitrary periods
> without the CPU.  (Similarly it can accurately profile sleep current
> consumption over HDQ without the CPU, something we would love).  We can
> do things like wake the CPU because you have been still for a while
> after traveling, or force airplane mode even if the CPU sleeps if it
> detects accelerations that only happen in airplanes, etc.
> 
> If the MPU can do gesture estimation, it means also that we can wake the
> CPU with a fully captured gesture handed to it when it wakes a second or
> two later... things should just have less discontiguities depending on
> the CPU state.  The CPU is then more like an expensive asset that we
> leave asleep until we already determined something important happened
> than the hassled thing that has to wake before any little thing can be
> achieved.

Yep, ACK. But we see here it's not really trivial. Above consideration has to 
be done carefully for each and every possible source of interesting data.
Of course there has to be GSM, GPS, Hold / jackinsert, WLAN, BT, BAT-HDQ & PMU 
and probably TouchScreen, all has to be checked for possible scenarios of use 
a MPU couldn't handle, and for conditions worth to be monitored to trigger a 
wake.
Especially the low level things are more hard to keep open - let's assume some 
weird example: I have an ambient light sensor and I havea LED in the switch. 
When I decide to use the photodiode for learning commands from my TV-remote 
and then send these via the LED, I can easily do so as long as these 
components are driven directly by main CPU GPIO. A MPU probably wouldn't be 
designed to do this highspeed magic for any of both. 
For a more feasible thing: wake up on noise (we have a mic!), e.g. for a 
babyfone. How to do this? Yeah i know it's not easy (or better: impossible) 
without MPU either, i only want to point out there's a lot to think about to 
keep the whole thing as "open" as possible, as adding complexity always 
reduces flexibility. 
My approach with fully interupt driven main CPU is a dream that never may come 
true due to chip limitations. However it's the way to go for "normal" power 
management (starting with scheduler), what doesn't mean we don't need a MPU 
to get the best from both.

cheers
jOERG





More information about the openmoko-kernel mailing list