next-generation MPU discussion
joerg at openmoko.org
joerg at openmoko.org
Fri Apr 25 17:43:34 CEST 2008
Am Fr 25. April 2008 schrieb Werner Almesberger:
> joerg at openmoko.org wrote:
> > The idea is *every* GPIO is I *and* O, so you have maximum flexibility.
>
> Our layout girls are probably busy making "Joerg" voodoo dolls right
> now ;-)
She's sitting next booth to me, so far I didn't notice any black magic.
Well even schematics not started yet, let's wait for the PCB-routing... ;-)
>
> I'd say that we should consider GTA04v1 (v0 ? ;-) as a first test
> balloon, where we can do things that won't make sense in the final
> product, if doing those things helps us to speed up development.
>
> This will also help us avoid endless haggling about some minor features
> that may get overridden later by larger design decisions anyway.
>
> So I'd agree with the MPU being able to do more than strictly needed.
> Then, as development continues, we'll gradually get a better idea of
> what we really need and what not, and then we can always decide to
> remove some connections
Remove connections? Never! Maybe remove a whole layer, so it's worth it, but
some connections... :-/
> or even to pick a less powerful and cheaper
> chip.
Yep.
>
> By the way, "help to speed up development" should also go for our
> hardware team. If any of this sounds unreasonable for you, please don't
> hesitate to raise your concerns.
>
> It wouldn't do us any good to design a software engineer's wet dream
> platform where all the system software can be easily done in half a
> day, but where we need a 50-layer board and dozens of prototype runs
> to get the hardware working ;-)
>
> > BTW: which number of LED is GTA04
>
> I don't think we know yet. I think Steve hates them a bit. I'd like
> to have at least one "engineering LED" for debugging, but it doesn't
> have to be visible when the case is closed :-)
We have to plan for _some_ maximum. 64? 256? Drop some of them later no
problem. This is our core-design!
cheers
jOERG
More information about the openmoko-kernel
mailing list