Computer programmers' habits in electronics

Sounds famliar... I set up the occasional computer or piece of software at a place that brokers fruits, and the custom software written for them was done in Delphi, back in the days when a "fast" PC was something like a 100MHz Pentium with 16MB of memory. The guy who wrote the software designed so that every time you performed a query on the database, the contents of the entire database were sucked over to the local PCs (10baseT Ethernet back then) where the search was actually performed. :-(

I never re-wrote the thing (I don't have the skills nor am I particularly interested in learning them), and happily PC performance has scaled much faster than their database size, so these days performing searches only takes some 5-10 seconds. Unfortunately, they now want to work from home with their DSL or even dial-up connections, so it's the exact same problem all over again. The currently proposed solution is using remote desktop software... sheesh...

All of this because some guy didn't have the foresight to spend about 3 seconds thinking about scalability a decade back to reach a conclusion I think most of the techno-nerds around here would have already come up with in high school ...!

---Joel

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

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.

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. ;-)

Bletch, Ack, Blaaaarghhhh

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 ;-)

Yep!!

Someone who likes to ask that question told me of an interviewee who got as far as saying "I think it involves recursion...".

So I wrote a version that did it using recursive function calls and sent it to her. I don't know if I would have gotten the job -- they had already made the mistake of hiring me.

Good thing the PC has a lot of stack space.

For interviewing embedded SW engineers we finally settled on a fairly basic scaling problem. We started with a little story problem that required the interviewee to find the ratio of a couple of numbers and multiply it to a third, then we said "oh, by the way, our floating point library is too slow -- do it with integers". The question usually took about 40 minutes to explore fully, with some folks never getting it and some just glancing at the board and writing down the correct answer.

It's amazing how you can separate the desktop programmers from the embedded engineers with that one.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

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.

On Tue, 20 Dec 2005 20:21:59 -0800, John Larkin wrote: ...

Mine does. :-)

Cheers! Rich

Sure. I never use floating point in embedded stuff.

Who was it that said "If you have to use floating point, you don't understand the problem"?

John

Because it's not C, it's VHDL or Verilog.

Cheers! Rich

I once rewrote a Z-80 stepper motor drive loop so that instead of going, "CLACKETY-CLACKETY-CLACK", it went, "Hmmmmmmmmmmm."

Seeing veeps and CEOs and PHDs and stuff going "Ooh, Aah" is extremely gratifying. :-)

Cheers! Rich

Admit it, Iggy. You're just looking for excuses to get out of doing the grunt work. ;-)

Cheers! Rich

Apparently, Ignoramian!

--
Flap!
The Pig Bladder from Uranus, still waiting for that
hot babe to ask what my favorite planet is. ;-j

When you have so many customers that you can't fill the need, so you take on outside help temporarily to take care of the overflow. You know, like "My cup runneth over", but of work?

I'm kinda looking for some stuff where I could telecommute; I know just enough C and perl to get myself in trouble, and can do hobbyist-level electronics - I used to be able to slap together uC circuits, but I don't really have a proper lab these days.

I'm wondering if I should look around for proofreader work, or does anybody bother to have anything proofread these days?

Thanks, Rich

It was a display problem, where we had a display of a certain known size, and we wanted to plot a line on it that reflected an even-numbered (10, 20, 50, 100, etc.) length. We told them that we wanted a procedure that took the screen size in real-world coordinates, the desired size in real-world coordinates, and the number of pixels in real-world coordinates, and that coughed up the line size in pixels. It actually came from a real product (sometimes we had system pictures in the conference rooms & we could point to the box & say "it's in that there box, as a matter of fact").

If they didn't start that way themselves we'd encourage them to "just do the math" first, and look for how well they did their 8th grade algebra problems.

Once the math was done, and sorted out into something that worked well, we'd say "Oh, that's good, now write the procedure that calculates it". Sometimes the interviewee would have to be encouraged to just do it in floating point with no error handling -- if it looked like they were concerned with side issues because of good programming habits we'd give them extra credit.

Once the function was written then we'd drop the bombshell: "This particular code base doesn't have a functioning floating point library

-- if you try to do any floating point operations the processor will lock up. Please do this with integer arithmetic". Then we'd spend the rest of the time allotted for the question working through issues of truncation, overflow and (for extra credit) rounding.

We probably only saw 10% of the candidates make it through the question

100% unscathed, so we didn't grade on results. Instead we looked for how quickly folks picked up on the concepts being thrown at them and figured out solutions.

Interestingly enough the folks that did the worst at this were the telecom guys. In spite of doing "embedded" software they never had to do math and they _always_ worked with 32-bit machines -- to the point where some of them required convincing that 'int' in C could refer to a

16-bit number, and many had no concept of the notion that a 'long int' is, well, _longer_ than an 'int'.

Probably the most amusing anecdote that came out of this was a guy we hired after he did quite well on The Question. His first task on the job was to embellish a control loop, which he did using floating point. I was called in to figure out why it didn't work, and was able to point out that the code was just too damn slow. When I pointed out that he did so well at The Question he replied that he thought it was just a question -- he didn't realize it was a warning, too.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

The string reversal problem also may test whether the programmer thinks about limit-checking and error handling, unless they choose to reverse it in place (which could be influenced by specifics of the question).

Reminds me of the time I gave a little programming job to a fellow. Other than the GUI (which he did an okay job on), the 'guts' of the task involved coming up with a handful of vectors and doing a few dozen flops. Speed was of no concern. He precalculated every possible value and created a multi-megabyte Access-compatible database. Absolutely grotesque.

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

Well, this PROVES you're not gay, despite your fondness for musicals...

Three-line sieve of Eratosthenes? Do post do post!

It wouldn't happen to be...

int main(void){ DoSieve(); return 0; }

, now, would it?

Hey, try Ketamine! Let us know if there's life (bacterial or other animal) around any of the nearer stars (within 100 light-years)... that is, if you make it back alive, that is...

Something like this? (ugh)

#include

rev2(char * istring, int start, int fin) { char t; t = istring[start]; istring[start] = istring[fin]; istring[fin] = t; start++; fin--; if (fin > start) rev2(istring, start, fin); }

...

/* reverse the string in place */ rev2(mystring, 0, strlen(mystring)-1);

...

Here's one I did to approximate e^(-x) over the range 0 .. 0.75 (the end product would be written in assembler**, the C is just to explain).

--
where xf, yf are 32-bit integers. 

  xf = x * 128; 	
  yf = 32768 - xf  + (xf* xf)/65536 - (((xf * xf)/32768
)*xf)/(6*32768) + (((xf*xf)/32768)* ((xf*xf)/32768))/(32768 * 24) 
   - (((((xf*xf)/32768)* ((xf*xf)/32768))/32768) * xf)/(32768 * 120)
;

The result is ~= exp(-x/256) * 32768 over the range 
x = 1 to 192. 

yf/32768 agrees with exp(-x/256) within 0.001 over that range. 


You can easily extend this to additional terms, although it gets a bit
tedious. 

It\'s based on the textbook Taylor/Maclaurin series 
           
           infinity
           ---
           \\
exp(x) =    >  (x^n)/n! 
           /
           ---
          n= 0 


** actually assembler macros, but that\'s another story

The code should be self-documenting, the comments should tell something (like the "why") that the code does not tell.

--

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

Data Collectors

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

important.

Like an in-line assembler/disassembler to interface with a ROM simulator?

;-)

Cheers! Rich

YGBSM.

OK, since it's a job app, lessee what I can come up with.

Um, do you want me to reverse it in place, or to create a reversed copy on the heap?

Thanks, Rich