Computer programmers' habits in electronics

I am very much for adding comments to the code. It is always very helpful as

1) the documentation is where they belong semantically 2) they are more likely to be kept up to date 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

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

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

That often happens indeed.

Yes, especialy if it is packaged into a nice callable function, class, or whatever. (encapsulated)

Indeed I am a complete newbie to electronics.

Very well said.

Yes. Plus, what's 29,970 bytes these days.

Which is definitely a good practice when it comes to programming.

Looks cute.

Yes, indeed splitting stuff into blocks works well.

Of all my college classes, I liked calculus the best.

i

C++ and perl.

i

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.

Well, I am not trying to get into this professionally. Computer programming is better for me anyway. I just need some electronic pieces from time to time, that's as far as I am willing to go.

i

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

...

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

LMFAO

I've always thought that in electronics:

- the requirements document and specification is the design document

- the schematic is the source code

- the physical circuit is the binary executable

Sometimes you are the compiler converting the schematic to circuit. Sometimes a CAD program is the compiler and creates the circuit for you out of the schematic (you may still need to do placement).

What you're doing is not the same as ad-hoc coding, what you're doing is opening up a hex editor to manually create/edit a binary executable without the benifit of a compiler or assembler (I've actually had to edit binary executables in this fashion before).

The electronics equivalent of ad-hoc coding is ad-hoc schematic drawing (which I do often) without first working out all the equations (do we even know that this may not be doable by this specific circuit?) and assume all resistors are either 1k or 4.7k (usually works for digital circuits).

I've been taught that "WHY" is the only thing you really need to write comments and documents on. Maybe the "WHAT" as well if it is not clear. The "HOW" is often self-explanatory. Unfortunately a lot of people comment on "HOW" the code works instead of "WHY" it was written that way. In my experience, misinterpreting the "WHY" inevitably leads to bugs - often in seemingly unrelated code, in a different process, on another CPU.

Theres a big difference between self explanatory to you who wrote it, now, and someone else used to doing things differently working on it in

5 years. What is obvious to one tends to be a real mystery to the other. Not fully appreciating the magnitude of this is one of the problems of being a geek, for me anyway.

NT

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?

For each processor where x evaluates true, do something. For those processors where x evaluates false, do no-ops until end of statement. Note that this is a parallel 'if' statement,

On all processors, do something, but loop. The where statement is not a loop.

The where keyword (which was added for the parallel compiler we used) permits the evaluation of a variable on a per processor basis. Very useful in sending data streams or error messages, amongst many other things

for instance

where (PROCNUM == 0) { printf("Some error message"); }

prints one instance of the error message (from processor 0), while

if(error) printf("Some error message"); causes all processors to print an error message, which gets a little untidy ;)

Cheers

PeteS

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

important.

Especially true with the nightmare called LabView...

-

wrote in

write

this...

Rich Grise wrote in news: snipped-for-privacy@doubleclick.net:

*snip*

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