Programming for Electronics Engineers

James Meyer wrote...
Winfield Hill wrote:

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.
Guilty as charged... I thought it was a mis-type. I have a compulsion
to fix spelling errors - if I see them that is; I have some difficulty
seeing fine fonts on my 1600x1200 LCD display. Having lots of pixels
is nice, but they sure are small. Plus, using a digital video cable
means the font lines are no longer slightly spread out, but now occupy
exactly one tiny pixel. Sheesh, one step forward, two steps back.


--
Thanks,
- Win
 
In article <92dqu0t0cm145m3do49mktolsamoe3civt@4ax.com>,
jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX says...
On Tue, 18 Jan 2005 10:28:54 -0500, Keith Williams <krw@att.bizzzz
wrote:


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.


We like being able to send a customer a single plugin eprom chip that
upgrades the firmware and all the fpga's on the board at once.
Configuration control is easier, too, when the firmware and fpga
configs are bound in a single release... it's impossible for them to
ever get mismatched.
Sure, it depends on the needs. In my case the FPGA configurations were
in flash (well, one was) and downloaded from disk.

--
Keith
 
In article <7bgru0hu2ornqrtl3fh7sbqef7ijuhjka2@4ax.com>,
jjSNIPlarkin@highTHISlandPLEASEtechnology.XXX says...
On Tue, 18 Jan 2005 15:53:49 -0600, John Fields
jfields@austininstruments.com> wrote:

On Tue, 18 Jan 2005 19:36:33 +0000 (UTC), "Reg Edwards"
g4fgq.regp@ZZZbtinternet.com> wrote:


GOTO's are a positive menace. Any language which allows them is a disgrace
to mankind's considerable acheivements in that direction.

---
Assembler with no labels? What a concept!


There have been some attempts at "structured assembler" with 'for' and
'while' type kluges, generally by use of a simple preprocessor or a
bunch of weird macros. This makes debugging especially silly.
FOr a while I used a set of PL/I macros for M$ MASM. They worked out
quite well and were recognized by the source debugger. I can't
remember if they supported the complete PL/I SELECT/WHEN construct, but
they were quite useful and produced tight code (even understanding
near/far).

--
Keith
 
Joel Kolstad wrote:

Heck, even the Linux people like COM!
That would only be fair, because Microsoft sure does seem to like Linux!
See [ http://www.aaxnet.com/editor/edit033.html ]
 
Winfield Hill wrote:

Aha, two Forth fans!

Forth has been around for over 25 years now, and as one who was very
keen on it in the early days- I saw it as a sort of MSI language, a bit
like the more complex TTL as aginst simple gates- I think its day has
long passed. In fact Forth any_good if people_using_it more then. It's
just too easy to crash when you have to do your own stack shunting. I
don't think C is perfect, but it's widely available, and it does the
job, even for 2k/128 byte targets, and it's got the low level dangerous
things that allows people who know what they are doing to get on with it.

Paul Burke
 
In message <4d31239910tonyw@ledelec.demon.co.uk>, Tony Williams
<tonyw@ledelec.demon.co.uk> writes
In article <cssfc201q1r@drn.newsguy.com>,
Winfield Hill <hill_a@t_rowland-dotties-harvard-dot.s-edu> wrote:

James Meyer wrote...

Guy Macon wrote,

Aha, two Forth fans!

Three.

Plus Jerry Avins, who (unfortunately) only posts
here occasionally.

Five, then.

Cheers
--
Keith Wootten
 
In message <35jt7dF4h5mn7U1@individual.net>, Paul Burke
<paul@scazon.com> writes
Winfield Hill wrote:

Aha, two Forth fans!

Forth has been around for over 25 years now, and as one who was very
keen on it in the early days- I saw it as a sort of MSI language, a bit
like the more complex TTL as aginst simple gates- I think its day has
long passed. In fact Forth any_good if people_using_it more then. It's
just too easy to crash when you have to do your own stack shunting.
For embedded work, that's a good thing. Get all the bugs out before
release. In practice, stack balancing becomes second nature.

Forth on a stack machine is a thing of beauty. Very fast, and
deterministic. Interrupt latency is very small - there's nothing to
stack, it's already there!

The obsolete RTX2000 was a very, very nice part and at 10MHz would
outperform anything else I've come across with similar clock speed. The
Ignite1 is astonishingly rapid (www.ptsc.com) but is owned by a bunch of
suits. There are several FPGA stack machine implementations which look
very interesting.

C works as a reasonable assembler, but whoever thought up the use of =
and == should be shot. Slowly. I also dislike the stupid typing rules
which seem to exist so that the compiler can tell you that you've broken
them, and why can't I use any goddam character I want in a function or
other name. The pointer syntax seems to deliberately obfuscate a simple
concept.

I don't think C is perfect, but it's widely available, and it does the
job, even for 2k/128 byte targets, and it's got the low level dangerous
things that allows people who know what they are doing to get on with it.

Paul Burke
I have to use it sometimes too, but I'd be kicking and screaming at the
thought of 2KiB/128B work in C or Forth for that matter. For small PICs
I use my own assembler which allows Forth-like naming flexibility and
looping/branching constructs without trying to force a data stack onto
the poor thing and which runs under Win32Forth.

Cheers
--
Keith Wootten
 
On Sat, 22 Jan 2005 11:36:26 -0500, keith <krw@att.bizzzz> wroth:

On Fri, 21 Jan 2005 23:38:14 +0000, James Meyer wrote:

On Fri, 21 Jan 2005 18:51:49 +0000, Guy Macon
_see.web.page_@_www.guymacon.com_> wroth:


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++.

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.
If you want speed in a C++ program for certain procedures or functions,
you often need to drop back to a hand optimized assembler routine. FORTH not
only allows that but even makes it easy. FORTH is interpreted when it can be,
usually during development, but after things are working, FORTH is usually
compiled into code that is often smaller and faster than assembly language.

Jim
 

Welcome to EDABoard.com

Sponsor

Back
Top