Programming for Electronics Engineers

[Rich Grise]

On Mon, 17 Jan 2005 16:34:34 -0800, John Larkin wrote:

On Tue, 18 Jan 2005 00:06:42 GMT, Rich Grise <richgrise@example.net
wrote:

On Mon, 17 Jan 2005 21:44:08 +0000, Ken Smith wrote:

In article <1gqjkh3.1lx82l9ruvmaaN%bskb@m.a.c.com>,
Bjarne Bäckström <bskb@m.a.c.com> wrote:
Ken Smith <kensmith@green.rahul.net> wrote:

[...]
write('Q = '); readln(q); { Read in the values }
write('P = '); readln(p);

p := abs(p); { The sign doesn't matter }
q := abs(q);

if (p=0) and (q=0) then halt; { Don't use silly values }

That's BAD user interface!

repeat
flag := true;
write('Q = '); readln(q); { Read in the values }
write('P = '); readln(p);
if (p=0) and (q=0) then { Don't use silly values }
begin
writeln('Illegal value(s)');
writeln;
flag := false
end
until flag { = true } ;

That's worse because it doesn't giver the user an escape if he doesn't
happen to know some good values. In this case it is not much of an issue
but if the restrictions were tighter, this would be a very bad idea.


repeat
flag := true;
write('Q = '); readln(q);
if (q=0) or (q > 10000) then
begin
writeln('Q must be between 0 and 10000');
writeln;
flag := false
end
until flag;

repeat
flag := true;
write('P = '); readln(p);
if (p=0) or (p > 10000) then
begin
writeln('P must be between 0 and 10000');
writeln;
flag := false
end
until flag;


Cheers!
Rich



--


That's a lot of trouble to avoid a coupe of GOTOs. I never understood
the anti-GOTO religion.

I just didn't remember if Pascal had gotos or not. If I'd been allowed to
use "C", I'd just continue;.

Cheers!
Rich

 

[Rich Grise]

On Tue, 18 Jan 2005 02:24:24 +0000, Ken Smith wrote:

In article <uamou0pskrveuib4g9c9m3tiv4dp1st3i7@4ax.com>,
John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote:
[...]
That's a lot of trouble to avoid a coupe of GOTOs. I never understood
the anti-GOTO religion.

Someone said that GOTOs were a bad thing and everyone believed him.

You can take any program that uses GOTOs and rewrite it as one that is
harder to understand without GOTOs. It is so easy that a program to do
the conversion can be written.

It could be simply an overreaction to some of the nightmare spaghetti code
that got written before people learned how to break out of loops. Heck, in
one of the first languages I learned, "For-Train", one very prominent
feature was the "Computed GOTO". That's like, the whole raison d'etre of
stored-program automatic calculating machines. ;-)

Cheers!
Rich

 

[Rich Grise]

On Mon, 17 Jan 2005 23:11:23 -0500, Spehro Pefhany wrote:

On Mon, 17 Jan 2005 19:23:30 -0800, the renowned John Larkin
jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX> wrote:

On Mon, 17 Jan 2005 21:52:11 -0500, Spehro Pefhany
speffSNIP@interlogDOTyou.knowwhat> wrote:

On Mon, 17 Jan 2005 18:42:19 -0800, the renowned John Larkin
jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX> wrote:

What pantywaist languages. Real men don't program in lowercase.
John

Lower case helps even in assembly. The shape of the letters is easier
to distinguish so you can read it more easily.


No. Listings printed on my fanfold dot-matrix printer are much easier
to read in uppercase.

John

I don't think I've printed a full program listing in years- last
fair-sized assembly project I wrote would have been close to 300 pages
single-spaced. Sometimes a few pages (one function, perhaps) in 9 pt
on the laser printer so I can pour over it at lunch. Pore over it,
too.

Well, if you're pouring very expensive cognac, it might be a good idea to
have a high-value doily like a listing. ;-)

Remember the launch pad gag?

When I was about 12, the family would have neighbor families over from
time to time, so the adults could drink and the kids could watch TV or
whatever. Well, I was very fortunate, in that my folks used to let the
kids watch the adults drink.

One time, during the "tell a better joke than the other guy" phase of the
drunk-fest, my Dad (bless his soul) came up with:

"Well, there's been some space shots, and they're very expensive. And one
of the most expensive parts is the launch pad [while giving this patter,
he's taking a cocktail napkin and rolling it into a cylinder] - so, does
anybody have, say, a $20 bill we can lay here, to represent the launch
pad? Great! [he says as someone proffers a 20]. So, this is the missile
[he puts the loosely rolled-up cocktail napkin, maybe 1" cylinder, upright
on the 20]. And they have this countdown, before they fire off the
engines. We're going to represent this by lighting it [ he lights the top
of the cylindrical napkin, as one would light a candle, but it's paper
napkin burning] Ten! Nine! Eight! [and so on - the napkin continues to
burn, from top down, producing well-defined, but very fine, ash] Two! One!"
And the ash and remnant of smouldering paper gets entrained in the
convection, and rises from the "launch pad", as if by magic. EVERYONE
watches the rising napkin ash, and when it finally becomes soot, everyone
looks back at Dad and the $20.00 launch pad, and the $20.00 is gone.

"I don't know what happened to it! Maybe it got burned up!"

Of course, the gag is simple misdirection.

I'm gonna have to try this sometime. %-)

Cheers!
Rich



Cheers! Rich

 

[Guy Macon]

Rich Grise wrote:

Yeah, but where do you get the 300-key keyboard?

Y&ou can use two of these:

http://www.monu-cad.com/keyboard.htm

Or 1/10 of one of these:

http://www.honco.net/japanese/05/caption/caption-1-03.html

 

[Frithiof Andreas Jensen]

"Reg Edwards" <g4fgq.regp@ZZZbtinternet.com> wrote in message
news:cs91ms$1ok$1@titan.btinternet.com...

43 years later, in my opinion, for what it's worth, the salient attribute
of
so-called professional computer programmers is the ability to make vast
amounts of money under false pretences.

.... And this is a Bad Thing?

 

[Frithiof Andreas Jensen]

"John Larkin" <jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX> wrote in
message news:j3alu0l6q9refbdvanl3kv4cgufirlgd1l@4ax.com...

You have to realize that guys like Jim and I are fulltime circuit
designers.
.........
grapher program. Some of the stuff I do is very compute intensive, so
a pig like Visual Basic would be unusable. So what we need is a
simple, quick, easy to learn and easy to use language that runs fast.
And, at least for me, can do hardware i/o without requiring me to
write device drivers.

Python with the 'Numeric' and 'Scientific Python' (numpy & scipy) packages
should do you then!

Python have all the OO constructs, classes and whatnot too - AND you do not
have to use any of it either, if you do not want too!

I *like* Python ;-)

 

[Keith Williams]

In article <5u5pu05pgmm4ga9imgmnpd9v6pgg71oql7@4ax.com>,
jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX says...

On Mon, 17 Jan 2005 23:11:23 -0500, Spehro Pefhany
speffSNIP@interlogDOTyou.knowwhat> wrote:

On Mon, 17 Jan 2005 19:23:30 -0800, the renowned John Larkin
jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX> wrote:

On Mon, 17 Jan 2005 21:52:11 -0500, Spehro Pefhany
speffSNIP@interlogDOTyou.knowwhat> wrote:

On Mon, 17 Jan 2005 18:42:19 -0800, the renowned John Larkin
jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX> wrote:

What pantywaist languages. Real men don't program in lowercase.
John

Lower case helps even in assembly. The shape of the letters is easier
to distinguish so you can read it more easily.


No. Listings printed on my fanfold dot-matrix printer are much easier
to read in uppercase.

John

I don't think I've printed a full program listing in years- last
fair-sized assembly project I wrote would have been close to 300 pages
single-spaced. Sometimes a few pages (one function, perhaps) in 9 pt
on the laser printer so I can pour over it at lunch. Pore over it,
too.



300 pages is, what, 15k lines? That's a lot of assembly.

I still like to print them on fanfold, put them in a listing binder,
and take it to bed and read it over very carefully. I can make notes
in the margin, add post-its to flag things, stuff like that. I hate to
debug in the lab, so I try to get everything right the first time.
After a couple of passes like this, things get pretty good and, in
fact, I spend very little time debugging... maybe 10% or less of the
coding time. I like to make things largely table-driven, as opposed to
tons of branchy code, and that helps keep the bugs down.

Another advantage of table-driven code is hardware revision control.
On project I had needed to operate on several different versions of
hardware (several processors that had to inter-operate differently
depending on who they're talking to). I had a table for each supported
set of hardware. The entries in the tables were addresses of the
supported functions for that revision. On power-on each set of
hardware called out its revision and each processor set its table
pointer accordingly.

Each function was branchy because every test had an error handler
(which turned out to be 90% of the work).

Most of my embedded stuff seems to run around 4K lines, often less
(except for that 16-bit sine routine that was, um, 128 kbytes long. I
.nlisted that part.) Somewhere around 10K lines or so, flat assembly
programs (and their paper listings) start to get unweildy.

I don't like functions longer than a few pages (perhaps five 9pt.
pages). ...and often one of those is header material describing the
function, it's inputs and outputs, assumptions, and errors handled.

Lately most of our assembly progs have one or more Xilinx fpga config
tables built into the rom image, so the uP can boot the fpga's. We
wrote a rom builder program, sort of a primitive linker, to build
images out of S28 code and .RBT fpga config files. Dumb but works.

I put them in separate ROMs on my last project. It made things easier
and cost was no object.

So, off to bed, with a listing.

Don't get any paper cuts.

--
Keith

 

[John Woodgate]

I read in sci.electronics.design that Keith Williams <krw@att.bizzzz>
wrote (in <MPG.1c56f051c517484e989867@news.individual.net&gt about
'Programming for Electronics Engineers', on Tue, 18 Jan 2005:

Everyone knows that no matter what the question, the
answer is 'C'.

What is the circuit symbol for an inductor?
--
Regards, John Woodgate, OOO - Own Opinions Only.
The good news is that nothing is compulsory.
The bad news is that everything is prohibited.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk

 

[John Larkin]

On Tue, 18 Jan 2005 10:13:21 -0500, Keith Williams <krw@att.bizzzz>
wrote:

In article <a00pu0p4s55g1p616f1jgiqh6449a30k9n@4ax.com>,
jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX says...
On Tue, 18 Jan 2005 02:45:25 GMT, "Kryten"
kryten_droid_obfusticator@ntlworld.com> wrote:

John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote:
[...]
That's a lot of trouble to avoid a couple of GOTOs. I never understood
the anti-GOTO religion.

Someone said that GOTOs were a bad thing and everyone believed him.

I feel that GOTO can be valid in a certain circumstances.

Such as GOTO <special exit point>.

However people will abuse anything they are offered, so
GOTO <valid local jump
gets used a
GOTO <any place I damn well please anywhere in the entire program

Given the scope for appalling abuse, it might be wise to recommend very
sparing usage.

I heard of a guy who's immediate boss (the company boss's son) thought all
code should use GOTO almost entirely, and tried to force everyone else to do
so.


I prefer very flat programs controlled by conditional GOTOs (or JMPs,
in assembly) that operate as state machines. After all, not many
computers have curly brackets in their native instruction sets. What
language you use, and how you use it, just depends on how you think.

I prefer to use CASE like statements to implement state machines. The
PL/I Select/when fit me like a glove here. VHDL's CASE is not quite as
powerful, but makes very readable state machines. If it's done right
the implementation of the state machine can be determined at
compile/synthesis time, rather than during design.

Sure. CASE is just a list of GOTOs.

John

 

[Keith Williams]

In article <1BrIGJEUxS7BFwhz@jmwa.demon.co.uk>,
jmw@jmwa.demon.contraspam.yuk says...

I read in sci.electronics.design that Keith Williams <krw@att.bizzzz
wrote (in <MPG.1c56f051c517484e989867@news.individual.net&gt about
'Programming for Electronics Engineers', on Tue, 18 Jan 2005:

Everyone knows that no matter what the question, the
answer is 'C'.

What is the circuit symbol for an inductor?

What's the problem? indu-C-tor ;-)

If it can't be done in 'C', it's not worth doing. ;-)

--
Keith

 

[Keith Williams]

In article <7rcqu0dc085omgcu4bqt0ppvfg74qteirm@4ax.com>,
jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX says...

On Tue, 18 Jan 2005 10:13:21 -0500, Keith Williams <krw@att.bizzzz
wrote:

In article <a00pu0p4s55g1p616f1jgiqh6449a30k9n@4ax.com>,
jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX says...
On Tue, 18 Jan 2005 02:45:25 GMT, "Kryten"
kryten_droid_obfusticator@ntlworld.com> wrote:

John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote:
[...]
That's a lot of trouble to avoid a couple of GOTOs. I never understood
the anti-GOTO religion.

Someone said that GOTOs were a bad thing and everyone believed him.

I feel that GOTO can be valid in a certain circumstances.

Such as GOTO <special exit point>.

However people will abuse anything they are offered, so
GOTO <valid local jump
gets used a
GOTO <any place I damn well please anywhere in the entire program

Given the scope for appalling abuse, it might be wise to recommend very
sparing usage.

I heard of a guy who's immediate boss (the company boss's son) thought all
code should use GOTO almost entirely, and tried to force everyone else to do
so.


I prefer very flat programs controlled by conditional GOTOs (or JMPs,
in assembly) that operate as state machines. After all, not many
computers have curly brackets in their native instruction sets. What
language you use, and how you use it, just depends on how you think.

I prefer to use CASE like statements to implement state machines. The
PL/I Select/when fit me like a glove here. VHDL's CASE is not quite as
powerful, but makes very readable state machines. If it's done right
the implementation of the state machine can be determined at
compile/synthesis time, rather than during design.

Sure. CASE is just a list of GOTOs.

Ok, you can say that about any HLL construct then. The abstraction
reduces errors.

--
Keith

 

[Thaas]

On Tue, 18 Jan 2005 15:33:40 +0000, John Woodgate
<jmw@jmwa.demon.contraspam.yuk> wrote:

I read in sci.electronics.design that Keith Williams <krw@att.bizzzz
wrote (in <MPG.1c56f051c517484e989867@news.individual.net&gt about
'Programming for Electronics Engineers', on Tue, 18 Jan 2005:

Everyone knows that no matter what the question, the
answer is 'C'.

What is the circuit symbol for an inductor?

|
C|
C|
C|
|
(created by AACircuit v1.28.4 beta 13/12/04 www.tech-chat.de)

See?

--
Thaas

 

[Ken Smith]

In article <MPG.1c56f051c517484e989867@news.individual.net>,
Keith Williams <krw@att.bizzzz> wrote:
[....]

Come on, John! Everyone knows that no matter what the question, the
answer is 'C'.

No, its "Use a PIC"

Also a language for engineers should also implement run time checking
without a lot of extra work. 'C' doesn't do this at all.

No-one has mensioned IDL, so I will.



--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <1gqkyi9.igd7qj965bjaN%bskb@m.a.c.com>,
Bjarne Bäckström <bskb@m.a.c.com> wrote:
[....]

Sorry, I've missed the earlier replies because I've limited the
number of posts in one download to the latest 50 in each group.

My comment was a bit 'tongue in cheek,' but I really think one should
under no circumstances let a program quit, without letting the user know
whether the program crashed or he/she did something wrong.

Well, isn't obvious that it is always the case that the user did something
wrong. They either entered bad values or they ran a program that crashes,
both of which are their fault.


All seriousness aside:
I was more interested in showing the style and flavour of Pascal than the
details of a program. I used a useful program as an example because it is
often easier to grasp things with real examples.

--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <pan.2005.01.18.04.46.22.282897@example.net>,
Rich Grise <richgrise@example.net> wrote:
[.....]

I just didn't remember if Pascal had gotos or not. If I'd been allowed to
use "C", I'd just continue;.

Pascal has a GOTO.

Borland added CONTINUE and BREAK.

--
--
kensmith@rahul.net forging knowledge

 

[Ken Smith]

In article <peuou0d4qtp6o3rm0fm820alrjm5kjijct@4ax.com>,
Jim Thompson <thegreatone@example.com> wrote:
[....]

He also harps about GOTO. But he hasn't broken me of that... I just
use labels ;-)

Just make a JimThompson.h:

#define Do
#define what
#define it goto
#define says
#define at

------

Then you can write:

Do what it says at Line1;


--
--
kensmith@rahul.net forging knowledge

 

[Spehro Pefhany]

On Tue, 18 Jan 2005 08:44:12 -0800, the renowned John Larkin
<jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX> wrote:

On Tue, 18 Jan 2005 11:14:29 -0500, Keith Williams <krw@att.bizzzz
wrote:


Ok, you can say that about any HLL construct then. The abstraction
reduces errors.

Up to a point. The FBI just dumped a database project after spending
$170 million. The UK public health service is having a similar
experience, I think. Windows has had thousands of security holes and
tens of thousands of bugs. My best customer is a maker of megabuck
analytical instruments, with a heavily C++ loaded processing
component. They issue a weekly bug list averaging 5-10 new bugs; I
read it to find the ones related to my equipment (they always blame me
first, and they've been wrong every time so far.) One of their senior
researchers describes their software as "spinning out of control."

We live in the dark ages of programming.

John

Ah, don't be such a gloomy Gus.

It's amazing what is possible to cob together using other peoples'
work these days. Like that fellow here who made up (and gave away) a
gerber->pdf converter and only had to write something like 1,000 lines
of code (my estimate). But I imagine most of the work is understanding
and wrestling with APIs rather than the actual work itself.

But for mission-critical stuff, I like to see the bare metal, or at
most one layer above (such as C).


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

 

[John Larkin]

On Tue, 18 Jan 2005 17:09:56 +0000 (UTC), kensmith@green.rahul.net
(Ken Smith) wrote:

A good argument can be made for making the CALL instruction conditional.

The only CPU I ever designed had this. It had a total of four
instructions, as I recall. It was all MSI TTL with a hardware stack
and a 20 khz 4-phase clock. The follies of youth!

Some DSP and RISC machines have a conditional skip the next instruction,
but if you combine it with a call, you still get one following instruction
before the call happens.

The PDP-8 had a conditional skip. I suppose it was a RISC machine,
since it wasn't microcoded and did everything in one clock. I think
the low-end PICs are really PDP-8's.

The microcode for the PDP11/05 had ops thet were, essentially,
"conditional OR to the program counter." Imagine programming that!

John

 

[Keith Williams]

In article <csjekk$7s9$1@blue.rahul.net>, kensmith@green.rahul.net
says...

In article <MPG.1c56f051c517484e989867@news.individual.net>,
Keith Williams <krw@att.bizzzz> wrote:
[....]
Come on, John! Everyone knows that no matter what the question, the
answer is 'C'.


No, its "Use a PIC"

;-) ...and program it in 'C'? The truth is that a microcontroller is
often the best tool in the box.

Also a language for engineers should also implement run time checking
without a lot of extra work. 'C' doesn't do this at all.

I tend to agree, though many think it's a waste of time (see: M$).
This is one of the reasons I prefer VHDL over Verilog.

No-one has mensioned IDL, so I will.

Pointer?

--
Keith

 

[Keith Williams]

In article <giequ0la46torit42hhv4lj1n1qesk6orn@4ax.com>,
jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX says...

On Tue, 18 Jan 2005 11:09:43 -0500, Keith Williams <krw@att.bizzzz
wrote:

In article <1BrIGJEUxS7BFwhz@jmwa.demon.co.uk>,
jmw@jmwa.demon.contraspam.yuk says...
I read in sci.electronics.design that Keith Williams <krw@att.bizzzz
wrote (in <MPG.1c56f051c517484e989867@news.individual.net&gt about
'Programming for Electronics Engineers', on Tue, 18 Jan 2005:

Everyone knows that no matter what the question, the
answer is 'C'.

What is the circuit symbol for an inductor?

What's the problem? indu-C-tor ;-)

If it can't be done in 'C', it's not worth doing. ;-)


The original design of C was too timid. Insteading of minimizing
keywords, K&R should have been bold and eliminated them entirely,
creating a language based entirely on punctuation marks.

I *hate* the punctuation marks C uses now! I much prefer begin/end to
{}. It's easier for my eyes to find words.

And the math operations should have been external subroutines like
everything else.

That would make overloading the functions easier, but do you really
want M$ to overload '/' like Intel did? ;-)

--
Keith