werner at openmoko.org
Tue Apr 28 09:10:57 CEST 2009
Bah, *had* to change the subject or we'll still writing in some
"welcome" thread in ten years ;-)
Florian v. Samson wrote:
> I am glad to see such a focused and open discussion discussion about the
> next steps of the OM hardware development. This is a novelty IMHO and
> bears some potential, though caused by an unfortunate situation.
Thanks :-) Yes, I think this is indeed a bit more radical than what
I've seen so far, but it also appears that it's now quite feasible to
take such a step.
> - DeNANDification & integration of IDBG (Internal Debug Board)
Ah, I'd leave IDBG out for the first prototype (i.e., "GTA02-core").
It's low-risk, but it's a change we don't really need there.
Also, a clarification about NAND: the 2442 MCP (multi-chip package)
has built-in NAND, so we can't avoid having it. However, we can avoid
using it for anything but Qi and certain configuration data (i.e.,
what is today the "factory" partition.)
The value of not using NAND is that bare NAND has many idiosyncrasies
that are visible at several places in the system and need considerable
effort for handling. Also, considering how large and cheap microSD is
these days, the comparably small NAND in the MCP hardly seems to
> - (My 2c:) Reverting the accelerometer IRQ change (including keeping
> *two* accelerometers) or rework accelerometer IRQs
Hmm, is anyone actually making use of both accelerometers in GTA02 ?
Also, they aren't entirely independent. E.g., no matter how the sensors
are placed, you still can't detect rotation around the axis that goes
> Why does the GTA lack an SIR- / CIR-Port (Simple-Infrared /
> Consumer-IR), which would enable a multitude of applications,
Feature creep, here we come ;-) I actually haven't seen much IR
being advertized on phones or laptops in the last years. Perhaps
everyone has moved to BT and USB ?
This brings us back to modularity. We've already established that
trying to have a generic electromechanical module system like ISA
or PCI isn't possible.
However, perhaps there might be a compromise. If there would be a
reserved area with the right connections within easy reach, that
should simplify a lot of extensions. You would still have to make
your own PCB and do the wiring, but you wouldn't have to hunt for
unused cavities and the wires could run short distances.
E.g., GTA02 could accommodate a 15x10x5mm volume at the location of
the debug board connector. A daughterboard with the complexity of
IDBG would fit there. So that's about 2-3 major components.
This approach has a number of limitations, though:
- this area has to be close to an easily modifiable part of the case,
so that access holes can be added (for sensors, connectors, etc.)
- the perimeter of the PCB is already a densely populated area
- in many zones, placing anything metallic may detune an antenna and
thus affect radio performance
- for connectivity, the reserved volume would have to be adjacent to
an area that has plenty of unused PCB space, e.g., the LCM
- no matter how much space is allocated, the module you want will not
Of course, with all the EDA files out in the open, there's always the
more costly but tidier approach of making a custom board variant. If
there are enough people who want IR (or ZigBee, RS-232 current loop,
etc.), then it might even be possible to combine this with the
production of "vanilla" units to save costs.
> BTW (an old tune), while I also think a System-Controller / BMC (almost
> as in big iron servers) is ultracool, could be utilised in many ways
> talk), etc.), and a TI MSP340F5xxx (these µCs are slow and resource
Right now, I'd just use a C8051F327 or the pin-compatible C8051F321,
since that one has the cheap USB we need for IDBG anyway. The 321 has
lots of built-in features and is supposed to be cheaper than a 326/327
in large quantities.
More information about the Gta03