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

[Andy Green]

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

Somebody in the thread at some point said:

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

Well fine, but what does giving the MSP430 the battery backup actually
get us?  I don't think it really needs to hold much state that it can't
discover when it wakes back up?  If we can't think of what we can
leverage the backup power for on MSP430 then we can just leave the
battery on PCF50633 only since this is at least lower risk.  Of course
if there is some benefit we should consider it but I didn't think of one.

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

Exactly, this is the reason behind the "core" concept.  We need the core
to be deployable in any reasonable "clothes" like LCM, physical
dimensions, etc.  So it doesn't delay us that the LCM is not decided, we
design the core to not depend on particular display.

We have to design a particular variant to exact LCM dimensions etc but
this first time we prototype the core architecture as much as the first
variant using it, a buttload of work and verification and testing
software creation has to happen this first time around Linux + BSP, core
peripheral function and so on.  The earlier we get started with that the
less delay we will cause everyone on the back end.  But the SECOND time
we roll out that core will be a different story, we deal with the guts
of the second design as an already proven hardware design + software
stack and we have test software for it already.  We just need to keep
our eyes fixed on that happy goal while we navigate through current
unpleasant realities.

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

It's not a crazy argument, like I said the better chip is fine for me
and there is a little risk fixing on the small one before we wrote all
the code.  However, part of the core concept is that the core sets the
minimum cost of a device using it, we have to think about keeping its
cost modest, or it won't be usable on some hypothetical variant that is
really cost sensitive.  Then we're into using two core arches, etc,
better if we can max the spread of usage cases for the one.

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

Bitbang is pretty trivial when the clock in synchronous as in SPI or
I2C, it eats a bit of power to do it and MPU bandwidth is all.  UART
bitbang off timer is harder but it can still be considered.

| Maybe we can decide on the chip on Friday meeting?

We can do with such a decision so we can go on with the schematics
(which will need studying carefully against software needs in MSP430
anyway).

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

iEYEARECAAYFAkgQM2cACgkQOjLpvpq7dMocYQCfT6xZwt6I6Uj32MQmXOnxk/EP
ZUMAniaXEjpiRkGVL6D5bMKqkV0mpzwV
=jDF+
-----END PGP SIGNATURE-----