Computer programmers' habits in electronics

[John Popelish]

Jim Thompson wrote:
(snip)

When I kept using block diagramming she got pissed at me and started
giving me F's on the assignments, in spite of the resulting code being
quite compact.

Then I skipped the final since I could care less about the credit.

So I got a F for the course.

The dean, Shirley something or other, wrote me a letter expressing
concern for my academic future.

I sent her back a note, "Surely Shirley, Aren't you capable of reading
my records? I already possess a Masters in electrical engineering."

She didn't reply ;-)

There is no one more bull headed than a person who has a method that
both fits how their mind works, and gets the job done. ;-)

I had to argue with a professor, once, because the assignment was
supposed to illustrate a weakness of a particular numerical method for
solving simultaneous equations. I don't enjoy failure, so I designed
a little add-on to the program, that eliminated the weakness, and
solved the troublesome equations. For some reason, he didn't like it
that I got answers. I thought I deserved an A for understanding the
problem well enough to solve it. He wanted to give me a D for not
following the directions, exactly.

 

[PeteS]

This was a custom compiler for parallel C. With parallel processors
(SIMD architecture) one could do this

where(x == active)
{
do_something;
}

which would run on the procs that x == active was true and run noops on
others.

Cheers

PeteS

 

[PeteS]

There's a 'where(x)' construct in C? How is it implemented?
Where is this documented?

Surely you mean "while(x)", yes?


Methinks you have been programming Fortran or LISP too much.

Done both, enjoyed them.

Although I answered, perhaps you should consider carefully reading
everything I wrote. I mentioned it was a massively parallel system
(well, 320 parallel, anyway) and a construct such as 'where(something)
is perfect in a parallel SIMD world.

I actually wrote that I loved the C 'where(x) construct'. There was no
mention of it being ANSI C

Cheers

PeteS

 

[Martin Riddle]

As a circuit designer I've always liked "block" diagramming of a
system before I begin, so I don't create redundant (or useless)
circuit chunks.

So I find it hard to fathom how you can write software without some
similar organizing scheme.

I once took a course at the community college in Pascal (that will
date me

The instructor insisted on using "outlining" which, to me, was trying
to write raw code without any sense of direction.

When I kept using block diagramming she got pissed at me and started
giving me F's on the assignments, in spite of the resulting code being
quite compact.

Then I skipped the final since I could care less about the credit.

So I got a F for the course.

The dean, Shirley something or other, wrote me a letter expressing
concern for my academic future.

I sent her back a note, "Surely Shirley, Aren't you capable of reading
my records? I already possess a Masters in electrical engineering."

She didn't reply ;-)

LMFAO

 

[Spehro Pefhany]

This was a custom compiler for parallel C. With parallel processors
(SIMD architecture) one could do this

where(x == active)
{
do_something;
}

which would run on the procs that x == active was true and run noops on
others.

Cheers

PeteS

It's a little cheeky to call it a "C construct" when it isn't
mentioned in the standard.


Best regards,
Spehro Pefhany

 

[Geoff Joy]

Done both, enjoyed them.

Although I answered, perhaps you should consider carefully reading
everything I wrote. I mentioned it was a massively parallel system
(well, 320 parallel, anyway) and a construct such as 'where(something)
is perfect in a parallel SIMD world.

I actually wrote that I loved the C 'where(x) construct'. There was no
mention of it being ANSI C

Cheers

PeteS

And I did consider everything you wrote. Which is why I asked how it
was implemented since as a function, where() would have had to have
been exactly that, a function. Your choice of the word "construct"
keyed me into that. Strictly speaking, "while" is a keyword, not a
construct or a function call.

Now, what's the difference between

where(x == active)
{
do_something;
}

and

while(x == active)
{
do_something;
}

and why did it require creating a new keyword?

 

[Dirk Bruere at Neopax]

And I did consider everything you wrote. Which is why I asked how it
was implemented since as a function, where() would have had to have
been exactly that, a function. Your choice of the word "construct"
keyed me into that. Strictly speaking, "while" is a keyword, not a
construct or a function call.

Now, what's the difference between

where(x == active)
{
do_something;
}

and

while(x == active)
{
do_something;
}

and why did it require creating a new keyword?

I assume it means:
"where processor x is active, execute this code on processor x"

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org

 

[[email protected]]

current methodology is called "UML", for "Universal Modeling Language".
While the "Universal" is more of a comment on the narrow-mindedness of

"Universal" is meant in the sense of "impractically large and unwieldy
for any mortal to use". UML is yet another attempt to reduce logical
thinking and structured software design into a point-n-click Lego
exercise.

 

[Baxter]

Too many don't document code correctly - the *why* is extremely important.

 

[Rick]

Too many don't document code correctly - the *why* is extremely

important.


Especially true with the nightmare called LabView...

 

[Adrian Jansen]

A newbie question...

As a computer programmer, I am used to programming without drawing
"design diagrams", "flow charts" and other bullshit. I just start
coding and try to make sure that I have some working prototype most of
the time, and that I do things nicely. Usually things work out okay
and programs do their job quietly, as intended.

Not doing too much "design" also helps when the purpose of the program
is not quite known from the beginning, as it usually happens.

I find it very difficult to change this mindset and do any sort of
diagram drawings or some such when it comes to electrics or
electronics. For example, I put together a pretty intricate phase
converter in the last month, for instance, with two motors, some turn
on logic, blah blah. That seemed to work.

What I am worried about is that if I try to do something involving more
than say 20 wires, I would run into a wall and that electronics is not
the same as computer programming.

So, I am curious if anyone can relate and tell me either just how
mandatory drawing is, and how to get accustomed to it, or how they
make things without detailed plans.

i

Two comments:

1:
Sure you can do simple stuff without circuit diagrams, but you give up a
*lot* when you come to lay out a PCB, without a schematic to check it
against. And tools to do that are part of every good design system now.
Why go back to doing all that mindless checking by hand ?

2:
"Now I have this really great system with the 1000 ton hydraulic press
controlled by this here micro. See, I toggle this line on in software,
and the press ram moves. And I have a limit switch sensed on this line
here, and when it goes low, the software switches off the ram motor ....
or was it maybe this other line high?...."

--
Regards,

Adrian Jansen adrianjansen at internode dot on dot net
Design Engineer J & K Micro Systems
Microcomputer solutions for industrial control
Note reply address is invalid, convert address above to machine form.

 

[Rich Grise]

Jim Thompson wrote:
(snip)

There is no one more bull headed than a person who has a method that
both fits how their mind works, and gets the job done. ;-)

I had to argue with a professor, once, because the assignment was
supposed to illustrate a weakness of a particular numerical method for
solving simultaneous equations. I don't enjoy failure, so I designed
a little add-on to the program, that eliminated the weakness, and
solved the troublesome equations. For some reason, he didn't like it
that I got answers. I thought I deserved an A for understanding the
problem well enough to solve it. He wanted to give me a D for not
following the directions, exactly.

I can one-up this one. I was on a temp job, doing "document coding", which
is pretty much data entry by a whole roomful of grunts. But, they found
out that I had computer skills, so they let me take a look at this
database software. It was called "Paradox", and the way it worked was
that all of the coders (the grunts at the PCs which are acting like
dumb terminals) were editing one huge database file by way of one
invocation of the program on "The Server". Coders were typing stuff
into the entry blanks on their data entry forms, and having to wait
a distressingly long time, like full seconds, just to see what they'd
typed get echoed. I rewrote their software in about a week - it was really
simple to do - and just as I was about to present it, they stopped me, and
the next day the temp agency called and said that they didn't need me any
more. I think they were frightened because a guy who was working for eight
bucks an hour showed up a team of three multi-big-buck college boy
"programmers", and solved a problem that their incompetence had put into
place.

As far as I know, they're still using the same stupid broken software,
ass-u-me-ing they're still in business.

Thanks,
Rich

 

[Rich Grise]

Jim Thompson wrote: .... ....
Interestingly enough folks have been trying to find structured ways to
do this with software for decades, with moderate to good success.

It's butt-ass simple.

Write down on a piece of paper what it is you're trying to accomplish.

That pretty much is it; from there it's just connecting the dots.

Cheers!
Rich

 

[John Larkin]

A newbie question...

As a computer programmer, I am used to programming without drawing
"design diagrams", "flow charts" and other bullshit. I just start
coding and try to make sure that I have some working prototype most of
the time, and that I do things nicely. Usually things work out okay
and programs do their job quietly, as intended.

Not doing too much "design" also helps when the purpose of the program
is not quite known from the beginning, as it usually happens.

I find it very difficult to change this mindset and do any sort of
diagram drawings or some such when it comes to electrics or
electronics. For example, I put together a pretty intricate phase
converter in the last month, for instance, with two motors, some turn
on logic, blah blah. That seemed to work.

What I am worried about is that if I try to do something involving more
than say 20 wires, I would run into a wall and that electronics is not
the same as computer programming.

So, I am curious if anyone can relate and tell me either just how
mandatory drawing is, and how to get accustomed to it, or how they
make things without detailed plans.

i

It depends on how your head works. If you can keep complex structures
organized in your head, and keep them intact over time and through
interruptions, fine. I can't, so I draw block diagrams of hardware and
software designs early-on. The hardware block diagram (along with a
table of contents) becomes Sheet 1 of all my non-trivial schematics.

For software, the block diagram eventually becomes comments within the
code (which has a table of contents, too!) so is not presistant. Where
I really need the diagrams is for data structures, not for code flow,
which is usually easy to keep track of mentally. An embedded product
may have a VME register file, a per-channel dynamic parameters table,
a per-channel nonvolatile calibration table, a shared range/transducer
types definition table, thermocouple and RTD lookup tables,
miscellaneous little decode tables, some in ram and some in eprom and
some in esquare, with live and static pointers and flags all over the
place.

I draw them all on d-size vellum, with a Berol F pencil.

John

 

[John Larkin]

Thanks. What you say makes sense. Yes, there is a difference between
at least some kinds of software and circuits.

Software can be fixed in minutes. A complex multilayer PC board has a
recycle time of weeks at best, and a custom IC turns in months,
sometimes for megabucks. I've observed that the levels of care and
documentation are inverse with the ease of kluging.

Software pretty much never works the first time it's fired up. Good
hardware designs do.

John

 

[John Larkin]

I think that you both have a good point and at the same time got
carried away a little.

In real life, it is often unknown just what the end result _should_
be. And if people think that they know, they are usually wrong.

I often don't know what a product will really do when I begin
designing it. The first thing I do is write the manual, to see if the
whole thing makes sense. We often send the manual to potential
customers and get their ideas and reactions, too.

Then we usually design bottom-up.

*Then* we (usually) know what we're doing and pretend to do a final
pass top-down, tweaking all the first-cut hardware and software blocks
to look and play nice together. If it doesn't fit on the pc board
nicely, or the parts have 86 week delivery, go back to step 41C.

Anybody who claims that design is an orderly process isn't being
challenged enough.

John

 

[Puckdropper]

*snip*

It's butt-ass simple.

Write down on a piece of paper what it is you're trying to accomplish.

That pretty much is it; from there it's just connecting the dots.

Cheers!
Rich

Maybe a few notes of *how* you intend to accomplish it... before you
forget.

Puckdropper
--
www.uncreativelabs.net

Old computers are getting to be a lost art. Here at Uncreative Labs, we
still enjoy using the old computers. Sometimes we want to see how far a
particular system can go, other times we use a stock system to remind
ourselves of what we once had.

To email me directly, send a message to puckdropper (at) fastmail.fm

 

[Mike Young]

What I am worried about is that if I try to do something involving more
than say 20 wires, I would run into a wall and that electronics is not
the same as computer programming.

So, I am curious if anyone can relate and tell me either just how
mandatory drawing is, and how to get accustomed to it, or how they
make things without detailed plans.

A simple answer trivializes both. So I'll trivialize... Prototyping in both
can be quite similar. It doesn't matter much whether you start by
diagramming, or diagram by coding class heirarchies. Likewise, maybe it
doesn't matter so much if you start by slapping a few ICs onto a breadboard.
I find it easier to start with the schematic, if only to keep from having to
count pins more than once.

Moving the prototype to production or finished product is vastly different.
You can't just scan or xerox your breadboard to reproduce or version it.
With software, just keeping the redundant copies or old versions under
control can be a problem. For both, the task is trivial when the prototype
is the finished product.

There are a lot of other similiarities and differences. Both make use of
recurring patterns (eg. Colpitts; envelope; h-bridge; observer). Many times,
it's a matter of simple plumbing, connecting commode A to sewer B, and
matching impedances along the way.

I can go on, but don't see a need. Simple problems have simple solutions.
Simple solutions don't require much thinking or planning. By extension,
complex problems have complex solutions, and require more thought and more
planning. At some threshold, you have to start scribbling down details to
keep track of them, if only to avoid answering the same questions over and
over again.

I arrive now at the inescapable conclusion that breadboarding even a small
circuit is not at all like building software. With software, I can just pop
over to the header and check the semantics of a function call. The reference
material is all right where I'm working: sitting at the keyboard.
Diagramming a circuit can be the same, only simpler, because even crappy
tools will keep track of which pin is what. What are my choices when I'm
hunched over a breadboard?

Take a look at Eagle http://www.cadsoftusa.com/. The free version will meet
your needs for quite a while, I think. You can even layout a double-sided
PCB if you want to take things beyond breadboarding.

 

[Frithiof Andreas Jensen]

That is indeed how it is done in real life - we use large whiteboards ...
and coloured pens ;-)


When arguing wiht academics you must always call upon Higher Beings - err.
references - such as Jourdon f.ex. who has written USD 150 book about how to
draw block diagrams and state machines when designing software. Just arguing
that something works is plebeian. ;-)

Interestingly enough folks have been trying to find structured ways to
do this with software for decades, with moderate to good success. The
current methodology is called "UML", for "Universal Modeling Language".
While the "Universal" is more of a comment on the narrow-mindedness of
the software engineering world than on the applicability of UML for
anything but software, it is a very handy conceptual tool.

It provides, among other things, a very powerful block diagramming
language tailored to designing object-oriented software applications.

Bletch, Ack, Blaaaarghhhh <cough, cough>

UML is yet-another-attempt at turning a task that is hard to understand and
execute into coloured Lego bricks that can be drawn by managers and handed
over to disposable code-monkeys in India!!

The UML is, in most cases, something that is done by a reverse engineering
tool *after* the design is implemented because the *customer* wants it, not
because the *designers* needed it (if they did need it, there was probably
too many layers of redirection and obfuscation* in the way of The Job anyway
;-)

Discalimer:

Of course Rose Realtime can be used to advantage if one *must* use a large
amount of C++/Java to avoid too much exposure to the underlying language.

UML sort of works, but like most computer based tools, the notation and the
insistence on all the details up front actually gets in the way of
*thinking* which is the most important task.

*Abstraction - O.O. term for inserting soo many interface layers and glue
code that one forgets what the task was ;-)

 

[John Larkin]

I arrive now at the inescapable conclusion that breadboarding even a small
circuit is not at all like building software. With software, I can just pop
over to the header and check the semantics of a function call. The reference
material is all right where I'm working: sitting at the keyboard.
Diagramming a circuit can be the same, only simpler, because even crappy
tools will keep track of which pin is what. What are my choices when I'm
hunched over a breadboard?

Large circuits are virtually impossible to breadboard... how are you
going to connect a few hundred tiny analog parts to a half-dozen TSOP
and BGA chips? So at some point, you may as well stop fiddling and
start designing, and get the real product right the first time without
wasting your time on prototypes.

And why not design software that way, too?

John