AVR-Chat

Kathy Quinlan wrote:
> OK
>
> I think we need to split this discussion into 2 sections, those who
> are using an language for hobby and those who are using a language
> for work.
>
> The reason I say this is like a PCB layout program, hobbyists go for
> the package with all the included symbols and foot prints, where as
> professionals tend to generate their own.
>
> With C, most pre defined routines have set IO pins etc, but you may
> not want to have the LCD hanging of Port A etc.
>
> The debate so far has revolved around re using code, who says ASM is
> not reusable ? I find that I can go to an old project, and pull out
> modules as is needed, and re use them, I have a description block for
> each module which says what it is called by, what it does, what it
> expects as an input, what it outputs and what it destroys.
>
> There are LARGE amounts of ASM code available on the internet, and it
> only takes a few minutes to modularise it, so it can be reused later.
>
> Regards,
>
> Kat.


Kathy, let me draw another shape here.

I worked to IBM as a mainframe engineer from 1974 to 1993, mostly during the
first 12 years mainframes were not much intelligent, so they rely on human
expertise to locate and fix problems.  A simple flip-flop failing in some
part of the machine could take hours to locate and fix.  Even using an army
of several important electronic tools and machine microcode to exercise and
analyze answers, 200 pounds of manuals that if piled up could easily be
taller than me, it was a pure electronic debugging. In most cases it would
be simpler just following the error lamp back to what is causing it to lit,
even so it could take hours due some tricky set fast pulses or just a
failing indicator latch.

At that time a good engineer was the ones who could "see" the machine
working, what it needs to work and what could cause it to stop.  I was lucky
enough to work on the last kind of mainframes monsters like systems /360 and
/370 where without an oscilloscope and piles of infinite giant loops on
manuals one could do absolutely nothing to fix most of the problems.  After
several months of work, most engineers could be able to fix almost about
anything in those machines, not because they knew it, but they did
understand it.  Understand it means how the big blocks work, what is the
common reaction for different situations, what is sensible and what is not,
what is the vital and what causes more problems, where you need extra care
and what are the most tricky disorientation circuits that can lead you to a
wrong way.

An average engineer at that time, after good months of brain teasing, was
entitled to be considered as a "saint" by the customers with a failing
mainframe.  Customers use to protect the "saint", it was incredible. Several
times I went to customers in emergency call to put back a mainframe to work,
after fix it I saw other I/O machines with problems, like printers, tape and
disk units, but customers didn't want me to take care of it, they use to say
that repair customer service was already called, that I didn't need to waste
my time with those.  Can you see?  Like "save your miracles".  But even
being able to fix them all, we "the saints" use to have objectives to
coordinate other younger technicians and their jobs.

The ability to going into deep circuits and micro-code (as we called the
inner hardware + software interaction) that internally run the machine
instructions, a gross comparison with a PC BIOS), made us able to understand
almost anything around a mainframe, and for that recognized not only by IBM
management (I hoped so) as well by customers.

Here comes the catch:
The grow of machine population in the market, more and more mainframes were
all over, required more and more "saints", it cost money, training time,
etc.  Of course machines substitute human labor, mainframes "saints" were
not exception.  Sooner IBM released new mainframes that were able to
identify its own problems, constant concurrent tests with customer running
jobs, failing logs, intermittent failures identification and weeks of
auto-traces to isolate and identify the bad part, auto-calling to IBM parts
dispatch via dial-up connection, auto-call to technician dispatch to replace
the part in a hot-swap fashion, etc.   Technicians were not even dreaming
why that part should be replaced, why he was called at 3am to do it, and if
that action was a definite correct request of the machine, or if the machine
did it due a failing circuit at the "search and hit" failure scanning
mechanism.

Now, what happens if the same electronic board is being requested to be
replaced by the same machine, over and over?  Somebody in time will realize
something is wrong with that machine that can not fix itself, then a
super-saint should be dispatched there to fix it.  How you fix an
intelligent being?  Not with a screwdriver, but with a psychology degree
diploma.  You don't fix those machines anymore with an oscilloscope, that is
impossible. You need to analyze behavior, make questions and analyze
answers, search deep into the logs of memory to find out some strange turn
somewhere in time.

Now, try to match what a saint and a super-saint have in common.  They
understand the machine.  What the hot-swapping technician called 3am does
not?  He has no idea how the machine works, but he also help to fix the
machine, and this is only possible because the machine only could not spit
out the bad electronic card and suck in the new one.  Perhaps in the future?

Moving now to the programming thing, assembly, C, etc, what is the common
ground here.
Who needs to understand the microcontroller if you can program in C and the
compiler will do all the "machine understanding" job to create the working
software?  Nobody else.  Due the portability, if you know C then you
practically know all the machines, no matter what.

Really?
If that 100"sq board fully populated fails at intermittent fashion after
production, who you call to locate and fix it?  Somebody who wrote the C
source for another microcontroller and it was ported to this one? or
somebody that could run a step by step instruction and locate the failure
hardware execution?

When I go to a doctor to complain about a little pain in the finger, I don't
want to be diagnosed by someone that pulls a black notebook and search for
"finger pain" explanation.  I want to be diagnosed by someone who are able
to tell me not only about my pain, but about how and why the other fingers
can move without pain, how the whole system works and why.  Then I would
have found a "saint" that understand the machine, and probably he will be
able to precise identify and fix my pain.

What is the name we use to give to those guys?  Specialist.  Who is better
sit into the money chain at the professional world?  Who in some way teach
others?  Who will have better jobs and employers will fight over?

Something to think over.  It is not necessary that one write everything in
assembly, but it would be MUCH better if he/she is perfectly able to do so,
and decide what is better to use for that particular moment.

Wagner
-------

PS: The word "saint" here has no relation whatsoever with religious figure,
it was just a figurative way to describe someone that could do higher level
jobs.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.600 / Virus Database: 381 - Release Date: 2/28/2004