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