Maker Pro
Maker Pro

Programming for Electronics Engineers

J

John Larkin

I'll probably regret this, but since you guys are so adamant in your
dislike of 'C', what would you recommend as a replacement? N.B. if you
amswer Visual Basic, I'm writing you out of the will.

Since this thread is "programming for electronics engineers" and not
"programming for people who don't have anything else to do" I nominate
the various versions of PowerBasic.

Programming is a tool and a nuisance for me, so when I do have a
problem that requires software, I want to get it over as quickly and
cleanly as possible so I can move on to get more real work done. A
"professional" programmer will of course have different goals, since
he faces a lifetime of more of the same.

John
 
B

Bob Stephens

Since this thread is "programming for electronics engineers" and not
"programming for people who don't have anything else to do" I nominate
the various versions of PowerBasic.

Programming is a tool and a nuisance for me, so when I do have a
problem that requires software, I want to get it over as quickly and
cleanly as possible so I can move on to get more real work done. A
"professional" programmer will of course have different goals, since
he faces a lifetime of more of the same.

John

Well, I consider myself to be an electronics engineer who programs rather
than a programmer who tinkers with hardware. As such, my concept of
"programming for electronics engineers" is an environment that allows me to
get at the hardware directly without a lot of abstraction. Originally that
was machine language and assembly. For this type of programming, 'C' was
and is a Godsend. It allows the programmer to dial in the balance of
granularity vs. abstraction required for a given task. All the high level
constructs of Basic or FORTRAN etc. seamlessly integrated with register
level bit twiddling capability - including in line assembler - in the same
environment. C++ on the other hand is an entirely different matter. ;)


Bob
 
K

Keith Williams

I'll probably regret this, but since you guys are so adamant in your
dislike of 'C', what would you recommend as a replacement? N.B. if you
amswer Visual Basic, I'm writing you out of the will.

Me? The last time I used BASIC was some 20 years ago when Tektronix
had a very nice version in their Signal Processing Systems (built-in
FFT, RFFT, Convolution, Correlation, etc.). As far as programming
languages go (thus ignoring VHDL), I much preferred PL/I and thought
Pascal was tolerable (other than its lack of I/O). Pretty much all the
programming I've done in the past 20 years has been in assembler. I'm
a hardware type and most of the programming I do is bit-banging on the
metal, thus the choice of assembler.

I've also mentioned that I've used Excel (the only product from M$ that
has a reason to live) for some rather interesting things too. There's
more power in there than most realize.
 
B

Bob Stephens

Me? The last time I used BASIC was some 20 years ago when Tektronix
had a very nice version in their Signal Processing Systems (built-in
FFT, RFFT, Convolution, Correlation, etc.). As far as programming
languages go (thus ignoring VHDL), I much preferred PL/I and thought
Pascal was tolerable (other than its lack of I/O). Pretty much all the
programming I've done in the past 20 years has been in assembler. I'm
a hardware type and most of the programming I do is bit-banging on the
metal, thus the choice of assembler.
I agree with you in principle, but Lordy, 'C' has saved me thousands of
hours of effort doing loops, conditionals, string manipulation etc. over
straight assembler.
I've also mentioned that I've used Excel (the only product from M$ that
has a reason to live) for some rather interesting things too. There's
more power in there than most realize.

Care to elaborate?


Bob
 
R

Richard Henry

Bob Stephens said:
Well, I consider myself to be an electronics engineer who programs rather
than a programmer who tinkers with hardware. As such, my concept of
"programming for electronics engineers" is an environment that allows me to
get at the hardware directly without a lot of abstraction. Originally that
was machine language and assembly. For this type of programming, 'C' was
and is a Godsend. It allows the programmer to dial in the balance of
granularity vs. abstraction required for a given task. All the high level
constructs of Basic or FORTRAN etc. seamlessly integrated with register
level bit twiddling capability - including in line assembler - in the same
environment. C++ on the other hand is an entirely different matter. ;)

I'm pretty much in the same boat. Although I have a degree in CS, I
consider myself a hardware enginer.

Recently I downloaded Microchip's USB support software. Ack! Lots of files
that begin with IFNDEF, define a few objects, and then don't DO anything.
Looks like they hired a CS PhD.
 
G

Guy Macon

Bob said:
I'll probably regret this, but since you guys are so adamant in your
dislike of 'C', what would you recommend as a replacement? N.B. if you
answer Visual Basic, I'm writing you out of the will.

For the EE who also wishes to be a Linux guru, GCC/ANSI C++

For the EE who wishes to program small/cheap 8-bit chips, Assemby.

For the EE who wishes to program small/cheap 8-bit chips and wishes
to be able to outperform coworkers who are using assembly, Forth.

For the EE who uses Windows and just wants to be able to write
fast, bug-free programs to do calculations and access the PC
hardware for data aquisition, etc,, PowerBASIC Console Compiler.

Same as above but DOS user, PowerBASIC for DOS.
 
K

Keith Williams

I agree with you in principle, but Lordy, 'C' has saved me thousands of
hours of effort doing loops, conditionals, string manipulation etc. over
straight assembler.

I don't see these things (with the possible exception of strings) as
being all that difficult in assembler. One tends to do things the same
way each time. When I was doing a lot of MASM I had a toolbox of
macros for strings (and other similar functions) when I had to go
there. The big difference between assembler and HLLs that I could see
was in the eye-candy and computations. I didn't see any advantage for
bit-banging. IMO, assembler is much clearer here.
Care to elaborate?

I've used it for a lot of things, from the normal spreadsheet sorts of
things, to logic simulation and demonstration, to some fairly complex
functions. Someone once wanted a demonstration of ECC, so I coded up
and example (using an SDRAM interface as an example) in a few minutes.
We've done simulations of asynchronous logic with a spreadsheet. Get
one black-box done and block-copy multiple levels. Change a bit and
see the result.

Then there are the obvious spreadsheet type functions. Last year I had
to capture logic verification patterns to be used as input to a circuit
simulator. To do this I had to track the entity declarations of the
circuit's black-box back through several levels of hierarchy to the
signals driving them and generate pin-lists for the capture software.
Formatting the pinlists was a freebie (do it once and copy/paste) once
the signals were traced. As another freebie I output the pinlists for
the waveform viewing tool so we could see what patterns we were
capturing. Not any great shakes here, but all the formatting was
essentially free.

There are also functions buried in there that are quite useful to an
engineer (e.g. FFT).
 
J

John Larkin

Well, I consider myself to be an electronics engineer who programs rather
than a programmer who tinkers with hardware. As such, my concept of
"programming for electronics engineers" is an environment that allows me to
get at the hardware directly without a lot of abstraction. Originally that
was machine language and assembly. For this type of programming, 'C' was
and is a Godsend. It allows the programmer to dial in the balance of
granularity vs. abstraction required for a given task. All the high level
constructs of Basic or FORTRAN etc. seamlessly integrated with register
level bit twiddling capability - including in line assembler - in the same
environment. C++ on the other hand is an entirely different matter. ;)

I agree entirely, but I just prefer PowerBasic, for its readability,
its inherent (as opposed to external) functions, its graphics, and
PRINT USING. It's got peek/poke/in/out, inline assembly, bios call
capability, interrupt hooks, a jillion variable types (including
64-bit ints and 80-bit floats), locate array AT a hard address, bit
operators, all that stuff. On my creaky old 700 MHz Dell, it can run a
FOR loop at something like 20 MHz.

The PBCC version has cool stuff like TCP OPEN; makes Ethernet a snap.

John
 
J

John Larkin

I agree with you in principle, but Lordy, 'C' has saved me thousands of
hours of effort doing loops, conditionals, string manipulation etc. over
straight assembler.

In real embedded stuff, I don't think the language matters that much.
I recently spent a couple hours writing a driver (68K assembly) that
would handle various Maxim serial dacs, and spent most of that time
trying to deceipher cryptic timing diagrams and command sets on
datasheets. When it takes a half hour to decide which bit to set in
which register, language doesn't matter. Good commenting matters.

Serial dacs are the spawn of the Devil; no two are alike. One Maxim
part uses the clock rising edge, another uses the falling. I've got
over 300 dacs in this one gadget, and the driver table just to do dac
wakeups is three pages.

Assembly does allow one to build very pretty table structures. I guess
C could, too, but most of the static (loaded at compile-time)
structures I see in C programs are just jumbles.

John
 
J

James Meyer

For the EE who wishes to program small/cheap 8-bit chips and wishes
to be able to outperform coworkers who are using assembly, Forth.

From what I see at work, I could use FORTH to outperform cow-orkers
using C/C++.

Jim
 
W

Winfield Hill

James Meyer wrote...
Guy Macon wrote,


From what I see at work, I could use FORTH to outperform co-workers
using C/C++.

Aha, two Forth fans!
 
K

keith

Well, admittedly, the "300" was a modicum of hyperbole on my part. I've
since been enlightened, since (I don't remember who) posted that, "Yes,
anyone can learn to read APL - it's only impossible to read it _aloud_.

;-)

As long as we're in fill discalaimer mode... I now remember the golf-ball
backing up to do over-strikes, so some characters needed three symbols
transmitted. And they didn't all fit on the ball as unique characters.
Hey, it's only been 20 years since I've touched APL! ;-)
 
K

keith

Since this thread is "programming for electronics engineers" and not
"programming for people who don't have anything else to do" I nominate
the various versions of PowerBasic.

I've done BASIC, but I wasn't real happy doing it. Like I said in another
subthread, I did like the Tektronix SPS basic, because it had the concept
of a "waveform" and EE type functions built in. That was an EE language!
Programming is a tool and a nuisance for me,

You're kind. I hate programming, other than the widget I'm developing. I
hate programming general-purpose stuff.
when I do have a problem
that requires software, I want to get it over as quickly and cleanly as
possible so I can move on to get more real work done.

Sure. I haven't found that I need to do a lot of "programming" though.
Spreadsheets cover most of the ancillary crap I have to do.
"professional" programmer will of course have different goals, since he
faces a lifetime of more of the same.

Sure, they buy hardware that "works" too. Their job isn't to get it to
work.
 
J

John Larkin

For the EE who uses Windows and just wants to be able to write
fast, bug-free programs to do calculations and access the PC
hardware for data aquisition, etc,, PowerBASIC Console Compiler.

I use the dos version a lot, mostly for the graphics. PBCC doesn't
have graphics... do you use one of the add-ons? How is it?

I think I have GraphicTools around here somewhere...

John
 
K

keith

In real embedded stuff, I don't think the language matters that much.
I recently spent a couple hours writing a driver (68K assembly) that
would handle various Maxim serial dacs, and spent most of that time
trying to deceipher cryptic timing diagrams and command sets on
datasheets. When it takes a half hour to decide which bit to set in
which register, language doesn't matter. Good commenting matters.

Oh, crap! I didn't go anywhere near Maxim, but NSC's aren't any better.
I spent weeks trying to reconcile their specs with the devices actual
opration. Most of that time was trying to figure out why I was wrong (I
wasn't). If you have to support 'em all, my condolences go out to you! I
only had to get the ones I had working (perhaps two models and a couple of
tens of parts total).
Serial dacs are the spawn of the Devil; no two are alike. One Maxim part
uses the clock rising edge, another uses the falling. I've got over 300
dacs in this one gadget, and the driver table just to do dac wakeups is
three pages.

MAXIM == HELL. I wouldn't use their stuff if I had controlling stock in
the company (I likely still couldn't get parts). Just say *no* to Maxim!
Assembly does allow one to build very pretty table structures. I guess C
could, too, but most of the static (loaded at compile-time) structures I
see in C programs are just jumbles.

I'm a table oriented type too. I rather like jump-tables for embedded
stuff too. It just fits with my state-machine orientation. ...a reason I
like languages with strong CASE type constructs.
 
G

Guy Macon

John said:
I use the dos version a lot, mostly for the graphics. PBCC doesn't
have graphics... do you use one of the add-ons? How is it?

I never use graphics.
 
J

James Meyer

James Meyer wrote...

Aha, two Forth fans!

Did you manually change my "cow-orkers" to "co-workers"? Or did your
mail-reader do it for you? If you could see the nimnals I have to work with,
you'd know why they're cow-orkers instead of co-workers.

As an engineer/designer, FORTH appeals to me in the same way a well
stocked parts cabinet does. If I'm building hardware and I can't find a chip
that does exactly what I want, I can put together some lower level chips to do
the job. No signal generator? A quick Wein bridge from op-amps does it.

FORTH is like a well stocked parts cabnet. If there isn't a word that
does exactly what I want, I can either change one that comes close or throw one
together from scratch. With FORTH, I can know exactly what each and every part
of my program does. I don't waste my time trying to massage an ill fitting
library call that the original author never documented or even tested.

Jim
 
K

keith

From what I see at work, I could use FORTH to outperform cow-orkers
using C/C++.

In what way does FORTH "outperfrom" C/C++? Time to market or processing
speed? Both are obviously important, but I can't imagine FORTH winning
the latter.
 
Top