GTA04 Block V4 / risk and possibility

[Carsten Haitzler (The Rasterman)]

On Thu, 1 May 2008 19:34:28 -0300 Werner Almesberger <werner at openmoko.org>
babbled:

btw. a lot of the mpu need seems to stem fro our sleep and resume. i just
double checked - the nokia tablets (770/800/8100 don't suspend. they just go
into ultra-low power mode. as such i get many days of low power mode out of my
nokia.. WITH wireless on even. it is possible to do this. it pretty much
resolves our entire suspend/resume mess. servicing input for anything should be
nigh-instant. as such i believe the 6400 is much easier to play around with the
clocks on and that should mean this is all not so hard and something we
need/should do anyway.

i just had to reply to the mpu vs no mpu matrix as most of the arguments that
said "mpu is better" were use cases that had no value :( sure - purely
theoretical use cases, but practically they were not so valuable.

the one case i can think of is blinking led's - and hell. we can get led's that
blink themselves! no need for an mpu for that! :)

> Andy Green wrote:
> > Werner and I often find something to disagree about, but in this case it
> > seems we both are interested in how we can leverage a small supervisor
> > MPU in this design.
> 
> Indeed. What I think confuses the issue is that the MPU for the
> prototype ended up being pretty large, in terms of cost, storage it
> provides, and also physical size.
> 
> I started thinking about having such an MPU in November, when we hit
> some glue logic issue in HXD8, and I had some longing thoughts again
> when we hit the HDQ timing requirements. My idea was to get something
> in a 4x4mm package with ~8-15 usable GPIOs.
> 
> Unless we go too crazy with LEDs and buttons, I would still expect to
> end up in about that range. However, I agree that, during development,
> having a larger chip that already taps into everything can help us
> avoid having to do an extra board spin if we encounter something we
> haven't thought of before.
> 
> By the way, you saved us from disaster in the HDQ case by using FIQ.
> Now Mike found the GSM UART overrun problems, and it seems that the
> solution will require FIQ sharing, adding complexity and potentially
> cases where conflicts can't be resolved.
> 
> The MPU gives us more chances to dodge this kind of bullets,
> particularly if we discover them before we go MP ;-)
> 
> - Werner


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>