next-generation (now) MPU discussion / RAM/ROM-size requirements

[joerg at openmoko.org]

Am Do  24. April 2008 schrieb Andy Green:
> Somebody in the thread at some point said:
> | Am Mo  21. April 2008 schrieb Andy Green:
> |> Somebody in the thread at some point said:
> |> | Am Mo  21. April 2008 schrieb Andy Green:
> |> |> Somebody in the thread at some point said:
> |> |> | Very sure our RTC should move from PMU to MPU.
> |> |> | So is there any more need to have a backup battery for the PMU?
> Can we
> |> |> share
> |> |> | the battery between 50366 and 430?
> |
> | Any comments on this one?
> 
> It seems the PMU is decided to be PCF50633 again, which is fine by me.
> As I understood it the backup battery on PCF50633 has two jobs:
> maintaining RTC and also keeping the thing in "save" state instead of
> "off" state when there is no other power.
> 
> If we're sure there is no hit in the PMU more readily going to "off"
> state if there is no power, and we have a low risk story about trickle
> charge if the battery technology wants it, then sounds OK.
> 
> We probably can share the battery but I didn't really think of what
> better features it gets us.

Charging backup battery from 50633, thus avoiding dedicated charge circuitry.
Keeping the "save"-state and not messing around with these state changes of 
PMU. (though I don't see any big difference between save and off state, 
except for RTC and some lowpower-supply chain).
50633 datasheet says:
VBUBAT backup battery supply voltage min:1.6 - max:3 V
So depends on which battery (and support circuitry) we're going to use there, 
to meet the specs for 430.
Probably we're in again for 2 FETs switching power of 430 between Vbat and 
Vbubat, if we can't get from Vbubat the min:2.2V - 2.7V for flashing 

> 
> | Yep, this is $4.90/100 vs $12.90/100
> |
> | Very much depends on *your* needs for the sophisticated accelerometer
> thing.
> | If you can do this with 1k of RAM, 400 times/sec at maybe 6MIPS, *incl*
> | bitbanging, so I'm fine with it.
> 
> 1KByte is pushing it but with some scrimping it can do for the kind of
> things we have talked about.  A 100ms queue for accel data is only 30
> bytes at 100Hz, 120 bytes at 400Hz.  100ms of touchscreen might be
> another buffer the same.
> 
> I would also prefer to have your choice, lots more hw, smaller, but a
> bit more power and more expensive.
> 
> | Nearly OT to ask why we need 400 samples/sec from g-meter, and whether
> the
> | whole intelligence shouldn't go to this device to reduce it's amount
> of data
> | by some smart filtering in itself, instead of having a MPU for doing
> this.
> | Maybe if we spend the money for a smarter accelerometer, we're better off?
> 
> We have the same usage pattern on touchscreen if we service it here, we
> might as well cope with it.  The accels do have a threshold concept
> where below a minimum they will stay silent.  This is useful if we
> figured we are staying still for a long period, we stop polling them and
> set the threshold to restart polling when some movement is seen.
> 
> | We just ground upper plane (via CPU-GPIO), leave one (no, both) end of
> lower
> | plane open (via CPU-GPIO highZ), and connect other end of lower plane
> to a
> | MPU-GPIO (in irq enabled range of ports) with 100kR pullup. That's it!
> Touch
> | the screen --> IRQ on MPU. No polling, no A/D nothing.
> 
> OK, but maybe prototype this first and confirm the "crap level" if it
> has 100K impedence and there is ESD, etc, since we wake off it.  Some
> protection on the GPIO maybe needed too.  But sounds good.

ACK. We will keep an eye on this.


> 
> | IRQ in turn may start reading ts via A/D of MPU, or may wake CPU and we
> resume
> | A/D for ts as we always did.
> | If we do implementation of MPU the way I suggested when I was in
> London (*all*
> | I/O wired-OR shared between MPU, CPU & peripherial), we just can
> decide which
> | (M|C)ProcessingUnit should do the real readout.
> 
> Everyone seems to like that method of shared IO, it sounds like a good
> policy.

:-)
Though for ts readout it's _a_little_ more tricky (to do it the safe way - 
about driving L against H incidentally). But feasible anyway.

 
> | For a capacitive ts with I2C | UART or whatever protocol we got there,
> things
> | are quite different. Very largely depends on the exact protocol of TS, as
> | well as on whether we got some nINT-output on the ts....
> | There's no decision on ts yet, so no use to work on the details right now.
> 
> Yeah.  I think we aim to get started for first prototype with GTA02
> screen even... 

Yep.


> for our initial purposes it doesn't matter.  If the 
> capacitive ones have I2C it is easy, UART more of a trouble.
> 
> Although saying it is easy, we need to give thought about I2C bandwidth
> if we plan to use it for CPU comms, PMU and now possibly touchscreen.

The point is, we have to take and cope with virtually whatever ts we get from 
hardware supply side of FIC/OM. :-/ 
We heard in yesterday's meeting it's quite difficult to find the right screen, 
and technical considerations are not first point on the list.
Decision on that will take another few weeks it seems.

So we may start with GTA02 LCM right now as well.

 
> |> If the extra bitbanging and restrictions are too crazy, your choice is
> |> the next one that is the right size in MSP430 as far as I can make
> out too.
> |
> | At least this one has "plenty" of RAM, and enough flashROM for sure,
> to do
> | things like accelerometer integration and some sorta pattern matching
> of the
> | kind you suggested. And it reads in a whole dataword (well byte) frm
> serial
> | without waking the 430-cpu, just irq when done with it. Bitbang will
> be more
> | work for the little thing, maybe we even can't go to sleep at all with
> | bitbang (if there's more than 1 bit during the >6uSeconds for wakeup, for
> | e.g. 10uS we are at 100kBaud max! ABS max! No?)???
> 
> Hey I prefer the nice one too :-)  Just seeing if we can keep the price
> down.  It's some kind of bigger risk to use the smaller one 

Right. Just wondering how many devices we have to sell to break even on 
bargain_on_chip/unit(hw-supply)./.additional_effort_for_small_chip(sw-manpower).
If we save ~7$/unit on the hw, we need to sell roundabout 10 units for every 
hour of work that goes to hw- & sw-design and maintenance for the little 
chip.
Really guess it's much *more economic* to use the higher priced chip.

> but probably 
> it would just crimp our style somewhat and not kill us.

Sure we can cope with this, just additional weeks (/months?) of a man's work 
to get the bitbang etc done.
Later on we have the risk we can't do everything we like to do, due to low 
ram, high load etc.

Maybe we can decide on the chip on Friday meeting?


cheers
jOERG