next-generation PMU discussion / RAM/ROM-size requirements

[joerg at openmoko.org]

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?



> |> | So anybody here who's unhappy with the MSP430FG4618?
> |> | Before I start to read the next 100 pages of manual to check if it
> |> meets our
> |> | specs.
> |>
> |> The price is a lot... I hope this price doesn't bear any resemblance to
> |> the "FIC price" because it is a bit hard to defend blowing $13 on this
> |> MPU.  I think we probably did some overkill needing 8K of RAM, 1K or
> |> maybe 2K should be fine.
> |
> | just it makes NO difference at all.
> | This is the only "model" with BGA113 footprint, and they are same
> price for
> | 4k - 8k and different flash-ROM sizes.
> 
> These prices are at qty 100 -- FIC will get way better pricing.
> This device is:
> 
> ''16-Bit Ultra-Low-Power MCU, 116KB Flash, 8KB RAM, 12-Bit ADC, Dual
> DAC, DMA, 3 OPAMP, 160 Seg LCD''
> 
> There are also some choices in 64QFN package
> 
> http://www.ti.com/litv/pdf/mpqf141a
> 
> This is 9mm x9mm 0.9mm thickness.
> 
> The BGA113 is better for sure, at 7.1mm x 7.1mm and 0.77 - 1.0mm high.
> 
> It's just possible we could do extensive bitbanging (with consequent
> higher power and software complexity) and use
> 
> http://focus.ti.com/docs/prod/folders/print/msp430f417.html
> 
> which is $4.90/100 in QFN. 

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.
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?


> |> | Andy: ts scanning won't keep the MPU awake, a touch is triggering a
> |> | hw-interupt on the A/D-input of 430. So no touch, no op (not even
> NOP ;)
> |>
> |> Don't we have to go around driving X then Y plane?  Is it OK to drive
> |> one plane all the time from a power POV, if that's what goes on?
> |>
> But the ADC does not look good enough for 
> touchscreen... but we could define that it only detects a touch action
> and not the coordinates (shares the touchscreen so it looks only while
> CPU down).

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.
IRQ i 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.
No quiescent current (other than pullup for GPIO), no risks in design, 
virtually no additional components. :-) ((really I thought this is obvious))

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.


> 
> 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?)???


/jOERG