Which programming language to learn
dapunka
reading, and am about to embark on a "first robot tutorial" on the
Society of Robotics website.
When I reach a more advanced level, I know I will need programming
skills. I haven't done any programming apart from some BASIC at
school 20 years ago! But I'm willing to learn. So, what would be the
best programming language for me to learn in connection with hobbyist
robotics? C++? Some form of BASIC? Or something else entirely?
BRW
Both C and BASIC are well supported by microcontroller compilers /
interpreters, so either language is a good choice. I personally
prefer compiled C for my micro work (I use CCS's awesome C compiler).
On the (Windows) PC side, I recommend C# or VB.NET. Don't bother with
C++, as it and its COM/DCOM ilk are deprecated. .NET / C# / VB.NET is
where it's at now.
BRW
howy
I agree, unless you are writing a huge program, plain old C is much
simpler and reduces your risk of encountering compiler induced bugs.
Don't repeat that out loud on the C++ news group though or they will
start screeching and throwing feces at each other in protest. They can
be an ornery bunch when you suggest that C has any use in modern day
life.
For robot control C is great although I can see if you get into heavy
image processing or very complex behavior heuristics then C++ could
help insure isolation between software components. Of all the
programming languages, learning C will give you the best return on
your investment long term. An interpreted language like C# might help
speed things along when you are making constant changes but I dont
think you are going to find a C# interpreter for your 8 or 16 bit
micro controller.
Oh, and try to start with a PC as your experimenting platform. Buy a
few servos and hook them up to your serial port (or USB port) using
that Mini-SSC adapter thingy and just start making things move.
-howy
Wayne C. Gramlich
> On Aug 29, 10:21 am, dapunka <dapu...@googlemail.com> wrote:
>> I have recently become interested in robotics - I've done a bunch of
>> reading, and am about to embark on a "first robot tutorial" on the
>> Society of Robotics website.
>>
>> When I reach a more advanced level, I know I will need programming
>> skills. I haven't done any programming apart from some BASIC at
>> school 20 years ago! But I'm willing to learn. So, what would be the
>> best programming language for me to learn in connection with hobbyist
>> robotics? C++? Some form of BASIC? Or something else entirely?
>
> Both C and BASIC are well supported by microcontroller compilers /
> interpreters, so either language is a good choice.
Agreed. Not all Basic's are the same, but if you learn one
you can usually get something working on the other. ANSI-C
is really quite standardized, but most microcontroller C
compilers only implement a sub-set of ANSI-C. Thus, code
written for one microcontroller C compiler tends to need
some "tweaking" to get it to run on another microcontroller
C compiler. I'd vote for ANSI-C, but Basic is not a bad
choice either.
> I personally
> prefer compiled C for my micro work (I use CCS's awesome C compiler).
Many people are extremely happy with the CCS C compiler for
Microchip PIC microcontrollers. For the Atmel AVR folks,
most people use the GCC (Gnu C Compiler) tool chain which
is "free".
> On the (Windows) PC side, I recommend C# or VB.NET. Don't bother with
> C++, as it and its COM/DCOM ilk are deprecated. .NET / C# / VB.NET is
> where it's at now.
C# tends to be mostly Windows these days (although there is
the mono project for Linux.) C++ is available on more
platforms. Also, Java is quite popular. These languages
tend to require pretty beefy machines to run. There are
exceptions (C++ on the AVR) and the Java on PIC effort out
of the Netherlands, but for the most part you need a 32-bit
processor for the Java/C++/C# stuff.
Your mileage may vary,
-Wayne
Too_Many_Tools
Seems like a civil group....let me ask a question too.
What are the differences between C C++, C#, C.Net? and any other
variations out there?
I used to BASIC and PASCAL...each had its place.
I especially liked PASCAL...it allowed one to write readable and well
structured code.
TMT
Wayne C. Gramlich
I recommend reading the appropriate Wikipedia articles
to answer your question. Anything I write here would be
a rehash of what the articles already say.
Many people have fantastic religious wars about how language
A is better/worse that language B. These religious wars obscure
the fact that a programming language is a tool. In the hands
of a skilled programmer, each language can be made to sing;
likewise, in the hands of an amateur, the resulting code is not
pretty to read or debug.
Rather than focusing in on a particular programming language
it is probably more important to learn basic programming skills
that are applicable across most languages. Particularly important
programming skills for programming are 1) data structures and
2) debugging skills. There are many books on data structures,
but rather few books on debugging.
My $.02,
-Wayne
-Wayne
dapunka
Thanks everyone for your advice! It's a coin-toss, C or BASIC... I'll
have to give it some thought. Thanks again.
JGCASEY
There is the option of learning both BASIC and C so you can use
whatever is suitable at the time.
--
jc
imma
dapunka
You're right, of course. Why limit myself?
Joe Pfeiffer
Based on my experience, you pretty much have to learn C before you can
learn C++ (of course, I learned C roughly two decades before I learned
C++, so I might be biased. But we tend to teach our students concepts
that apply to both languages first, and then move to C++ constructs).
But no single event has improved my C code as much as learning C++
did -- you end up thinking in objects, which is (IMHO) just plain a
better way to think, no matter what the application or the language
you're working in.
So I'd say learn C, then C++. I'd suggest a scripting language like
PHP (or Perl, or Python -- but PHP is the one I know) next, but that's
not really useful for a robotics project.
You'll notice BASIC didn't make my list. As a historical note, it was
the first language I learned.
Joe Pfeiffer
>
> What are the differences between C C++, C#, C.Net? and any other
> variations out there?
C++ is a superset of C (well, not quite, but pretty close) which adds
object-oriented constructs -- classes, in particular. The syntactic
differences are small, but you think very, very differently when
programming C++, and that bleeds over (in a good way) to your C code.
It has some features supporting genericity in functions, which can
lead to huge problems with bloat in the generated machine code.
I don't do Windows, so I don't speak C# or C.net, and can't comment on
them.
> I used to BASIC and PASCAL...each had its place.
Me too -- in my experience, BASIC's place was in a wastepaper basket.
To the extent that BASIC has become a useable language, it's been by
adopting C constructs -- you're much better off with a more modern
scripting language (in a post I made a couple of minutes ago, I
mentioned PHP, Python, and Perl -- forgot Ruby, which should also be
listed).
> I especially liked PASCAL...it allowed one to write readable and well
> structured code.
I was a real Pascal bigot (first structured langauge I learned, and
the group that wrote the VAX Pascal compiler for DEC was in the
department where I got all my degrees) until the day I had a tape with
data in Data General floating point format data and needed to convert
it to run on a VAX. I think that may have been my last Pascal
project. C will let you do what you want to do, and not argue with
you about it -- it's got lots of flaws that the programming languages
researchers will complain all day long, but that one virtue covers
almost anything.
sp...@controlq.com
> What are the differences between C C++, C#, C.Net? and any other
> variations out there?
>
> I used to BASIC and PASCAL...each had its place.
>
> I especially liked PASCAL...it allowed one to write readable and well
> structured code.
>
> TMT
C, originally a portable but high level "assembler" is a procedural
language designed in and around the original Unix operating system at
AT&T, and become useful for portable OS development, system level coding
and indeed, embedded programming, as it is a relatively low level language
which gets close the iron, and supports structures and syntax easily
supported directly by most processor instruction sets. C is simple,
straightforward, efficient and widespread with many implementations both
open source and commercial. (see also predecessors BCPL, B and variant D)
C++ was an extension to C created by Bjarne Stroustrup, and originally
consisted of a preprocessor which added object oriented features (objects,
classes, inheritance, operator overloading ...) to the intial C language,
which remains a valid subset of C++ by the way. Modern C++
implementations are full compilers, rather than a preprocessor tacked onto
the front of a C compiler. C++ is often criticized as being a write only
language, and indeed it is easy to write convoluted and undecipherable
C++, and this is exacerbated by the features which continue to creep into
the language over time. Smalltalk, it is not!
C# is a language developed by Microsoft to counter Java, and in this
regard has many similarities to Java (as opposed to C). C# was closely
linked to the .net environment on Windows, and was more about locking
software onto the Microsoft platform. This has been countered to some
extent by the existance of the open source Mono project which has a
portable implementation of the .net environment on Linux/Unix, and which
is not on Microsoft platforms.
C.net? Visual C? Visual C++? simply a compiler/IDE with bundled Windows
libraries for Win32, and the .net wrapper for the Microsoft environment.
Pascal is similar to C in certain respects, but indeed, has aspects common
to Ada, in that strong type checking, nested functions, and some aids to
prevent programming errors. Assignment (:= vs =) is sufficiently
different from logical test (= vs ==) to avoid many common C bugs.
Basic is an ideal language for babies, or hw engineers who think that
programming is mostly done with solder, and can't be bothered to learn
programming in a proper language (eg: C or Forth). The BASIC various
dialects are so numerous and so different from any standard, that no two
basics share much in common. Microsoft's Visual Basic as a case in point
has very little to do with basic, and was named mostly to impress
potential programmers as to how easy it is to use (propaganda).
Having said this, I'm surprised that noone on this thread has mentioned
Forth as an embedded language, as it in certain respects beats most
languages hands down for robotics. Originally used to control
telescopes for astronomical tracking, this langage has been around since
Charles Moore described it in the very early 1970's, and literally exists
on just about every processor invented by man.
Forth is often "available" as an option wherever embedded basic is
available, and typically offered as a me-too. Having gone through the
learning curve with Forth, with its embedded assembler(s) cross
compilation, metacompilation simple multitasking, and inherent ability to
bit-bang, it is very close to the hardware, high level words can be
re-written in assembly for efficiency when needed, there are all kinds of
advantages.
Anyway, I hope the above (admittedly biased) descriptions help ... 8-)
Cheers,
Rob Sciuk
David Kelly
>
> Seems like a civil group....let me ask a question too.
>
> What are the differences between C C++, C#, C.Net? and any other
> variations out there?
One of the biggest differences is that its pretty easy to get your
application written in C to run on a $2.50 (qty 1) CPU. Using avr-gcc I
once put a 600 byte application on an AVR that cost less than $2.50 from
DigiKey.
Microchip has been the darling of hobbyists in the past. Today I suggest
looking at the Atmel AVR products. Also the free WinAVR and other
avr-gcc tool chains.
Don't go more than a day into your project without some form of revision
control. Starting cold turkey you should give preference to Subversion.
TotoiseSVN would be my recommendation for Windows. CVS is also a good
choice. Nightly backups is not as good altho you should routinely backup
the version control repository.
You should commit your changes every time you have mostly completed
something. Use short descriptions to the commit, "Started serial command
processing routines." Should commit several times per day, and always at
the end of the day. Then for fun use the version comparison functions in
TortioseSVN (or TortoiseCVS) and it should become obvious why one should
use version control if it wasn't already.
Ironically one of the most common practical uses I get of CVS and SVN
(have projects under both that are not practical to convert) is file
synchronization between machines. Just go to the project directory and
"update". CVS or SVN goes to the proper place and updates local files
and/or flags those that have changed locally so that one can reconcile
the differences.
http://www.bdmicro.com/ has good AVR stuff, robotics oriented. I have
used a MAVRIC board to prototype before laying out my own board
optimized for my application.
For $40 this is an awfully good value for programming and in-circuit
debugging of most (double check first) AVRs which support JTAG
interface: http://www.ecrostech.com/AtmelAvr/AvrIceCube/index.htm
The $4 10-way Ribbon Cable and $3 Cable Adapter are very handy. If you
need them you will have spent more than $7 in frustration learning that
you needed them. Forgot why the Cable Adapter is needed.
The AVR Dragon for $52 will handle some newer JTAG AVRs the ICECube will
not, has Debug Wire the ICECube lacks, but will not handle the larger
AVRs (as used on the MAVRIC boards) that ICECube does.
e c kern
> Too_Many_Tools wrote:
> > On Aug 29, 9:21 am, dapunka <dapu...@googlemail.com> wrote:
> >> I have recently become interested in robotics - I've done a bunch of
> >> reading, and am about to embark on a "first robot tutorial" on the
> >> Society of Robotics website.
>
> >> When I reach a more advanced level, I know I will need programming
> >> skills. I haven't done any programming apart from some BASIC at
> >> school 20 years ago! But I'm willing to learn. So, what would be the
> >> best programming language for me to learn in connection with hobbyist
> >> robotics? C++? Some form of BASIC? Or something else entirely?
>
> > Seems like a civil group....let me ask a question too.
>
> > What are the differences between C C++, C#, C.Net? and any other
> > variations out there?
>
> > I used to BASIC and PASCAL...each had its place.
>
> > I especially liked PASCAL...it allowed one to write readable and well
> > structured code.
>
> I recommend reading the appropriate Wikipedia articles
> to answer your question. Anything I write here would be
> a rehash of what the articles already say.
http://en.wikiquote.org/wiki/Programming -- especially. it's not
always obvious which quotations are supporters and which are
detractors, though.
> Many people have fantastic religious wars about how language
> A is better/worse that language B. These religious wars obscure
> the fact that a programming language is a tool. In the hands
> of a skilled programmer, each language can be made to sing;
> likewise, in the hands of an amateur, the resulting code is not
> pretty to read or debug.
technically speaking what you really mean is that in the hands of a
skilled programmer any language can be used to simulate a turing
machine. sing is subjective. if you take a brilliant lisp hacker and
make him write java servlet pages, he'll be able to do it, but he
won't describe it as "singing". he'll tie a noose with his mouse
cable and hang himself. the desire to avoid that leads to fanaticism.
> Rather than focusing in on a particular programming language
> it is probably more important to learn basic programming skills
> that are applicable across most languages. Particularly important
> programming skills for programming are 1) data structures and
> 2) debugging skills. There are many books on data structures,
> but rather few books on debugging.
while programming concepts are similar across languages, language
choice affects how you think about programming (see also: sapir-whorf)
as well as which operations are simple vs. contrived. in the last
week, i have worked on code in three languages: c, c++, and perl, for
three projects: a website i'm writing, an avr in a robot, and a high
performance distributed server system for my job. assuming for now
that i'm a skilled programmer, do you really think i could make those
"sing" in any language/project combination?
if the goal is programming small microcontrollers for robots, in the
long run the best option is to learn c.
-chris.
e c kern
> Based on my experience, you pretty much have to learn C before you can
> learn C++ (of course, I learned C roughly two decades before I learned
people do tend to think that but the truth is you only need to learn c
first if you want to be a *good* c++ programmer. pretty much
everybody who knows c++ writes "c/c++" on their resume. when i
interview software engineer candidates i usually ask coding questions
in c. it is astounding how many "senior c/c++ programmers" fall on
their face when you ask them to use malloc.
the scary part about c++ is how much you can do without understanding
what you are doing.
-chris.
Deep Reset
"e c kern" <eck...@gmail.com> wrote in message
news:1188587016.8...@e9g2000prf.googlegroups.com...
Or even knowing where the "shift" key is.
Deep.
dapunka
> On Aug 29, 8:11 pm, "Wayne C. Gramlich" <Graml...@PacBell.Net> wrote:
>
>
>
> > Too_Many_Tools wrote:
> > > On Aug 29, 9:21 am, dapunka <dapu...@googlemail.com> wrote:
> > >> I have recently become interested in robotics - I've done a bunch of
> > >> reading, and am about to embark on a "first robot tutorial" on the
> > >> Society of Robotics website.
>
> > >> When I reach a more advanced level, I know I will need programming
> > >> skills. I haven't done any programming apart from some BASIC at
> > >> school 20 years ago! But I'm willing to learn. So, what would be the
> > >> best programming language for me to learn in connection with hobbyist
> > >> robotics? C++? Some form of BASIC? Or something else entirely?
>
> > > Seems like a civil group....let me ask a question too.
>
> > > What are the differences between C C++, C#, C.Net? and any other
> > > variations out there?
>
> > > I used to BASIC and PASCAL...each had its place.
>
> > > I especially liked PASCAL...it allowed one to write readable and well
> > > structured code.
>
> > I recommend reading the appropriate Wikipedia articles
> > to answer your question. Anything I write here would be
> > a rehash of what the articles already say.
>
Thank you chris, and everyone else who replied. It's been very
helpful, and has focused my attention.
Wayne C. Gramlich
> On 31 Aug, 19:24, e c kern <eck...@gmail.com> wrote:
>> On Aug 29, 8:11 pm, "Wayne C. Gramlich" <Graml...@PacBell.Net> wrote:
[snip]
>>> Many people have fantastic religious wars about how language
>>> A is better/worse that language B. These religious wars obscure
>>> the fact that a programming language is a tool. In the hands
>>> of a skilled programmer, each language can be made to sing;
>>> likewise, in the hands of an amateur, the resulting code is not
>>> pretty to read or debug.
>> technically speaking what you really mean is that in the hands of a
>> skilled programmer any language can be used to simulate a turing
>> machine. sing is subjective. if you take a brilliant lisp hacker and
>> make him write java servlet pages, he'll be able to do it, but he
>> won't describe it as "singing". he'll tie a noose with his mouse
>> cable and hang himself. the desire to avoid that leads to fanaticism.
I was not trying to say that the languages are interchangable;
they are not. What I was saying is a that a skilled programmer
will know how to write reasonable code for each language.
Indeed, they will choose the language based on the problem
at hand.
Actually, I do know some phenomenal LISP hackers and they
have largely moved onto other languages. Many of them
now regularly program in languages other than LISP with
committing suicide.
>>> Rather than focusing in on a particular programming language
>>> it is probably more important to learn basic programming skills
>>> that are applicable across most languages. Particularly important
>>> programming skills for programming are 1) data structures and
>>> 2) debugging skills. There are many books on data structures,
>>> but rather few books on debugging.
>> while programming concepts are similar across languages, language
>> choice affects how you think about programming (see also: sapir-whorf)
>> as well as which operations are simple vs. contrived. in the last
>> week, i have worked on code in three languages: c, c++, and perl, for
>> three projects: a website i'm writing, an avr in a robot, and a high
>> performance distributed server system for my job. assuming for now
>> that i'm a skilled programmer, do you really think i could make those
>> "sing" in any language/project combination?
In the likely situation where you are a skilled programmer,
I suspect that you use the best language for the application at
hand. I repeat, I was not trying to say that languages are
interchangable.
I've been writing code since the 1960's, so I have quite a
number of programming languages that I've used over the years
(Algol, FORTRAN IV, APL, PDP-8 assembler, PDP-10 assembler,
8080 assembler, Bliss-10, SAIL, Pascal, Bliss-11, K&R C, Clu,
Snobol, 808x assembler, C++, Bourne Shell, Tcl/Tk, Java, Perl,
SQL, Python, Microchip PIC assembler, etc.) Many of the skills
that I learned in now obsolete languages have been transfered
to newer languages. Thus, my paragraph above was trying to
focus on learning useful transferableprogramming concepts rather
than just programming languages.
>> if the goal is programming small microcontrollers for robots, in the
>> long run the best option is to learn c.
I agree, C is an excellent choice for embedded microcontrollers.
-Wayne
Wayne C. Gramlich
> Actually, I do know some phenomenal LISP hackers and they
> have largely moved onto other languages. Many of them
> now regularly program in languages other than LISP with
> committing suicide.
Typo: I meant "... with[out] committing suicide."
oops.
-Wayne
Joe Pfeiffer
It was more fun the first time :)
RMDumse
> Basic is an ideal language for babies, ...
I think this is the standing myth, but it misses BASIC's historical
origins. BASIC was named because the authors wanted a very basic
language. But it's early popularity was not its simplicity, but its
interactivity. I would suggest it was one of the very early IDE's
(integrated development environments). If you were a beginner and were
going to write a program in the '70's, you have your choice.
1) Learn how to launch BASIC. Start typing.
2) Or learn how to launch an editor, learn the system file structure
and save your edited source with only allowed character names and
extensions, learn how to launch a compiler, with half a dozen command
line parameters, which implies learning the command line structure of
the system as well, learn how to launch an assembler, again with
command line parameters, extensions, and file modifications, learn how
to run a linker, etc., and then see if your program did anything but
crash. The differences were astounding. BASIC accomplished this by
being interactive. You could enter your program, edit your program,
run your program, all from the terminal. So BASIC became popular by
being interactive.
Lest we forget interactivity was what made the Personal Computer,
well, personal. Most contact with computers in the 1970's was through
a punch card deck. Someone else took care of the JCL cards that
proceeded and followed your job, and a print out was all you got back.
Unless you were a system guy, you never saw the part where all that
was done. The JCL (or the paper tape, or even the front switch panel)
was the interactive part.
Now those days are gone. The new "Basic"s aren't interactive any more.
They are roughly like any conventional language. Hence only the
leagacy of "simple" carries Basic forward, and the simpicity stands in
the way of useability, without the advantage of interactivity. Yet it
tends to be a very low performance language, speed-wise.
> Having said this, I'm surprised that noone on this thread has mentioned
> Forth as an embedded language, as it in certain respects beats most
> languages hands down for robotics.
Yes, sorry. Generally promoting Forth falls to me, here (self
appointed). Been down sick for over a week (or should I say very
weak).
Forth retains its interactivity (most versions), runs natively on the
final system, has good speed (particularly for a language retaining
interactivity), and has unparallel code compaction. Forth is generally
available at very reasonable prices, as well as in freewear
"unsupported" versions.
In robotics, the wonderful thing about Forth is, again, its
interactivity. You don't have to wonder what value some variable
holds, you can query it and see. You don't have to wonder if some
output is high or low, you can query it and see. You don't have to
wonder what some input from a sensor is, you can query it and see. You
don't have to wonder if changing some variable slightly would do, you
can just set the value and try it. You don't have to wonder if some
servo is working or not, you can just try it, set it where you want,
and see if it follows. And so on. They way you do these sorts of
changes with conventional debugging are usually convoluted and
complex, and done with very expensive ICE equipment, while Forth
programmers feel totally enabled with a tiny bag of tools readily at
hand.
Interactivity. Nearly a lost concept in the world of modern
programming.
You might want to atleast have a look at Forth. MPE is one of the
remaining leading vendors, and is resident in the UK.
--
Randy M. Dumse
www.newmicros.com
Caution: Objects in mirror are generally more confused than they
appear.
RoboHobby
I am programmer by profession.
Robotics is just my hobby.
I use Java (J2ME - Java in cell phones) for robotics.
We created J2ME-based robot, with uses phone camera as a sensor and it
is even possible to see where the robot is going.
If you want to program microchips, I recommend you to use C language
(not C++).
C language is supported for a lot of devices (chips).
It is most popular language (after assembler) for microchips.
Also BASIC is supported on some chips.
All the other languages (C++, Phyton, Java, etc.) are not so popular.
If you ask me personally, I like Java because I use this language for
programming things of any size - big data driven systems, web sites,
cell phones, PDAs, etc.
It works on many platforms and I like this language very much.
Sincerely, Oleg
-----------------------
On Aug 29, 6:21 pm, dapunka <dapu...@googlemail.com> wrote:
> I have recently become interested in robotics - I've done a bunch of
...
sp...@controlq.com
>
> On Aug 29, 9:42 pm, s...@controlq.com wrote:
>> Basic is an ideal language for babies, ...
>
> I think this is the standing myth, but it misses BASIC's historical
> origins. BASIC was named because the authors wanted a very basic
> language. But it's early popularity was not its simplicity, but its
> interactivity. I would suggest it was one of the very early IDE's
> (integrated development environments). If you were a beginner and were
> going to write a program in the '70's, you have your choice.
>
> 1) Learn how to launch BASIC. Start typing.
Randy, This tongue in cheek response was meant in jest, and in no way
to slag your products. My main problem with BASIC, is that some people
will call any simple language "basic" regardless its syntax/roots.
Standardization remains the one real problem here.
>
> 2) Or learn how to launch an editor, learn the system file structure
> and save your edited source with only allowed character names and
> extensions, learn how to launch a compiler, with half a dozen command
> line parameters, which implies learning the command line structure of
> the system as well, learn how to launch an assembler, again with
> command line parameters, extensions, and file modifications, learn how
> to run a linker, etc., and then see if your program did anything but
> crash. The differences were astounding. BASIC accomplished this by
> being interactive. You could enter your program, edit your program,
> run your program, all from the terminal. So BASIC became popular by
> being interactive.
>
> Lest we forget interactivity was what made the Personal Computer,
> well, personal. Most contact with computers in the 1970's was through
> a punch card deck. Someone else took care of the JCL cards that
> proceeded and followed your job, and a print out was all you got back.
> Unless you were a system guy, you never saw the part where all that
> was done. The JCL (or the paper tape, or even the front switch panel)
> was the interactive part.
been there, done that!
>
> Now those days are gone. The new "Basic"s aren't interactive any more.
> They are roughly like any conventional language. Hence only the
> leagacy of "simple" carries Basic forward, and the simpicity stands in
> the way of useability, without the advantage of interactivity. Yet it
> tends to be a very low performance language, speed-wise.
>
Forth has all the interactivity and simplicity of BASIC, is generally
faster, more compact and portable, and has the added advantage of ANS/ISO
standardization, embedded assembly, simple multitasking, various
levels of hardware register and interrrupt support etc. etc. While it has
a steeper learning curve than BASIC, IMHO, it is well worth the effort!
MPE is a fine company, and they (Stephen Pelc) offers a free programming
in Forth .pdf tutorial which is a *VERY* good introduction to Forth:
http://www.mpeltd.demon.co.uk/arena/ProgramForth.pdf
Additionally, free/GPL'ed versions of Forth exist for classic 8 bit
(8051/8088/6502/6809) processors, as well as more recent (PIC/AVR/ARM etc)
SoC's and versions for Windows, Unix, Linux, Mac, some with X-development
tools for metacompilation and meta assembly ...
> --
> Randy M. Dumse
> www.newmicros.com
> Caution: Objects in mirror are generally more confused than they
> appear.
Thanks, Randy, and again, BASIC is not really a language for babies, and
engineers who prefer soldering to coding, but Forth offers a *VERY*
good alternative for the embedded developer, IMHO ...
David Mitchell
> When I reach a more advanced level, I know I will need programming
> skills. I haven't done any programming apart from some BASIC at school
> 20 years ago! But I'm willing to learn. So, what would be the best
> programming language for me to learn in connection with hobbyist
> robotics? C++? Some form of BASIC? Or something else entirely?
Speaking as a programmer who has spent quite a few years programming
embedded systems, in a variety of languages...
I wouldn't use C for anything larger than a page or two of code; but it
does tend to generate fast, compact, code, and there are a million and
one compilers for it, many free. OTOH the language itself is rather
poor, IMO, it lacks many useful features and, unless you're very careful
can produce buggy code - the programmer is expected to check everything
"manually" (for example array bounds).
You can mitigate this to an extent with program analysis tools such as
LINT however. (To put this in context, I was once contracted to perform
QA on some C code for a mobile phone manufacturer. I analysed code in
handsets which were already on sale, and found over thirty "fatal" errors
in the first week). I wouldn't program in C without LINT nowadays, and
I'd advise you to do the same. The GNU C compiler can also perform some
static program checks, and is free.
C++ tends to generate bulkier code, and it's not much of an improvement
on C in terms of the language itself.
FORTH, as others have pointed out, is ideally suited to certain kinds of
embedded systems, the interactivity is extremely useful (one study, using
smalltalk, found that programmers using interactive programming
environments were up to ten times more productive than the traditional
edit-compile-run alternatives), the code, although generally interpreted,
executes very quickly and is generally very compact. However, there are
generally no safeguards against programmer error, and the language lacks
pretty much every high-level feature you might want (although you can
usually write your own). I like FORTH, I've written a lot of code in it,
and even one or two compilers for it; but I wouldn't use it for large
scale projects.
My favourite language du jour is pascal - there are lots of good
compilers for it (www.freepascal.org have a good one, and it's, as the
name suggests, free).
It's a better language than C, IMO, it's more readable, more consistent,
runs equally quickly and there as almost as many free components for it
as C, thanks mainly to Borland.
The best advice I can give you is to pick a language and tools which most
reduce the possibility of programmer error - and of the four described
here, that's pascal.
However, if you can find a compiler for it, I'd recommend Ada: it's a
modern language with lots of high-level features and it was designed to
allow comprehensive static checking, and to work efficiently in embedded
systems. I haven't worked with it, though, so I can't recommend it from
actual experience.
Eiffel is also a very interesting language in that regard - again, I've
not used it, but I hear very good things about it.
HTH
--
=======================================================================
= David --- If you use Microsoft products, you will, inevitably, get
= Mitchell --- viruses, so please don't add me to your address book.
=======================================================================
Bill Cooke
activities. Without a doubt you should evaluate the IPRE program
http://wiki.roboteducation.org/Main_Page . It focuses on a (freshman)
course introducing "computer science" with what early schooling calls
"manipulables" - namely robots. The tool is built on Python, a
functional programming language which is readily learned by fifth
graders and up. It is widely used, both at the core of very
sophisticated web apps, and for autonomous robots carrying a linux / mac
/ windows cpu or netbook.
IPRE is certainly a rewarding personal investment. If not the only
robotics language you will learn, your IPRE study will certainly carry
you a long way in early simplicity, and later complexity, of robotic
developments.
If simplicity is your only goal, try parallax's basic.
~ ~ Bill
Phil O. Sopher
news:Q6SdnWtiVsN1C5zW...@brightview.co.uk...
>
> FORTH, as others have pointed out, is ideally suited to certain kinds of
> embedded systems, the interactivity is extremely useful (one study, using
> smalltalk, found that programmers using interactive programming
> environments were up to ten times more productive than the traditional
> edit-compile-run alternatives), the code, although generally interpreted,
> executes very quickly and is generally very compact.
FORTH is the interpreted assembly language of the English Electric
KDF9 computer. It is even more buggy than C, and is at a lower level.
The code, being interpreted, runs at a slower speed, at least 5 times
slower, than the compiled code from C.
C is generally a better bet than assembly language these days, because of
the advances made in optimisations. You'd be hard pressed to write
code with fewer instructions than that generated by the C compiler. OK,
occasionally you might get a better use of registers, but such improvement
will be piecemeal.
In C you might write "a = b + c" and all the underlying machine code
will be generated correctly. In FORTH, you must write a whole
load of lower-level code to achieve the same, any line of which code can
introduce a difficult-to-find bug.
To come back to the OP, to really understand what's going on from an
engineering
perspective, some time spent with assembly language is, however, valuable.
David Mitchell
> In C you might write "a = b + c" and all the underlying machine code
> will be generated correctly. In FORTH, you must write a whole load of
> lower-level code to achieve the same, any line of which code can
> introduce a difficult-to-find bug.
I'm not sure what you're saying here, I'd just write:
b @ c @ + a !
It's not so intuitive; but that's partly because it's variable based, and
FORTH generally isn't.
That's actually one of the reasons why it tends to run so quickly -
programs tend to be optimised, to an extent, as they're written.
It's hard to give a reasonable example, but if you compare these two
functions written in C and FORTH...
C
=
int smallest(int a, int b)
{
if (a<b) {
return a;
}
else {
return b;
}
}
FORTH
=====
: smallest
2DUP > IF SWAP ENDIF DROP
;
Now I know that these aren't realistic examples, (you'd almost certainly
write something as small as this as a #define using the ?: function in C,
for example), but my point is that you need the register optimisation in
C because you're accessing variables, typically more than once; whereas
in FORTH they just remain on the stack, and you manipulate them using the
stack primitives - which are written to execute as quickly as possible.
If you have a "proper" compiler for FORTH (and they do exist), they
typically optimise the top 'n' stack items into registers (where 'n' can
be anything from 1 to 6), so the FORTH example is pretty-much self-
optimising: a "proper" FORTH compiler generally executes about ten times
as quickly as an interpreter, usually about as fast as C.
This is very handy, as optimisation is one of the greatest sources of
hard-to-find compiler errors.
monty
> name suggests, free).
>
> It's a better language than C, IMO, it's more readable, more consistent,
> runs equally quickly and there as almost as many free components for it
> as C, thanks mainly to Borland.
>
> The best advice I can give you is to pick a language and tools which most
> reduce the possibility of programmer error - and of the four described
> here, that's pascal.
>
> However, if you can find a compiler for it, I'd recommend Ada: it's a
> modern language with lots of high-level features and it was designed to
> allow comprehensive static checking, and to work efficiently in embedded
> systems. I haven't worked with it, though, so I can't recommend it from
> actual experience.
>
> Eiffel is also a very interesting language in that regard - again, I've
> not used it, but I hear very good things about it.
>
> HTH
>
> --
> =======================================================================
> = David --- If you use Microsoft products, you will, inevitably, get
> = Mitchell --- viruses, so please don't add me to your address book.
> =======================================================================
I think a lot of you have missed the point a bit. There are really two
questions here and they are closely related. Before you decide on a
language you have to pick a processor and it's environment. Whether it
be C, C++, Pascal, Forth, Basic or Assembly, only matters if the
langauge is supported by a compiler for the environment you need it
on.
When it comes to many small controllers your choices are usually very
limited: Assembly is alaways a choice, C is usualy also usually a
choice, then things start to thin out a bit after that. Is there even
a Pascal version that cross compiles to a Pic or AVR? I always liked
forth but again the target makes the choice.
C has gotten a lot of bad press but is really as structured as C++ if
the programmer makes it that way. The problem is most programmers try
to get "slick" using C and go to lengths to make it bad, though
usually not intentionally. C++ prevents a lot of that but the overhead
is horrendous when it comes to a small chip. For that matter most C
embedded applications don't even use Malloc() as there is no support
for it in that environment.
For a beginner for small embedded applications I would recommend both
C and the Assem for the target as a learning point. If you already
know Pascal or Forth or C++ you are probably not a beginner :) If you
are a part time hobbist and it is available for your target, Basic is
a viable choice ( use subroutines not goto's). When you want to get
better control shift to C. When your project grows Java and C++ or C#
or ?? become an option, again the target determines your options more
than the language.
Monty
Too_Many_Tools
> name suggests, free).
>
> It's a better language than C, IMO, it's more readable, more consistent,
> runs equally quickly and there as almost as many free components for it
> as C, thanks mainly to Borland.
>
> The best advice I can give you is to pick a language and tools which most
> reduce the possibility of programmer error - and of the four described
> here, that's pascal.
>
> However, if you can find a compiler for it, I'd recommend Ada: it's a
> modern language with lots of high-level features and it was designed to
> allow comprehensive static checking, and to work efficiently in embedded
> systems. I haven't worked with it, though, so I can't recommend it from
> actual experience.
>
> Eiffel is also a very interesting language in that regard - again, I've
> not used it, but I hear very good things about it.
>
> HTH
>
> --
> =======================================================================
> = David --- If you use Microsoft products, you will, inevitably, get
> = Mitchell --- viruses, so please don't add me to your address book.
> =======================================================================
David, thanks for revisiting this discussion.
I agree with your comments and choices.
While I understand the reasons for C's popularity, I consider it to be
a poor language for large programs.
Pascal and other languages like Ada are better.
TMT
David Mitchell
> David, thanks for revisiting this discussion.
You're welcome.
> TMT
Coincidentally, there used to be a pascal compiler marketed by a company
called TMT.
Gordon McComb
>
> I agree with your comments and choices.
>
> While I understand the reasons for C's popularity, I consider it to be
> a poor language for large programs.
>
> Pascal and other languages like Ada are better.
Virtually no one uses straight C these days, and in fact most C
compilers for microcontrollers are C++.
The *best* language for robotics would be one specifically written for
the task. Many people have tried; so far, none have caught on to any
significant degree. I imagine it's because people are still undecided
what a robot should do. Creating libraries, data structures, and other
language elements is still too task-centric. What works for one project
fails miserably for another.
I don't see how Pascal, Ada, C, C++, Basic, Lisp, Cobol, Fortran, Forth,
or any other language is better or worse than another, because it really
comes down to how well the libraries and compiler match the hardware.
There are no standards in robot hardware, so if you were (for example)
coding in Pascal the suitability of the language would depend on such
things as existing libraries for controlling servos, sensors, and other
hardware, or at the least, how willing you are to write these libraries
yourself.
If I were developing a robot with advanced vision analysis I might opt
for a PC with Windows XP, so I could leverage the very powerful
DirectShow architecture. That pretty much limits me to using C++,
because that's about the only language that can tap into the real power
of DirectShow (you can use .NET for record/playback functions, but you
really need C++ to write real-time imaging filters).
Whether or not Pascal/Ada/whatever is a better language is a moot point.
For such a robot described above I can't use these except as wrappers,
so they're off the table from the get-go.
-- Gordon
Gordon McComb
>
> I agree with your comments and choices.
>
> While I understand the reasons for C's popularity, I consider it to be
> a poor language for large programs.
>
> Pascal and other languages like Ada are better.
Virtually no one uses straight C these days, and in fact most C
waynegramlich
> Too_Many_Tools wrote:
>> I agree with your comments and choices.
>>
>> While I understand the reasons for C's popularity, I consider it to be
>> a poor language for large programs.
>>
>> Pascal and other languages like Ada are better.
>
> Virtually no one uses straight C these days, and in fact most C
> compilers for microcontrollers are C++.
I'm not sure that the statement above is true. For example, I never
found a C++ controller for PIC16Fxxx series (not that I would want one.)
I agree with everything else you say below.
> The *best* language for robotics would be one specifically written for
> the task. Many people have tried; so far, none have caught on to any
> significant degree. I imagine it's because people are still undecided
> what a robot should do. Creating libraries, data structures, and other
> language elements is still too task-centric. What works for one project
> fails miserably for another.
>
> I don't see how Pascal, Ada, C, C++, Basic, Lisp, Cobol, Fortran, Forth,
> or any other language is better or worse than another, because it really
> comes down to how well the libraries and compiler match the hardware.
> There are no standards in robot hardware, so if you were (for example)
> coding in Pascal the suitability of the language would depend on such
> things as existing libraries for controlling servos, sensors, and other
> hardware, or at the least, how willing you are to write these libraries
> yourself.
>
> If I were developing a robot with advanced vision analysis I might opt
> for a PC with Windows XP, so I could leverage the very powerful
> DirectShow architecture. That pretty much limits me to using C++,
> because that's about the only language that can tap into the real power
> of DirectShow (you can use .NET for record/playback functions, but you
> really need C++ to write real-time imaging filters).
>
> Whether or not Pascal/Ada/whatever is a better language is a moot point.
> For such a robot described above I can't use these except as wrappers,
> so they're off the table from the get-go.
-Wayne
Joe Pfeiffer
> Too_Many_Tools wrote:
>>
>> I agree with your comments and choices.
>>
>> While I understand the reasons for C's popularity, I consider it to be
>> a poor language for large programs.
>>
>> Pascal and other languages like Ada are better.
>
> Virtually no one uses straight C these days, and in fact most C
> compilers for microcontrollers are C++.
Where "virtually no one" includes the developers of small projects like
the Linux kernel and X11.
--
As we enjoy great advantages from the inventions of others, we should
be glad of an opportunity to serve others by any invention of ours;
and this we should do freely and generously. (Benjamin Franklin)
Gordon McComb
> > Virtually no one uses straight C these days, and in fact most C
> > compilers for microcontrollers are C++.
>
> Where "virtually no one" includes the developers of small projects like
> the Linux kernel and X11.
Sorry. Didn't realize these were considered microcontrollers, and that
this group was no longer about robotics.
-- Gordon
Gordon McComb
> I'm not sure that the statement above is true. For example, I never
> found a C++ controller for PIC16Fxxx series (not that I would want one.)
Okay it might have been an over-simplification for ALL controllers. Then
again, where did Picant go? Didn't they do a C++ compiler for various
PIC chips? Their domain seems now to be parked and unused. Either this
is saying something about the PIC or about C++ compilers! <g>
Anyway, I tend to think of things like the GNU GCC toolchain and
microcontrollers supported by it, e.g. AVR. I should re-educate myself
about the lack of good C++ tools among the (still pricy) compilers for
some of the other controllers people are still using...
Let us not forget that it isn't the compiler that matters, but the
libraries the compiler brings to the table, thus making your job easier.
I happen to think classes are the better way to share and implement
reusable libraries.
Given the limited instruction set of the typical microcontroller, and
its relative lack of hardware (over a microprocessor system), C++ for uC
tends to be much more a concept than a full fledged implementation of
OOP. But the concept is notable. Imagine the state of progress if we
always had to re-invent the wheel each time we developed something new.
I'm fine using someone else's servo class, and adore not having to know
how it works unless I feel the need to futz with it.
I'm not sure why you wouldn't want an object-oriented version of a
compiler for any task, regardless of the target. I guess I've gotten so
used to the paradigm that I now dislike procedural programming. I'm not
knocking it, but if given a choice, I know which one I'd make.
-- Gordon
Joe Pfeiffer
It's just that the claim as stated was overly broad, and there are some
large projects out there that provide pretty easy counterexamples.
Though, as a matter of fact, the SBC mounted on my iRobot Create is a
486 running Linux. And pretty much all the code I've written for it is
written in C.
waynegramlich
> waynegramlich wrote:
>> I'm not sure that the statement above is true. For example, I never
>> found a C++ controller for PIC16Fxxx series (not that I would want one.)
>
> Okay it might have been an over-simplification for ALL controllers. Then
> again, where did Picant go? Didn't they do a C++ compiler for various
> PIC chips? Their domain seems now to be parked and unused. Either this
> is saying something about the PIC or about C++ compilers! <g>
I used to make a living working on the Sun Microsystems C++ compiler.
C++ compilers are big huge complicated beasts. To the best of my
knowledge there have been fewer than 10 successful C++ compiler
implementations.
> Anyway, I tend to think of things like the GNU GCC toolchain and
> microcontrollers supported by it, e.g. AVR. I should re-educate myself
> about the lack of good C++ tools among the (still pricy) compilers for
> some of the other controllers people are still using...
Technically, you can compile C++ code for the AVR using GCC, but I'm not
sure how well supported it is. The supported library for the AVR is for
C, not C++. It must be exciting to support C++ exceptions for the AVR.
> Let us not forget that it isn't the compiler that matters, but the
> libraries the compiler brings to the table, thus making your job easier.
> I happen to think classes are the better way to share and implement
> reusable libraries.
Again, I'm not aware of many C++ libraries tasked towards robotics
for the smaller microcontrollers (e.g. 8-bit and 16-bit.)
Maybe Microsoft Robotics studio? I don't know, maybe somebody else
can point to some C++ robotics libraries.
> Given the limited instruction set of the typical microcontroller, and
> its relative lack of hardware (over a microprocessor system), C++ for uC
> tends to be much more a concept than a full fledged implementation of
> OOP. But the concept is notable. Imagine the state of progress if we
> always had to re-invent the wheel each time we developed something new.
> I'm fine using someone else's servo class, and adore not having to know
> how it works unless I feel the need to futz with it.
Agreed, libraries and classes are great.
> I'm not sure why you wouldn't want an object-oriented version of a
> compiler for any task, regardless of the target. I guess I've gotten so
> used to the paradigm that I now dislike procedural programming. I'm not
> knocking it, but if given a choice, I know which one I'd make.
The only reason for not wanting such a compiler is that it does
not fit. I actually do program my AVR's in an object oriented language.
I just do not use C++ (or Java) because they require very substantial
run-time support.
Please note, I largely agree with you. I just do not think C++ has
penetrated the 8-bit micro controller world with any level of success.
-Wayne
Gordon McComb
> It's just that the claim as stated was overly broad, and there are some
> large projects out there that provide pretty easy counterexamples.
> Though, as a matter of fact, the SBC mounted on my iRobot Create is a
> 486 running Linux. And pretty much all the code I've written for it is
> written in C.
Overly broad AND utterly inaccurate! <g>
I've been too long in one corner of the robotics workshop. Gotta get out
more often to see what other people are doing!
-- Gordon
Gordon McComb
> The only reason for not wanting such a compiler is that it does
> not fit. I actually do program my AVR's in an object oriented language.
> I just do not use C++ (or Java) because they require very substantial
> run-time support.
As the kids say these days, "true dat," and I was being somewhat loose
with the interpretation of "C++." Compilers aren't supposed to call
themselves C++ if they only support a subset (like basic classes and
nothing else).
You wouldn't call ActionScript 3 C++, for example, but it is object
oriented, and supports classes. This is kinda-sorta what I meant (he
said red-faced). So in retrospect, exchange C++ with OOP, and add an
asterisk for dealing with the limited capabilities of the typical uC.
For your AVRs, are you using Wiring by any chance? Wiring is said to be
"simplified C++," though I've never been sure what features are
included/discluded.
If not, what is your language of choice?
As far as handling when exceptions are thrown, I prefer to treat
exceptions as features.
-- Gordon
waynegramlich
> waynegramlich wrote:
>> The only reason for not wanting such a compiler is that it does
>> not fit. I actually do program my AVR's in an object oriented language.
>> I just do not use C++ (or Java) because they require very substantial
>> run-time support.
>
> As the kids say these days, "true dat," and I was being somewhat loose
> with the interpretation of "C++." Compilers aren't supposed to call
> themselves C++ if they only support a subset (like basic classes and
> nothing else).
OK. Fair enough. I was thinking in terms of full ANSI-C++, which
GCC *does* support. There are lots of people who play fast and
loose with what they call their compiler.
> You wouldn't call ActionScript 3 C++, for example, but it is object
> oriented, and supports classes. This is kinda-sorta what I meant (he
> said red-faced). So in retrospect, exchange C++ with OOP, and add an
> asterisk for dealing with the limited capabilities of the typical uC.
Actually, I probably would call it a subset of C++, which I think is
fair and honest.
At our club, there is quite a bit of 8-bit micro-controller usage,
and almost everybody is using some version of C (usually a subset
that does not support floating points, long precision, etc.) To
date, I have not seen our members using C++ subset or OOP languages
for the 8-bit micro controllers yet. Doesn't mean that it is not
happening, just that I have not seen it.
> For your AVRs, are you using Wiring by any chance? Wiring is said to be
> "simplified C++," though I've never been sure what features are
> included/discluded.
I've never heard of Wiring. I'll have to check up on it.
> If not, what is your language of choice?
My hobby is programming languages. I eventually got tired of waiting
for somebody to put together a language with the features I wanted,
so I wrote my own. It is called Easy-C and you can read up on it here,
if you are so inclined:
<http://gramlich.net/projects/easyc/index.html>
Since there is no standard definition of what "object-oriented" means,
some people might not accept my claim that Easy-C is an ojbject-oriented
language. To be specific, I support static method calls and I use
a slightly different syntax to do it:
In C++:
result = object.method(arg, ....);
In Easy-C:
result := method@(object, arg, ...)
Virtual methods are supportable, but it requires some work from the
user to make them happen.
The bottom line is that I like it and I use it. I have used it to
compile code for the x86, MIPS, and AVR computer instruction sets.
> As far as handling when exceptions are thrown, I prefer to treat
> exceptions as features.
I was actually talking in terms of implementing exceptions. They
place a serious burden on the the compiler/linker/run-time system.
It was exciting figuring out how to make all of that work efficiently
back in early '90's.
-Wayne
John Nagle
> waynegramlich wrote:
>> I'm not sure that the statement above is true. For example, I never
>> found a C++ controller for PIC16Fxxx series (not that I would want one.)
>
> Okay it might have been an over-simplification for ALL controllers. Then
> again, where did Picant go? Didn't they do a C++ compiler for various
> PIC chips? Their domain seems now to be parked and unused. Either this
> is saying something about the PIC or about C++ compilers! <g>
>
> Anyway, I tend to think of things like the GNU GCC toolchain and
> microcontrollers supported by it, e.g. AVR. I should re-educate myself
> about the lack of good C++ tools among the (still pricy) compilers for
> some of the other controllers people are still using...
AVR CPUs can be programmed in C++. If you download the Atmel board
support package, you get a whole integrated development environment that
uses GCC.
The "Wiring" project has been supplanted by the "Arduno" cult, which
is a family of AVR boards with their own dialect of C++. The tool chain
is really GCC, with a front end to simplify things a bit.
I can't see using anything smaller than an AVR at this late date.
We're past the Basic Stamp era.
Above the low-end hobbyist level, there's some real-time Java and a
lot of C++. Willow Robotics has a "robotics operating system" which is
just Linux with some publish/subscribe message passing. Stanford and
Caltech like Java.
Boston Dynamics' Big Dog, by the way, uses C++ code on a ruggedized
Pentium 3 on QNX.
John Nagle
monty
>
> The "Wiring" project has been supplanted by the "Arduno" cult, which
> is a family of AVR boards with their own dialect of C++. The tool chain
> is really GCC, with a front end to simplify things a bit.
>
> I can't see using anything smaller than an AVR at this late date.
> We're past the Basic Stamp era.
>
> Above the low-end hobbyist level, there's some real-time Java and a
> lot of C++. Willow Robotics has a "robotics operating system" which is
> just Linux with some publish/subscribe message passing. Stanford and
> Caltech like Java.
>
> Boston Dynamics' Big Dog, by the way, uses C++ code on a ruggedized
> Pentium 3 on QNX.
>
> John Nagle
Funny about that, just because they use GCC doesn't make it C++. It
seems to me if you take away garbage collection and constructors and
the rest from C++ what you have left is "C". There is simply not
enough memory available to do anything useful in a PIC or AVR if you
use a "C++ environment". When all the overhead for true inheritance
and garbage collection and such is used the available code space drops
to near zero for useful work ... in a PIC/AVR environment!
It's true the reuse of code libraries is an advantage but it is not
now, nor never has been, limited to C++. As I stated in my previous
response the use of a language is determined by the environment that
you are running in, not your development environment. If you develop
in a C++ environment but IFDEF out all the C++ constructs you are
still coding in "C" and can make the same errors if you are not
careful that you get in a "C" environment.
C is not a bad language but it can be abused, but then so can most
other languages. Bad code is bad code no matter what environment it is
developed in, some languages tend to minimize the abuse but don't stop
it.
What the bottom line is that C and assembly are the predominant
languages for small controllers, others (including Basic) are used but
when it comes to packing in code to small environments they can't
compete.
My 2 cents worth.
Monty
dhyl...@gmail.com
> Funny about that, just because they use GCC doesn't make it C++. It
> seems to me if you take away garbage collection and constructors and
> the rest from C++ what you have left is "C". There is simply not
> enough memory available to do anything useful in a PIC or AVR if you
> use a "C++ environment". When all the overhead for true inheritance
> and garbage collection and such is used the available code space drops
> to near zero for useful work ... in a PIC/AVR environment!
Well, I can say that C++ can be used and does work on the AVR. The
Arduino use the C++ compilers.
I'm not sure why you're mentioning garbage collection. There is no
garbage collection as part of C++.
Inheritance has zero impact on code size (so I'm not sure what
overheads you're referring to).
Virtual functions cause a per-class vtable to be created, which adds a
small amount of overhead, but it's only one function pointer per
virtual function, and nothing forces you to use virtual functions.
There is an official subset of C++ called Embedded C++, and the C++
support available on the AVR by GCC definitely exceeds that subset.
<http://en.wikipedia.org/wiki/Embedded_C%2B%2B>
I have worked on entire phone GUIs written in Embedded C++ (not on an
AVR, but under linux), so it's still quite a powerful subset of C++.
For me, I really like using C++ for ADT (Abstract Data Types), and for
that, there is no signifancant code overhead compared to coding it in
C.
To use C++ on the AVR, requires a small piece of support code to be
added, the entirety of which I'll include here:
#include <stdlib.h>
void * operator new(size_t size) { return malloc(size); }
void operator delete(void * ptr) { free(ptr); }
__extension__ typedef int __guard __attribute__((mode (__DI__)));
extern "C" int __cxa_guard_acquire(__guard *);
extern "C" void __cxa_guard_release (__guard *);
extern "C" void __cxa_guard_abort (__guard *);
int __cxa_guard_acquire(__guard *g) {return !*(char *)(g);};
void __cxa_guard_release (__guard *g) {*(char *)g = 1;};
void __cxa_guard_abort (__guard *) {};
extern "C" void __cxa_pure_virtual(void);
void __cxa_pure_virtual(void) {};
monty
>
> I'm not sure why you're mentioning garbage collection. There is no
> garbage collection as part of C++.
> #include <stdlib.h>
> void * operator new(size_t size) { return malloc(size); }
> void operator delete(void * ptr) { free(ptr); }
Lets see, I see a call to malloc and free in these functions and you
say there is no garbage collection?? Must be some real magic here if
there is no garbage collection to handle memory allocation. Do you run
to a screaching halt when memory becomes fragmented?
Also try checking out your includes and see what happens when the
extern "C" is handled. I think you will find out that classes go by
the way side and are turned into structures. Most of the libraries I
have looked at that are C compatible are loaded with IFDEF's removing
classes and converting them into global structures and data. There
comes a point when maintenance of this type of code becomes a real
nightmare and should be avoided. Code reuse can easily become code
abuse when to much is tried to make them compatible. In my opinion it
is better to create seperate C/C++ libraries then try to make one
library serve both languages. This may shock some but the more you try
to cram ino a page of code the more of a maintenance problem it
becomes. I firmly believe that the maximum length of any routine is 2
text pages, more than that it becomes much more difficult to maintain
and debug.
When you are working on a processor that counts it RAM in bytes not
Mega bytes even a "small virtual table" is an excessive waste of
valuble resources. Let me get things straight, I have nothing against C
++ but every language has it's place. How much code can be reused in a
1K program memory anyway. A good set of fully debugged libraries is
much more practical. Before anyone jumbs on me for the paragraph above
in relation to thisone I know JSR's eat both types of memory but a
balance needs to be reached between code maintainability and code
space.
I also have yet to see an embedded linux environment on a PIC. Whole
different world.
As I have said in all my posts, each language has it's own use and I
believe the orginal question was which language is best for robotics.
Every robot I have built use several small controllers communicating
with a central core to handle overall logic. When these seperate
functions get rolled into a single small controller every byte of RAM
and Code space becomes precious. Therefore C/ASM in the controllers
and if there is one, C++ or Java in the core. They really are two
different worlds when it comes to which language to use.
Monty
waynegramlich
> On Jan 8, 7:43 am, "dhyla...@gmail.com" <dhyla...@gmail.com> wrote:
>
>> I'm not sure why you're mentioning garbage collection. There is no
>> garbage collection as part of C++.
>
>> #include <stdlib.h>
>> void * operator new(size_t size) { return malloc(size); }
>> void operator delete(void * ptr) { free(ptr); }
>
>
> Lets see, I see a call to malloc and free in these functions and you
> say there is no garbage collection?? Must be some real magic here if
> there is no garbage collection to handle memory allocation. Do you run
> to a screaching halt when memory becomes fragmented?
The commonly excepted definition of garbage collection is the
automatic freeing of unused allocated memory. The C++ language
specification does not support garbage collection. Conversely,
Java *requires* garbage collection.
-Wayne
Joe Pfeiffer
> On Jan 8, 7:43�am, "dhyla...@gmail.com" <dhyla...@gmail.com> wrote:
>
>>
>> I'm not sure why you're mentioning garbage collection. There is no
>> garbage collection as part of C++.
>
>> #include <stdlib.h>
>> void * operator new(size_t size) { return malloc(size); }
>> void operator delete(void * ptr) { free(ptr); }
>
>
> Lets see, I see a call to malloc and free in these functions and you
> say there is no garbage collection?? Must be some real magic here if
> there is no garbage collection to handle memory allocation. Do you run
> to a screaching halt when memory becomes fragmented?
You're using "garbage collection" in an idiosyncratic way. Normally,
the term is used for a system that simply "notices" that a data
structure is no longer accessible, and frees it for itself.
The GNU libc implementation of free() will notice and coalesce adjacent
freed blocks, but if memory gets fragmented... yep, system comes to a
screeching halt.
> Also try checking out your includes and see what happens when the
> extern "C" is handled. I think you will find out that classes go by
> the way side and are turned into structures. Most of the libraries I
> have looked at that are C compatible are loaded with IFDEF's removing
> classes and converting them into global structures and data. There
> comes a point when maintenance of this type of code becomes a real
> nightmare and should be avoided. Code reuse can easily become code
> abuse when to much is tried to make them compatible. In my opinion it
> is better to create seperate C/C++ libraries then try to make one
> library serve both languages. This may shock some but the more you try
> to cram ino a page of code the more of a maintenance problem it
> becomes. I firmly believe that the maximum length of any routine is 2
> text pages, more than that it becomes much more difficult to maintain
> and debug.
I really like C libraries written to be pseudo object-oriented, and then
a thin C++ interface layer on top of them.
> When you are working on a processor that counts it RAM in bytes not
> Mega bytes even a "small virtual table" is an excessive waste of
> valuble resources. Let me get things straight, I have nothing against C
> ++ but every language has it's place. How much code can be reused in a
> 1K program memory anyway. A good set of fully debugged libraries is
> much more practical. Before anyone jumbs on me for the paragraph above
> in relation to thisone I know JSR's eat both types of memory but a
> balance needs to be reached between code maintainability and code
> space.
Yes.
> I also have yet to see an embedded linux environment on a PIC. Whole
> different world.
That would be... interesting :)
> As I have said in all my posts, each language has it's own use and I
> believe the orginal question was which language is best for robotics.
> Every robot I have built use several small controllers communicating
> with a central core to handle overall logic. When these seperate
> functions get rolled into a single small controller every byte of RAM
> and Code space becomes precious. Therefore C/ASM in the controllers
> and if there is one, C++ or Java in the core. They really are two
> different worlds when it comes to which language to use.
>
> Monty
>
--
monty
>
> > Lets see, I see a call to malloc and free in these functions and you
> > say there is no garbage collection?? Must be some real magic here if
> > there is no garbage collection to handle memory allocation. Do you run
> > to a screaching halt when memory becomes fragmented?
>
> You're using "garbage collection" in an idiosyncratic way. Normally,
> the term is used for a system that simply "notices" that a data
> structure is no longer accessible, and frees it for itself.
>
> The GNU libc implementation of free() will notice and coalesce adjacent
> freed blocks, but if memory gets fragmented... yep, system comes to a
> screeching halt.
>
I guess I'm showing my age because before C++ came around "garbage
collection" was the term we used for the process to manage all those
disjoint blocks of memory created by repeated calls to malloc/free.
To be honest most of the work I have done does not utilize free/malloc
calls. The memory is simply too tight to use that overhead. C can
exist quite well without those tools, I’m pretty sure C++ cannot exist
without them at all, I may be wrong. You learn to manage memory
without them.
Most “embedded programmers” today expect an OS or RTOS to exist to
manage a lot of this stuff for them. Embedded programming is a term
that has morphed over the years. It no longer means the same thing now
it did 15 years ago, again “a whole different world” then and now.
What most consider an embedded environment now is: lot of memory
both code and ram, a SD disk, an LCD interface, etc. Most of you out
there have only seen my first computer in history books (KIM-1 using a
teletype capable printer/terminal, 20 ma loop, for interface).
My first post was to say that what determines the first language to
learn still holds true: It depends on the environment you will or
expect to be working in!
I still like Forth though I haven’t used it for years :):)
Monty
John Nagle
> On Jan 8, 10:33 am, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
>
>>> Lets see, I see a call to malloc and free in these functions and you
> I guess I'm showing my age because before C++ came around "garbage
> collection" was the term we used for the process to manage all those
> disjoint blocks of memory created by repeated calls to malloc/free.
The term "garbage collection" has been used for automatic recovery of
unclaimed storage since McCarthy's LISP 1.5 book in the early 1960s.
Knuth discusses storage management in "Fundamental algorithms",
from 1967, and does not use the term "garbage collection" in the
context of systems where the programmer must explicitly release space.
> To be honest most of the work I have done does not utilize free/malloc
> calls. The memory is simply too tight to use that overhead. C can
> exist quite well without those tools, I�m pretty sure C++ cannot exist
> without them at all, I may be wrong. You learn to manage memory
> without them.
In embedded work, it's quite common to allocate new objects at startup,
and never release them. This is as effective with C++ as it is in C,
plus you get object initialization. It's very useful for things
that have some configuration at startup. Embedded Java programmers
often work this way, so as not to invoke Java's garbage collector
at all.
Active use of dynamic memory does require more memory, but that's
a scaling issue, not a language issue.
> Most �embedded programmers� today expect an OS or RTOS to exist to
> manage a lot of this stuff for them. Embedded programming is a term
> that has morphed over the years. It no longer means the same thing now
> it did 15 years ago, again �a whole different world� then and now.
People are still writing very tiny embedded programs on very tiny
processors. That's fine, but it's not the upper levels of control.
Today's tiny programs probably control one motor. Many R/C servos
have a CPU in them. All the Bioloid ones do. But they're not
in overall charge of the robot.
John Nagle
dhyl...@gmail.com
> > > Lets see, I see a call to malloc and free in these functions and you
> > > say there is no garbage collection?? Must be some real magic here if
> > > there is no garbage collection to handle memory allocation. Do you run
> > > to a screaching halt when memory becomes fragmented?
>
> > You're using "garbage collection" in an idiosyncratic way. Normally,
> > the term is used for a system that simply "notices" that a data
> > structure is no longer accessible, and frees it for itself.
>
> > The GNU libc implementation of free() will notice and coalesce adjacent
> > freed blocks, but if memory gets fragmented... yep, system comes to a
> > screeching halt.
>
> I guess I'm showing my age because before C++ came around "garbage
> collection" was the term we used for the process to manage all those
> disjoint blocks of memory created by repeated calls to malloc/free.
> To be honest most of the work I have done does not utilize free/malloc
> calls. The memory is simply too tight to use that overhead. C can
> exist quite well without those tools, I’m pretty sure C++ cannot exist
> without them at all, I may be wrong. You learn to manage memory
> without them.
Ahh, we just call that the heap, or dynamic memory allocation (use of
free/new and friends).
C++ has dynamic memory alloaction, just like C. In todays world
garbage collection is used in langauges like Smalltalk, Java, and
lisp.
The difference is whether the allocated objects are freed explicitly
(like C and C++ do) or automatically (garbage collection). Garbage
collection has much more overhead than just a simple heap, which in
turn has much more overhead than global variables.
C++ has no more requirement of the heap than C does. Just like you can
write perfectly good programs in C which don't use the heap, you can
also write perfectly good programs in C++ which don't use the heap.
Whether you choose to use the heap has more to do with your data and
data structures, and nothing to do with the language (at least when
we're talking about C and C++). Admittedly, many C++ programmers have
some burned in belief that they must use new and delete for all
variables, but that's just due to bad teaching at school.
C++ has been much maligned about being bloated and slow, when in fact
its the way the language is used that makes the code bloated and slow,
not the language itself.
> Most “embedded programmers” today expect an OS or RTOS to exist to
> manage a lot of this stuff for them. Embedded programming is a term
> that has morphed over the years. It no longer means the same thing now
> it did 15 years ago, again “a whole different world” then and now.
> What most consider an embedded environment now is: lot of memory
> both code and ram, a SD disk, an LCD interface, etc. Most of you out
> there have only seen my first computer in history books (KIM-1 using a
> teletype capable printer/terminal, 20 ma loop, for interface).
I do embedded programming professionally, and you still see both types
of devices, the small one with limited memory, and no OS, and the
bigger one, often running linux with a full OS. It really depends on
what your're doing.
Dave Hylands
monty
>
> In embedded work, it's quite common to allocate new objects at startup,
> and never release them. This is as effective with C++ as it is in C,
> plus you get object initialization. It's very useful for things
> that have some configuration at startup. Embedded Java programmers
> often work this way, so as not to invoke Java's garbage collector
> at all.
>
> Active use of dynamic memory does require more memory, but that's
> a scaling issue, not a language issue.
>
> processors. That's fine, but it's not the upper levels of control.
> Today's tiny programs probably control one motor. Many R/C servos
> have a CPU in them. All the Bioloid ones do. But they're not
> in overall charge of the robot.
>
> John Nagle
John why do I get the feeling you are in upper management and have
lost site of the "real world". Do you think Micro chip would have
spent the money to develop a picaxe chip if there was not a rather
large market for "tiny" processors? The majority of control is done by
tiny processors, do yopu think the code writes it's self? C++ has
become a mangerial chopping block for software engineers. I really
believe they have lost site of the fact that C++ simply wastes
resources in small environments but they have been caught up in the
hype that you can't maintain "C" code and you have to develop in C++.
What most mangers don't realize is that yes they use a C++ compiler
but the developers write in C far more code then is believed. Just
because you wrap the code in a C++ compiler doesn't make it C++!
...and for those of you that have forgotten this tread is not about C+
+ vs C it was the question :
>When I reach a more advanced level, I know I will need programming
>skills. I haven't done any programming apart from some BASIC at
>school 20 years ago! But I'm willing to learn. So, what would be the
>best programming language for me to learn in connection with hobbyist
>robotics? C++? Some form of BASIC? Or something else entirely?
And I responded with the choice should be based on the environment you
are programming for!
BTW my small controller handles PWM output to 2 motors, reads 2 Quad
encoders and tracks position info including move to location commands,
handles the I2C communications with the central controller,also a
RS232 for link for what ever, and several failsafe bump sensors. For
small robots this small controller has room in it to completly handle
the robot in solving a 6x12 maze but currently is not used that way. I
opted for a Propeller chip board to coordinate the motor controller
and several IR distance sensors. Oops another language enters the
fray, SPIN!
Monty
Joe Pfeiffer
> On Jan 8, 10:33 am, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
>
>>
>> > Lets see, I see a call to malloc and free in these functions and you
>> > say there is no garbage collection?? Must be some real magic here if
>> > there is no garbage collection to handle memory allocation. Do you run
>> > to a screaching halt when memory becomes fragmented?
>>
>> You're using "garbage collection" in an idiosyncratic way. Normally,
>> the term is used for a system that simply "notices" that a data
>> structure is no longer accessible, and frees it for itself.
>>
>> The GNU libc implementation of free() will notice and coalesce adjacent
>> freed blocks, but if memory gets fragmented... yep, system comes to a
>> screeching halt.
>>
> I guess I'm showing my age because before C++ came around "garbage
> collection" was the term we used for the process to manage all those
> disjoint blocks of memory created by repeated calls to malloc/free.
> To be honest most of the work I have done does not utilize free/malloc
> calls. The memory is simply too tight to use that overhead. C can
> exist quite well without those tools, I’m pretty sure C++ cannot exist
> without them at all, I may be wrong. You learn to manage memory
> without them.
No... I first heard garbage collection used to mean automatic
deallocation when I learned LISP in the mid 1970s. Your use of it to
mean more general memory management is the first time I've ever
encountered that usage.
> Most “embedded programmers” today expect an OS or RTOS to exist to
> manage a lot of this stuff for them. Embedded programming is a term
> that has morphed over the years. It no longer means the same thing now
> it did 15 years ago, again “a whole different world” then and now.
> What most consider an embedded environment now is: lot of memory
> both code and ram, a SD disk, an LCD interface, etc. Most of you out
> there have only seen my first computer in history books (KIM-1 using a
> teletype capable printer/terminal, 20 ma loop, for interface).
There's still a whole world out there that's lower-end than the sorts of
RTOSs you're describing. I wouldn't want to guess which has more
developers, though.
> My first post was to say that what determines the first language to
> learn still holds true: It depends on the environment you will or
> expect to be working in!
> I still like Forth though I haven’t used it for years :):)
>
> Monty
--
Gordon McComb
> > As far as handling when exceptions are thrown, I prefer to treat
> > exceptions as features.
>
> I was actually talking in terms of implementing exceptions. They
> place a serious burden on the the compiler/linker/run-time system.
What I meant here was tongue-in-cheek, as in "if it acts broken, it's a
*feature*!
The best unhandled exception (that doesn't crash the program) is the one
that looks like it was meant to happen. I live for those, and I don't
charge my clients any extra for them! :-)
-- Gordon
Ian Clifton
david.robo...@googlemail.com says...
> However, if you can find a compiler for it, I'd recommend Ada: it's a
> modern language with lots of high-level features and it was designed to
> allow comprehensive static checking, and to work efficiently in embedded
> actual experience.
There's a free Ada compiler, called GNAT, bundled into GCC - in most
Linux installations it's in an additional package, usually called
something like gcc-ada or gnat-gcc. On Linux or Windows it's a really
solid and up to date compiler. Like GCC it can target AVR, I don't have
(yet) much experience of this embedded aspect of the GNAT Ada compiler,
but I know it can be done.
--
Ian
David Mitchell
Thanks for the information.
"jdpetrey<REM...@raytheon.com
Also you can download the latest Ada 2005 from this site (for free):
http://libre.adacore.com/libre/
Jerry
Sp...@controlq.com
> Date: Thu, 20 May 2010 08:23:57 -0700
> From: "jdpetrey<REMOVE_TO_REPLY>"@raytheon.com
> Reply-To: "jdpetrey @raytheon.com" <REMOVE_TO_REPLY>
> Newsgroups: comp.robotics.misc, uk.tech.robotics
> Subject: Re: Which programming language to learn
When ADA first came out, we used to joke amoungst the system programmers
where I worked that FORTRAN and COBOL were legal subsets of Ada. It is a
very big language, but the package idea is kind of neat.
As for a first language for embedded ... why not just buy into the Arduino
stuff, and use the Java based Wiring/Processing? Processing is a
perfectly good language, provided you are using AVR's exclusively, and in
particular the Arduino.
As for a single language which runs everywhere ... ANSI C is hard to beat.
The gotchas concerning the pointer and memory management notwithstanding,
C compilers are everywhere, cost from $0 to $little, and generate
reasonably efficient code.
Of course, I like Forth too ... but YMMV 8-)