Computer programmers' habits in electronics

--

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

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

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.

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

"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.

I am employed, I have been programming for money for 13 years or so. (not counting the gigs I had as a student).

Yes, if I am hired to design stuff, I better produce design, sure.

i

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

Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

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

--

--------------------------------------------------------------------- DataGet® & PocketLog®

Data Collectors

--------------------------------------------------------------------

It depends. I normally start by writing all the drivers that will actually interface with bits of hardware. That doesn't really take much 'design' in the normal sense of the word, but it gives me something to flash lights with.

Then I start at the top end and sketch out what classes/functions I need to get down to driver level.

Right now I'm into a control system being written in C++. It will probably top

3000 lines when complete, but I still do not need a formal design methodology.

I have spent a great deal of time on the control protocol that interfaces with a PC. That determines the data structures and hence classes. It's all quite straightforward.

Now, if I was having to collaborate on a bigger prog then formal methods would probably be indispensible.

--
Dirk

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

of

get

a

Not necessarily, if you have good programmers to work with, you can agree on who writes what libraries and in approximately what ways.

i

of

get

a

The biggest programming job I have worked on was one that topped (I estimate)

30,000 lines. There were two of us on that, and we needed only informal get-togethers to split the tasks reasonably smoothly.

Of course, what makes the job I am currently working on even easier is that I'm designing the h/w along with the s/w. However, I *will* be using circuit diagrams!

--
Dirk

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

That's the situation I'm in right now. There is a lot of pressure to get a working prototype. Bugs can be fixed and documentation done later. Getting money in comes first.

--
Dirk

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

of

get

top

with a

would

Sounds quite sensible. Judicious use of interprocess communications protocols often help seperate "the task" into smaller separate pieces.

There are many consultant gurus going around inventing methodologies, selling books etc, whereas what is mostly needed is having good programmers, attention to details and separation of tasks between both people and code.

A quick check suggests that I wrote about 50k lines of code here at work. Automatically generated lines are not counted.

I am not saying that documentation or design are never needed. Surely, sometimes they are. But not as often as it is suggested. Stacks of papers are not really a substitute for well written code.

i

I'm

diagrams!

>

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

There are many problems with documentation, the main one is that it is usually out of date or wrong. It is nice to have it, though, when it is correct and well written.

i

a

Depends what you mean by documentation. I document the code with plenty of comments because I know that I will likely have to return to it in a year or two when I've forgotten everything. Any 'real' documentation can wait.

--
Dirk

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

Would you agree if I replaced "lack of documentation" with "not understandable software"? I agree that stuff that is written in a manner that is hard to understand, needs at least documentation, although I feel that it is better to rewrite it.

In many, if not most, instances, there is a way to write code that is basically very self explanatory or needs just a fewe comments on top and some sprinkled in.

i

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.

But you could find out by starting out...

Absolutely true.

I never built a house, but I built a shed this way, it stands and is very functional. A house is a perfect example of where such an haphazard approach would not work, for many reasons. We do know however, that many houses have all sorts of issues even though they were designed.

We are not living in a simple world.

i

I am sorry, what is overflow work.

i

On Tue, 20 Dec 2005 11:19:01 -0700, in sci.electronics.design Jim Thompson wrote: snip

Woohoo, Nice one Jim

martin