The Cyber-Spy.Com Usenet Archive Feeds Directly
From The Open And Publicly Available Newsgroup
This Group And Thousands Of Others Are Available
On Most IS NNTP News Servers On Port 119.
Cyber-Spy.Com Is NOT Responsible For Any Topic,
Opinions Or Content Posted To This Or Any Other
Newsgroup. This Web Archive Of The Newsgroup And
Posts Are For Informational Purposes Only.
From: Chuck Simmons
Organization: You jest.
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.0.33 i586)
Subject: Re: Basic Stamp vs Pic processors
References: <3D9F33B3.E4B561BB@webaccess.net> <firstname.lastname@example.org> <3D9F5649.57327EDF@webaccess.net> <email@example.com> <3D9FAA0B.3E57BD60@webaccess.net> <firstname.lastname@example.org>
Date: Sun, 06 Oct 2002 14:52:23 GMT
NNTP-Posting-Date: Sun, 06 Oct 2002 07:52:23 PDT
Frank Bemelman wrote:
> "Chuck Simmons" schreef in bericht
> > Frank Bemelman wrote:
> > >
> > > "Chuck Simmons" schreef in bericht
> > > news:3D9F5649.57327EDF@webaccess.net...
> > >
> > > > The loss of line numbers from Basic would seem to render it
> > > > After all, Basic was invented to teach students how to increment line
> > > > numbers.
> > >
> > > Well, since it still is an interpreted language in most cases, so you
> > > the advantage that it doesn't crash the system. It can safely escape,
> > > complaining about an undesired situation occured at runtime etc. Without
> > > linenumbers it is a lot like other procedural languages, like pascal or
> > No. I don't think so. Basic does not have proper data types. Not that I
> > have ever seen. Basic inherited implicit variables from Fortran and that
> > makes Basic programs difficult to debug because typos work.
> Private Sub Command1_Click()
> Dim sText As String
> Dim lTextLength As Long
> Dim sChar As String
> Dim bASCII As Byte
> Dim x As Long
> sText = "This VB stuff is pretty darn cool..!"
> lTextLength = Len(sText) 'Gets # of chars in sText
> For x = 1 To lTextLength 'Loop through string one char at a time
> sChar = Mid$(sText, x, 1)'Gets the x'th charcter in sText
> bASCII = Asc(sChar) 'Gets ASCII value of character
> MsgBox "The ASCII value of '" & sChar & "' is " & bASCII 'Display results
> Next x
> End Sub
VB is not a standard Basic. Moreover, it still allows implicit variables
which was a major disadvantage of Fortran. However, it is the case that
I have not used Basic since 1980 (I left Burr-Brown after having been
exposed to every possible horror that existed in Basic at that time).
> > Pascal has strong data typing and data structures. It requires
> > declaration of variables in advance so typos typically don't work. The
> > rigorous data typing makes some tasks difficult but the structure makes
> > the language readable and largely self documenting. In fact, I have seen
> > assembly programs commented with Pascal to make algorithms clear.
> > C has weak data typing and data structures and C++ adds objects. Weak
> > data typing allows implicit conversions. Generally C allows convenience
> > in writing algorithms that are difficult to express in Basic or Pascal
> > in that it provides access to more primative functions.
> > > In my book, assembly is dead. C has become an excellent replacement, now
> > > that processors have become much faster - and cheaper. Programmable
> > > has also helped making assembly become redundant. Stuff that requires
> > > screaming
> > > speed can often be isolated enough into function blocks that can be
> > > implemented
> > > with programmable logic. The less speed-demanding stuff can be done all
> > > C/C++. I never liked Forth, I tried it a couple of times, but it's too
> > > oriented for me, I have difficulties translating my 'problems' into
> > In embedded systems, memory is very expensive. The reason is that memory
> > is a silicon hog. It is so nasty that one would not have it if it could
> > be avoided. Consider an optimal chip design that just fits a pad limited
> > die that just fits a package with the right number of pins. Now add more
> > memory. Yikes! The die grows out of the pad limited size and becomes too
> > big for the desired package die cavity. Very very bad because the larger
> > package costs more. OK, why not an external bus? Wrong answer. More
> > chips cost more. An external bus requires more pins so cost goes up.
> > Major loser. If that's you best shot, pack your personal stuff and go
> > home.
> There will always be examples where a few lines of asm are the sensible
> thing to do, but life has become a lot easier, in the embedded world.
> In 1978 I wrote a stackless program for a Z80, no ram chip to save money,
> as I could keep all stuff in the available registers. Handcoded ;) A simple
> jump at the end to close the loop. Today, in *my* book, assembly is dead.
The embedded world is indeed fairly strange. In 1980 I started doing
digital servos. I used a PDP-11/23 running Forth over RT-11. RT-11 was
very nice in that I could hijack the interrupt vectors and diddle
priorities conveniently. The servo was written in the assembler built
into CalTech Forth for PDP-11. The sample rate was a bit over 1kHz. The
ground rule for the servo was that it use less than 50% of available
cycles between samples since another part of the project needed the
other 50%. The product group that used the servo converted it to MC68000
which was the absolute best integrated processor of that time for the
task (based on our benchmarks which always came up with 8086 is last
place because of segmentation problems and too much register shuffling).
The product shipped initially with about 1 meg of code the bulk of which
was in C but the product group decided to leave the servo in assembler.
The servo was only a few thousand bytes but its execution consumed more
than 40% of the MC68000 cycles.
Today I have dedicated processors so I set my sample rate to about 80%
utilization leaving the other 20% for exception handling. The Harvard
architectures are clumsy about interrupt dispatching burning
unnecessarily some 20 or 30 cycles (this due to the fact program memory
cannot be written). Architectural inefficiencies have to be watched
closely becuse they can consume a lot of time. This is where compilers
get into trouble. They don't tell me that they are doing something
stupid like generating far to much code to get around Harvard problems.
If I see code getting out of hand because of architectural difficulties,
I change the approach or drop the feature entirely. Compilers don't
understand clock time. I currently sample the input every 20
microseconds but I produce outputs every 5usec. A state machine insures
output time jitter is less than 100nsec. Output data must be presented
at least 200nsec before it is used. Thus the time line for each output
calculation must be carefully kept below a known time period. It's a
juggling act keeping the initial timeline short and putting housekeeping
and cleanup at the end. Housekeeping is about 75% of the code
(housekeeping is everything that is done in preparation for the next
What always happens in high performance low cost motion control systems
is that the all of the tradeoffs are pushed to the limit.
... The times have been,
That, when the brains were out,
the man would die. ... Macbeth
Chuck Simmons email@example.com
Go Back To The Cyber-Spy.Com
Usenet Web Archive Index Of
The sci.electronics.design Newsgroup