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
> now,
> | that would make me think it's worth the additional effort and -in
> relation-
> | extremely high cost (13$/chip, Sean tells me: device costs increase by
> factor
> | 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
> that
> | 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
> sells
> | 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 
CPU.
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 
convince anybody.
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 ;)

cheers
jOERG




More information about the hardware mailing list