Hi Al and others,

> > That's the key. I've just learnt
that we two have entirly different
> > approaches. I personally made the experience that the first time that
> > I usually truly understand a problem is when I have finished it's
> > solution for the first time.
> 
> Yes this is probably the way most people approach problem solving. For
> many years I did the same myself. Sit down, write some simple code at a
> very high level, that code called a function, or two, which werew ritten
> next, gradually building in layers until you discover what was necessary
> to actually solve the problem as I went along. This works for a little
> while, but, I think even Kris would agree.

Absolutely !
While there have been times that I've worked on proposals for designs (with
a fixed
timeframe for delivery and price) that worked out just fine, the better part
either
required :

- Partial bottom-up topology.
  I had to knock together some very basic proto HW and/or some basic code
  to visit the feasibility of my Low Level view of the system, and whether my
high
  level perception of the whole design _will_ actually work properly.

- Partial top down.
  Still had to first design and develop some Low level stuff in order to
generate
  my *own* specifications of the SW running on the HW at low level, and based   

  on that.. do the actual design.

The only time the above wasn't necessary was when I either used a part
(parts)
in a way I hadn't used them before, or I hadn't used the part at all.

I still recall the motto (what's his name again ?) of the guy that started
Cicuit Cellar :
My favourite SW tool is a soldering iron !!!!

I have had one occasion where I learnt the hard way that not visiting/confirming
Low Level first at design stage can cost you dearly.

> Most projects have to be
> studied and designed first, and all reasonable problems solved or
> anticipated before coding begins. THEN you can take the decision to code
> abstractly, or directly, it is now a matter of choice, and project need,
> rather than necessity. I understood from our many discussions that Kris
> is also an advocate of an intense design and specification period
> followed by a short code period and a long debug period, thus you and he
> are coding in a similar style, ut for very different reasons.

Again 101% agreeing with Al here.
His conviction is mine as well in that regard.
As above, on one occasion I thought I could "skip" this part, and it
turned out
at development stage that the (RF) HW was NOT able to perform as per datasheet.
I had to bear the extra design - cost wise - myself, and it had tought me a
valuable lesson.

-- Kris

I remember the story of the Computer Science Professor who said., " I
give
an assignment and the C students rush to the console, the B students go to
the computer room and think about the problem and then start coding, the A
students go to their rooms, design the program and then go to the computer
room."  DRAIT

----- Original Message ----- 
From: "microbit" <microbit@micr...>
To: <msp430@msp4...>
Sent: Tuesday, June 01, 2004 8:48 AM
Subject: Re: [msp430] Compiler-Benchmark / was: How to force the C-compiler
to use registers? [ND-Cerberus checked]


>
> Hi Al and others,
>
> > > That's the key. I've just learnt that we two have
entirly different
> > > approaches. I personally made the experience that the first time
that
> > > I usually truly understand a problem is when I have finished
it's
> > > solution for the first time.
> >
> > Yes this is probably the way most people approach problem solving. For
> > many years I did the same myself. Sit down, write some simple code at
a
> > very high level, that code called a function, or two, which werew
ritten
> > next, gradually building in layers until you discover what was
necessary
> > to actually solve the problem as I went along. This works for a little
> > while, but, I think even Kris would agree.
>
> Absolutely !
> While there have been times that I've worked on proposals for designs
(with a fixed
> timeframe for delivery and price) that worked out
just fine, the better
part either
> required :
>
> - Partial bottom-up topology.
>   I had to knock together some very basic proto HW and/or some basic code
>   to visit the feasibility of my Low Level view of the system, and whether
my high
>   level perception of the whole design _will_
actually work properly.
>
> - Partial top down.
>   Still had to first design and develop some Low level stuff in order to
generate
>   my *own* specifications of the SW running on the
HW at low level, and
based
>   on that.. do the actual design.
>
> The only time the above wasn't necessary was when I either used a part
(parts)
> in a way I hadn't used them before, or I
hadn't used the part at all.
>
> I still recall the motto (what's his name again ?) of the guy that
started
Cicuit Cellar :
> My favourite SW tool is a soldering iron !!!!
>
> I have had one occasion where I learnt the hard way that not
visiting/confirming
> Low Level first at design stage can cost you
dearly.
>
> > Most projects have to be
> > studied and designed first, and all reasonable problems solved or
> > anticipated before coding begins. THEN you can take the decision to
code
> > abstractly, or directly, it is now a matter of choice, and project
need,
> > rather than necessity. I understood from our many discussions that
Kris
> > is also an advocate of an intense design and specification period
> > followed by a short code period and a long debug period, thus you and
he
> > are coding in a similar style, ut for very different reasons.
>
> Again 101% agreeing with Al here.
> His conviction is mine as well in that regard.
> As above, on one occasion I thought I could "skip" this part, and
it
turned out
> at development stage that the (RF) HW was NOT able
to perform as per
datasheet.
> I had to bear the extra design - cost wise -
myself, and it had tought me
a valuable lesson.
>
> -- Kris
>
>
>
> 
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>