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