Which programming language to learn

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

=A0 =A0 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

Hi Monty,

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.

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 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 =3D 1;}; void __cxa_guard_abort (__guard *) {}; extern "C" void __cxa_pure_virtual(void); void __cxa_pure_virtual(void) {};

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

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

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

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 really like C libraries written to be pseudo object-oriented, and then a thin C++ interface layer on top of them.

Yes.

That would be... interesting :)

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=92m pretty sure C++ cannot exist without them at all, I may be wrong. You learn to manage memory without them.

Most =93embedded programmers=94 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 =93a whole different world=94 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=92t used it for years :):)

Monty

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.

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.

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

Hi Monty,

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.

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

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 :

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

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.

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.

What I meant here was tongue-in-cheek, as in "if it acts broken, it's a

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

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.

Thanks for the information.

Also you can download the latest Ada 2005 from this site (for free):

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-)