On Thu, 1 May 2008 19:34:28 -0300 Werner Almesberger <[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]> _______________________________________________ hardware mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/hardware
