Lack of Specifications (was my work...)

Carsten Haitzler (The Rasterman) raster at
Fri Jun 6 09:29:39 CEST 2008

On Fri, 06 Jun 2008 07:35:00 +0100 Andy Green <andy at> babbled:

Well there is nowhere a spec that says the LED needs to do ANYTHING... :) so
even the LED is superfluous. we should ignore it. (as such i don't see an mpu
being needed to do anything with the LED while charging - why? we don't need to
suspend while charging as such as we have power, we can stay on. sure - it
won't charge as fast, but hey, nothing tells us how fast we must charge! :)). :)

in the end we dont have a spec. we have an existing platform we are stuck with
- for better or worse. if anything software should simply adjust to it and make
do. don't try and do things the hardware just won't be good at. some things are
raw requirements for the hardware, and we just can't ship without it, others
are entirely soft. :)

> Hash: SHA1
> Somebody in the thread at some point said:
> | - I think Raster made a good point when suggesting to use a
> |   microcontroller that does not require a development environment
> |   too different from the one we're already using.
> OK another s3c2442 it is then.  Maybe one more to make sure.
> I mused about where the actual problem here comes from when I woke up
> thismorning, like other running sores (eg, packaging system behaviours)
> I think the actual problem here is lack of a detailed spec, a solid
> goal.  We're flying by the seat of our pants in all areas based on where
> we are, not where we are going.
> I do not mean seeing "has an MPU" in the spec.  If the spec just took
> care enough to say, "charging LED consistently shows charging state at
> all times, even when device is 'off'", we narrowed it down to wiring
> that LED to PMU GPIO or having an MPU.  A few more assertions in the
> spec in other areas best dealt with by an MPU, and then the MPU is
> accepted with no argument.  (And on the other hand, if truly nothing in
> the spec can benefit from it, and we can't get the maintainability
> argument to fly: fine, no MPU was needed.)
> Instead what we got is us making these policies on the fly at
> implementation time, leading to reactionary "Hell, no" experts trying to
> guide the actual design of the device behaviours in realtime with about
> as much right as I have to do it.  The endless situation of not having a
> detailed spec to work against sets us all up for !success.
> Folks on the community list compare GTA02 to iPhone, I really doubt the
> guys at Apple are suffering the same muddle when it comes to device
> behaviours; bearded guys in pastel cardigans hand down tablets of stone
> about how their device should present itself from day one, because they
> have a detailed vision about it they can articulate.
> - -Andy
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora -
> iEYEARECAAYFAkhI2pQACgkQOjLpvpq7dMpblACfb9KjGwl7ITjpprZD3X8OAgF2
> UM4AnRq1j/n6DJfHhcwVmzdq/TEquTkx
> =QcHh

Carsten Haitzler (The Rasterman) <raster at>

More information about the openmoko-kernel mailing list