AVR-Chat

Dennis Clark Wrote
>  And then there is what I have taught my students and preach a bit about
>on the 'net.  It comes in part from Sherlock Holmes and part from my own
>experience:
>
>Data Watson!  Data!  You cannot make bricks without straw.
>
>and
>
>If the data does not make any sense, examine your assumptions, at least
>one of them is incorrect.

And reflect on whether what you think you are measuring and what you are
actually measuring are the same thing. And maybe whether you should be
measuring something else instead.  There's not much utility in measuring
how long something takes when what is important is how quickly it starts
(or vice versa), and if you actually need both only measuring half the
information may be of limited usefulness.

Record everything you do, it's very easy to forget previous informations or
worse remember it incorrectly.

Stop changing things, gather all of your symptoms together along with how
they changed as you modified things (see record everything), and just sit
down and think about what is happening.  You may need multiple attempts
starting from the original source each time to get enough information to
start making sense of the problem.

If it stops failing and you don't know why be worried.

Robert


--------------------------------------------------------------------
mail2web.com – What can On Demand Business Solutions do for you?
http://link.mail2web.com/Business/SharePoint

Another question is did this ever work?  If so, what has changed since then?
Hardware, software, environment, even things that "don't matter"

David's comment about how debugging is not taught gives me an idea.
Wouldn't it be fun to teach a class where you'd have a lecture/discussion
followed by a set up buggy problem for hands on skill building.  I took
something like this taught internally when I was at Apple and learned some
good techniques.  Doing it in the embedded world where you add the twist of
broken hardware would be a kick.

-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of subscriptions@aeolusdevelopment.com
Sent: Tuesday, February 05, 2008 9:50 AM
To: avr-chat@yahoogroups.com
Subject: Re: [AVR-Chat] serial communication

Dennis Clark Wrote
>  And then there is what I have taught my students and preach a bit about
>on the 'net.  It comes in part from Sherlock Holmes and part from my own
>experience:
>
>Data Watson!  Data!  You cannot make bricks without straw.
>
>and
>
>If the data does not make any sense, examine your assumptions, at least
>one of them is incorrect.

And reflect on whether what you think you are measuring and what you are
actually measuring are the same thing. And maybe whether you should be
measuring something else instead.  There's not much utility in measuring
how long something takes when what is important is how quickly it starts
(or vice versa), and if you actually need both only measuring half the
information may be of limited usefulness.

Record everything you do, it's very easy to forget previous informations or
worse remember it incorrectly.

Stop changing things, gather all of your symptoms together along with how
they changed as you modified things (see record everything), and just sit
down and think about what is happening.  You may need multiple attempts
starting from the original source each time to get enough information to
start making sense of the problem.

If it stops failing and you don't know why be worried.

Robert


--------------------------------------------------------------------
mail2web.com - What can On Demand Business Solutions do for you?
http://link.mail2web.com/Business/SharePoint




 
Yahoo! Groups Links






-- 
No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.19.20/1260 - Release Date: 2/5/2008
9:44 AM

> David's comment about how debugging is not taught gives me an idea.
> Wouldn't it be fun to teach a class where you'd have a lecture/discussion
> followed by a set up buggy problem for hands on skill building.  I took
> something like this taught internally when I was at Apple and learned some
> good techniques.  Doing it in the embedded world where you add the twist of
> broken hardware would be a kick.

Various places have done this officially, or unofficially.
I've heard tell of a game where a stereo or scope or something is
deliberately "broken" in some way, and the contest is to find the
problem with the minimum number of observations. Meter readings cost
so many points, waveform measurements so many etc..

In high school, we had components molded into ice cubes of resin in
different colors, and you had to identify the components.  Green ones
were easy, blue was intermediate like a diode and a resistor in series
or parallel, and red ones were hard, like a shorted turn in an
inductor, or a crystal.  They were numbered, so that there was an
answer sheet to sort it out in the end.  A fun game.

The worst technician I ever hired blacked out my written test...a test 
that some have sat down, looked over, and handed back saying "you don't 
want a technician, you want an engineer."  No, I want a technician who 
knows how to do more than change a board...but that's an epistle.

One of the best technicians had no formal training.

When this problem with technical people showed up, 25 or so years ago, 
we went to a 2 (actually 3) step hiring process.  We have a written test 
we use that they're required to at least take a stab at.  Some people 
clam up in writing, but if they seem to know what they're talking about 
we go to the next step.  That's a workbench with equipment and tools, a 
manual, and a piece of equipment that we've broken for the event.  
They're told to plan on spending a morning or an afternoon.

Back in the old days Tektronix had scope service training at their plant 
in Beaverton, may still do it.  The final "exam" was to troubleshoot a 
scope without taking the covers off and solely from the front panel 
indications.  They would cut transistor leads off, pull them out of the 
circuit, or wrap a wire around them and we had to troubleshoot to the 
base transistor circuit.  I miss those old 453 and 454 scopes.


REB


David VanHorn wrote:

>>David's comment about how debugging is not taught gives me an idea.
>>Wouldn't it be fun to teach a class where you'd have a lecture/discussion
>>followed by a set up buggy problem for hands on skill building.  I took
>>something like this taught internally when I was at Apple and learned some
>>good techniques.  Doing it in the embedded world where you add the twist of
>>broken hardware would be a kick.
>>    
>>
>
>Various places have done this officially, or unofficially.
>I've heard tell of a game where a stereo or scope or something is
>deliberately "broken" in some way, and the contest is to find the
>problem with the minimum number of observations. Meter readings cost
>so many points, waveform measurements so many etc..
>
>In high school, we had components molded into ice cubes of resin in
>different colors, and you had to identify the components.  Green ones
>were easy, blue was intermediate like a diode and a resistor in series
>or parallel, and red ones were hard, like a shorted turn in an
>inductor, or a crystal.  They were numbered, so that there was an
>answer sheet to sort it out in the end.  A fun game.
>
>
>  
>


[Non-text portions of this message have been removed]