GTA04 Block V4
joerg at openmoko.org
joerg at openmoko.org
Thu May 1 21:20:31 CEST 2008
Am Fr 2. Mai 2008 schrieb Andy Green:
> Somebody in the thread at some point said:
> | Now on topic:
> | MCU is a technically interesting thing to do for GTA04 (Engineer's
> point of
> | view), but I missed description of any exactly defined usecase up til
> | that would make me think it's worth the additional effort and -in
> | extremely high cost (13$/chip, Sean tells me: device costs increase by
> | 3 of part costs. Plus circuitry engineering, PCB-routing, FW-coding
> | expenses!).
> This $13 -> $60 figure is just disinformation. It is the 100-up pricing
> from TI's website for a device we believe is overkill anyway, but we put
> on the first prototype so we won't make problems running out of space.
> If we need the thing, it will almost certainly be in $4.90/100 variant,
> which probably costs FIC $2-3. OK?
> | Now I hear on the GTA04 meeting (that I missed (shame on me)),
> consensus was
> | we *will* use the MCU. So I think there have to be some good arguments
> | came up there on Wednesday to convince everybody except me it's worth
> to sell
> | GTA04 on X+~60$ with MCU, and there are usecases like x), y), z) and
> | corresponding added value of device, compared to a GTA04 w/o MCU that
> | for X$.
> That decision was made last Friday, on Wednesday I asked if there was
> any issue about the MPU being used: the answer was "no", and we moved on.
> | Please give me a comprehensive list of these usecases to
> | a) convince me it's the right thing to go MCU
> You two guys that now have a problem with the ~$2-3 MPU wasted most of
> Friday's meeting trying to sell the frankly crazy alternative of adding
> a *second S3C6400* to perform the MPU tasks.
It wasn't a try to sell sth, it was a question why we can't use a MCU that's
more powerfull and costs us less, and has a known toolchain. Frankly these
two guys didn't like the idea of a second CPU so much, but the statement
was "*if* it's not more cost in work and money, *and* it's feasible, let's
take the additional benefit of a really rocking CPU" *IF* we need a second
Anyway my statement still is: If we can fix it in software, we should NOT do
it in hardware. I'd appreciate very much to see a comparison of these two
ways to get low power and immediate response on events.
> We can make a cool phone either way,
So according to Sean_MP's rules, this means "do it without the MPU". Less
parts, more functionality. Sorry!
> but if the MPU pans out, it will
> allow us to go a further than people expect on battery life and in other
> areas. If it doesn't pan out, then no harm done since we design to work
> without it too from the start. Where is the problem?
The problem is: it takes additional manpower do implement MCU to the circuit,
and to have the software (both firmware and CPU-linux-system) up and running
on end of prototype design deadline (a close deadline), to keep the timeline
schedule for GTA04.
And I have been told I should advertise these timeline constraints to all
involved parties, with the premise from Sean "timeline is highest priority".
And I like to have a *sheet* where I can see what it gives us *benefit*
(detailed to the exact usecase) on one side, and where the *risks* are listed
on the other side of this sheet. So I can cross out every point while
designing the GTA04 circuit diagrams with Allen, and I can controll the
risks. And I can show this sheet to each colleague (and there are some every
day) who asks me "why for god's grace do we need this MCU". ("listen: when a
call comes in, without MCU... :(. And *with* MCU, it will look
like... :). ") A mere "it saves us power in standby" isn't detailed enough to
And I didn't hear of any dedicated sw-developer to even give a glance on this
FW-thing, not to mention promising to keep some deadline.
That's my problem.
One of my problems (just started to find them, every day a few ;)
More information about the hardware