cool article, interesting quote

helps).

You don't use libraries, macro or otherwise?

Yet another incompatible programming language, perhaps someone's PHd thesis.

No issue with that.

No disagreement here either. My point is that abstraction is a useful tool, particularly in the cases I mentioned.

--
  Keith

Ah, that old myth again ;).

Linked to that article is this one:

Which is germane to this thread ("Why are you still using C?"). The author promotes C++ because of OO. The point of OO is encapsulation and decoupling - i.e. good modularity - which is good. But this is all achievable in C (and is how I do things). The author says yes, but "C does little to promote this behaviour". Well, yes, but C or assembler or $language does little to promote any kind of behaviour (it has a GOTO, remember?). My point is - again - that good software design is the key issue. Coding is coding. I'd argue that C++ most often promotes inappropriate behaviour, but hey... the right tool in the right hands again.

To go back to the complexity issue: if modules are sufficiently well decoupled, the exponential law myth breaks down - the probability of bugs is equal to that in the weakest module. I strongly take issue with the idea that complexity is an argument for justifying bugs. It's an argument for good decomposition and good modularity - period. EEs take this for granted. Why do we have so much trouble with it??

Heh - won't argue with that one. Except to say "see above" ;).

Steve

If all they have is the degree, most produce crap in any language.

--
Al Balmer
Sun City, AZ

Even in circuits as well ;-)

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
         Old Latin teachers never die...they just decline

I once saw a 32V, 10A 3AG (automotive) fuse blow the holder cap half-way across a factory floor when it blew on a 240VAC circuit. =:-O

I gave a little safety lecture on why fuses have a voltage rating. :-)

Cheers! Rich

A few hours soldering and you'll make a few hundred joints, each of which you can test to destruction.

A four-year CS degree, and you'll write one complete program, which won't be properly tested.

Frankly, as someone who did the Cambridge Dip.C.S., I don't see how you can take more than one or two years to teach CS.

As an aside: we deal with interns from engineering and programming courses, either over the summer or doing a one-year placement. There are universities where it is possible to do two years of engineering and never go into a workshop. I regard CS degrees in similar light; unless the student actually designs, implements, tests, *and maintains* something, they haven't learnt much.

cheers, Rich.

--
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   |
need a Hand?           London  N1 1LX       | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml

Gains of 10 or 20 to 1 are easy, 100:1 harder. They depend almost solely on the ratio of emitter areas. Saturation voltage isn't the problem, but power dissipation is, since that occurs in the output collector circuit.

--
I hear the voices.    G W Bush, 2006-04-18

Use a P-channel PowerMOS with a small resistor in the source, then an OpAmp to set the current source amount.

It'll be "saturated" until the load tries to exceed the source value, then it will collapse.

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
         Old Latin teachers never die...they just decline

No. I do sometimes cut and paste text from other source files, or more likely start with source from an existing project, to get the uP register definitions and init code, the FPGA loaders, and maybe some basic structure to work from.

All the embedded stuff I do is absolute assembly of a single source file. We wrote a little rom-builder thing that combines the absolute assembler output (S28 format) with one or more Xilinx config files (.RBTs), which is as close to a linker as we get.

Really, it just works! A typical embedded project will involve 4-6 kloc and take 2-3 weeks to design, code, test, release. Bugs are rare, crash-type bugs unheard of.

Thought: the average company hires average programmers, pays average salaries, and gets risky, often horrible results. A truly good programmer is 10x as productive as average and most always delivers working, bug-free code. So a smart company would hire the good person, pay him/her exhorbitantly, and provide lots of support to maximize utility. Support would include the software equivalent of techs, beginners (maybe college CS grads? or is that a disqualification?) who would do the scut work, testing and cleaning up documentation and fetching expresso drinks, who someday may be allowed to write a little code themselves if they look capable.

Is there any such thing as a software tech?

Gotta go solder some LEDs.

John

Ah, I see. Small stuff. I understand your defence of your approach better now. I typically work on far larger projects, with timescales which are

*not* far larger ;). (Some examples at - a bit incomplete...) My earlier comments should be seen in that light.

Steve

Many embedded applications simply do not take more than what John says he does, so this approach is obviously practical for him. I also use old similar files for templates (who does not..), but I also do use libraries, system calls etc. whenever needed (in my main product line, they are needed everywhere as it is pretty huge - but well organized and I can tell you it really helps to have everything under control and not rely on other people's code - once you have all you need :-). I agree with you that bad code can be written in any language, but this is not valid about good code (I don't mean C). Among the high-level languages, C is the best simply because it is the lowest level of them all (and thus most flexible). It also is better than most assemblers because they are either non-portable or are defined by some awkward architecture (Intel comes to mind) or simply are too low level (PPC native assembly). I hope sooner rather than later I will be able to make public the DPS and VPA environment, it does deal with these issues in I believe the most obvious way, I hope other people will like it. Like you mentioned, object oriented coding can be done - no need to enforce it by making the language unusable for anything else. As a matter of fact, much of the code I have is written using the in-built DPS object handling system (the tcp/ip subsystem comes to mind). In general, I agree with both you and John that it is the guy at the keyboard who does the programming and not the compiler tools... How long do we have until we follow the blacksmiths? No idea. I guess it will be when all coding can be done as easily as using a web browser and there can be no alternative to that which delivers times (perhaps many times) more efficient code.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

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

Steve at fivetrees wrote:

I'm sorry, I don't believe this will happen.

The process of s/w design is a process of formalising the intended behaviour of the system. Now, we can argue until the cows come home about the best ways of doing that. Certainly some things can be generalised and automated - deriving a comms or file parser from a formal spec of the protocol is perhaps one example (although creating a truely formal spec can be hard enough). But unless and until we come up with a better way of fully defining the system behaviour down to the last detail and which can be fed as input into a supercompiler, we design s/w. By hand and by brain.

I believe the real skill lies in generating the system architecture, if you like - analysing the problem to find the generalities and the exceptions and getting a clear picture of how it all hangs together (now and in future). Then comes the decomposition and modularisation I keep banging on about, including the definition of the interfaces between the various elements of the overall system. (And finally the coding.) This is not something I expect to see mechanised. Partially, perhaps. Fully, no.

Of course, we could have a total paradigm shift - replicable neural quantum machines, anyone? (Although then they'd rebel and become our new overlords...)

Steve

But I completely agree with all that.

This is more or less what I expect to happen. Machines will become intelligent enough so we can explain - interactively - in plain English

what we want and they will eventually do the job. If they agree to, that is :-). A consequence of that development might well be the obsolescence of humans...unless it is possible to design them not too smart (seems possible, I am not sure whether we can stop there, actually I think we can't). Well, I am not saying I expect this soon enough so we carbon based creatures need not be worried for the time being... :-).

Now I switch back to normal coding (got tired of debugging but the machine said it won't do it on its own so I have to get back in wrestling mode again...:-)

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

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

Steve at fivetrees wrote:

Yes thats the stuff. You can get it in purer form at the lab supply house.

--
--
kensmith@rahul.net   forging knowledge

Here's a recent project of ours:

As you can see, we're very close to the hardware here. We'll typically run interrupt rates of 1 to as high as 10 KHz, and run some fairly hairy state machines and snippet dispatchers every interrupt. Since we're so close to the hardware, and since I'm an engineer, programming in assembly suits.

This was also programmed in assembly, and arguably shouldn't have been:

At something like 14 klines and lots going on, it got a bit hairy. We used an Xport module for the ethernet option. Once TCP/IP stacks get involved internally, I concede the language debate.

John

Would using a high-level language have allowed it to display lower case? :-)

You could still program the parts you want to in assembly and just link in the TCP/IP, GUI or whatever HLL code. Particularly for the ISRs. It's more like an analog or fuzzy variable rather than a binary choice.

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

Heh - temperature measurement and control is a big part of my background too. Back in the mists of time I was project leader at West Instruments, and was the daddy of the 3000 series of self-tuners:

[Blimey - they seem to be holding their value well!]

Also did some work for Eurotherm, if you know them.

With the Xport as an ethernet-serial converter, I imagine? We found it a bit tough to use any other way.

The stuff I'm working on right now does indeed include TCP/IP. Done right, it's a decent example of abstraction ;).

FWIW: most of what I do is also close to the hardware (I started out as a pure hardware guy). I frequently do use assembler too. But I still design in a higher-level language (C these days, but I used to use pseudo-code - I just *hate* flowcharts and other hard-to-maintain graphical approaches) and then hand-compile.

Steve

The Help system is upper/lowercase, and has hyperjumps.

John