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

Andy Green andy at openmoko.com
Wed Apr 23 19:59:47 CEST 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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

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

Everyone seems to like that method of shared IO, it sounds like a good
policy.

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

|> 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 but probably
it would just crimp our style somewhat and not kill us.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgPeRMACgkQOjLpvpq7dMrw5QCfTUbD1YIa8yUJg4Eeb6oz+bPX
nvUAniG127gYttrbXGK/sPOydCEB8KTt
=pLtf
-----END PGP SIGNATURE-----




More information about the openmoko-kernel mailing list