Pages

I totally lost you there, Joe. Honestly. Knowing you (netwise), quite good I think, I suppose there is some really to-the-point wittiness or sarcasm somewhere in there regarding some mistake I made, but I cant spot it.

I have tried Googling "Smileys Jeep gas shortage bottom Pacific" with and without "driver nuts" but came up with nothing..

Help this stupid Swede out, and give me a clue. Please?!

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

It wasn't aimed at you, but an attempt to wisecrack about getting into details like char * while using the wrong vehicle for the job in the first place. Some people want to use C++ as C without studying the basics or the philosophical differences between procedural versus object oriented programming. Not pointed at you, just a poor joke about other folks who want to use C++ when they don't seem to know anything about why one would choose C++ over C.

It wasn't aimed at you, but an attempt to wisecrack about getting into details like char * while using the wrong vehicle for the job in the first place. Some people want to use C++ as C without studying the basics or the philosophical differences between procedural versus object oriented programming. Not pointed at you, just a poor joke about other folks who want to use C++ when they don't seem to know anything about why one would choose C++ over C.

Sorry,
Smiley

So.. i guess you're talking about me.. are not you? And i wonder, why does a philosopher (haha) say that other folks don't know anything about programming paradigms without asking them first?

OK, I'd actually like to see a bit more, eg the whole of the implementation of the operator overload, a declaration/creation of an Lcd object and a call/use of the operator.

I dont have AVR Studio handy right now (just taking a break with working overtime). But I did pull together this small test in MS VC++ which works like a charm. I of-course simulate sending the characters to the LCD proper with a call to putchar, but apart from that I suppose I am close to what you have?

I will try something similar in AVR Studio when I get home, if I'm not too tired.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

It wasn't aimed at you, but an attempt to wisecrack about getting into details like char * while using the wrong vehicle for the job in the first place.

That's okay, Joe. I wasn't upset but rather in wisecrack mode myself. Still, and you know this, my position is that many (dare I say "most"?) times C++ is just as good vehicle as C for embedded systems. We might then be in a situation where someone uses an appropriate vehicle but does not know why (bad), and maybe how to operate it (worse).

Please note that I am not accusing JSkywalker being in either situation, but merely dwelling on Joes scenario in general!

Quote:

Sorry

No need to be, Joe. If you actually succeed in hurting me for real, we will settle that in a PM or two. No need for old grumpy beards to fight such things out in public. Anfd you haven't even gotten close yet. :wink:

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

1) Put the Lcd class in a C++ file, and in that file also put a global function test() that exercises the overloaded operator and gave that function C linkage (so that it can be called from main() that is in a C file):

2) wrote a simple main.c, containing main() that calls test(). No, I didnt bother to create a header file for the test() function. Call me sloppy if you like...

//main.c
#include
void test();
int main(void)
{
test();
return 0;
}

3) Fiddled a bit with the makefile before I got it right (it's been a while since my last experiments with C++ on AVRs).

4) Built the whole shebang, started up AVR Studio, loaded the ELF file and stepped through the code. I see it looping inside the overloaded Lcd::operator<< outputting the chars to PORTB one after the other.

A total success as far as I am concerned.

So now tell us in similar detail, and preferrably in a likewise minimal test/demo project, what your problem is.

Attachment(s):

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Hello Anyone,
doing embedded stuff with winCE for some time, now i'm back to 8 bit uC but won't miss c++ anymore. Thanks to a few hints from this great thread i'm quite happy now with AVRStudio and C++. Debugging is not as comfortable as with VisualStudio, but in former time we were happy when we had a console for debug output.

Now i would like to do some things like wrapping the peripherals i work with in C++ classes, or create waitable events and stuff.

Therefore it would be necessary to hook the handler methods of some objects to certain ISR vectors.
The only approach coming to my mind would be a dispatcher class. I could create some ugly file with all the ISR handlers in it, which call a static function of this dispatcher class, forwarding some ID or the current IP value to it, to tell which ISR was firing. Objects could then register their instance pointer and the address of a handler method to a global object of that dispatcher class.

This is of course ugly and absolutely not uC-like. Probably you cracks can tell a much better way. Any ideas?

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

I belive that readers of this forum would appreciate some concrete, AVR-specific examples that would allow for a quantitative comparison between C and C++ implementation of essentially the same problem specification.

To draw a fair comparison, one would need two equivalent AVR projects designed in object-oriented way, one in C and the other in C++. Otherwise, one would compare different programming paradigms and designs, not the direct impact of the programming language and compiler.

provide a unique opportunity to quantitatively compare the impact of C++. Specifically, the "QDK/C AVR-GNU" and "QDK/C++ AVR-GNU" projects use object-oriented designs with classes and single inheritance. They are both based on a small state-machine framework on top of which runs the classic "Dining Philosophers Problem" test application consisting of five Philosopher state machines and one Table state machine. The framework code consists mostly of a conditional logic to execute hierarchical state machines as well as an event queue, a timer module, and a tiny preemptive kernel. The Dining Philosophers application consists of state machines. I believe that this code is quite representative for typical projects that run on AVRmega MCUs. (These specific projects have been compiled for the AVR Butterfly board with the AVRmega169 MCU.)

So, here is the quantitative size comparison for the WinAVR/avr-gcc compiler (data taken from the map files in the release configuration):

The C++ code uses the "Embedded C++" subset, which avoids exceptions and templates leaving basically only the object-oriented features (classes, inheritance, and virtual functions). Also, the C++ code is not using new and delete (and the C code is not using malloc and free).

The code size increase of 14% of C++ compared to C is typical, although for other compilers I've seen an increase of only about 5% for the same "Dining Philosophers" project.

However, the data size increase of 40 bytes is unusually high. I would expect an increase of some 12 bytes for the virtual pointers stored inside the 6 state machine objects that have virtual tables. The mapfiles indicate that the WinAVR compiler allocates virtual tables in the data space (RAM), which is not optimal because v-tables are synthesized at compile time and can typically be stored in ROM. I'm not aware of any compiler options for WinAVR to control placement of virtual tables. Perhaps someone knows how to force the v-tables into the program space (ROM)?

Finally, I hope that my post could help dispel the widespread belief that you can't do object-oriented (or at least object-based) programming in C. In fact, it is quite easy to implement classes and single inheritance in C. I've blogged about it at EmbeddedGurus.net:

The mapfiles indicate that the WinAVR compiler allocates virtual tables in the data space (RAM), which is not optimal because v-tables are synthesized at compile time and can typically be stored in ROM. I'm not aware of any compiler options for WinAVR to control placement of virtual tables. Perhaps someone knows how to force the v-tables into the program space (ROM)?

AFAIK there is no way to get avr-gcc to store the V-tables in ROM (ie in flash memory). This is a performance hit that you get when using C++ (with the avr-gcc compiler) on AVRs.

Thank you for this post. I'll try to find some time to analyze in more detail what constitutes the increases in code and data size.

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

I took a quick look at the code. It seems it wasn't written as a C++ program. I'd guess it was either a quick copy from C code or it was written by a C programmer masquerading as a C++ programmer. I don't know how that would affect the code size.

I'm reminded of a task switching kernel we used at my previous job. It was taken from Dr. Dobbs Journal. It was written in the C language but it was obviously written by a Fortran programmer. I re-wrote every line of code, which typically happens when I use someone elses code. It was buggy too. It suffered from the "priority inversion" problem. Once fixed and cleaned up, it was pretty neat.

I browsed through this thread and failed to find source files where this discussion would be captured. Are those available anywhere? I could do a shot and upload something I have been using - based on the topmost parts of this thread. However, I am rather new in C++ and especially in embedded environment. I am not sure how *right* my files would be and certainly would appreciate more experienced developers to confirm or fix the files to a good shape.

It would also be nice to have these files available on the first post or other easily found location.

When just starting out with C++ and embedded programming it's easier to start with single thread programs. So using the -fno-threadsafe-statics switch will allow you to bypass the __cxa_guard stuff for a while. With embedded systems __cxa_guard wont be standard and will depend a lot on how the program is implemented. The best you can do is create stub files that can be filled in later when the specifics of the program/RTOS are known.

Has anybody got this to work with avr studio 5?
I couldn't find a way to configure a project for C++. I started a new project and added C++ files to it, but they didn't compile, they weren't even INCLUDED in the list of files to BE compiled, even though they were added to the project.

Hello. Brilliant post; thanks loads for all the information. I'm trying to use new[] and delete[] on an Arduino (using Eclipse) and I think that native support for new[] and delete[] might have made some progress since the original post at the top of this thread.

Specifically, on avr-gcc 4.7.0 (installed on the latest version of Ubuntu: 12.10) it appears that new, new[], delete and delete[] all work out of the box.

But on avr-g++ 4.3.2 (installed by latest version of the Arduino IDE on Windows: 1.0.1) it appears that new and delete work out of the box but new[] and delete[] produce a undefined reference to `operator new[](unsigned int)' error.

Please may I ask two specific questions:

Firstly, is there any way to automatically detect whether new[] and delete[] are already defined? (e.g. a preprocessor directive of some sort)? For example, could we do something like #ifndef _OPERATOR_NEW_[]_ ?!

Secondly, on a platform which already has native new and delete but doesn't have new[] and delete[], should we make use of new and delete and our definitions of new[] and delete[]? e.g. something like this (I'm rather new at this game of manually defining new[] and delete[] so forgive me if this is a dumb suggestion):

Firstly, is there any way to automatically detect whether new[] and delete[] are already defined? (e.g. a preprocessor directive of some sort)? For example, could we do something like #ifndef _OPERATOR_NEW_[]_ ?!

This is not the place to discuss this - this thread serves to hold long time information that will be of benefit to all users of avr-g++. For specific usage questions start a separate (non sticky) thread.

cc1plus is the actual c++ compiler, so you shouldn't assume support just from that. Since the compiler needs to know that new is a special keyword even if there is no library present that supports it.

Ah, cool, thanks. That's interesting. So where do you think new[] and delete[] might be defined on my Ubuntu 12.10 system? (new[] and delete[] work out-of-the box on Ubuntu 12.10... the only reason I'm having to define them again is for folks on older systems).

cc1plus is the actual c++ compiler, so you shouldn't assume support just from that. Since the compiler needs to know that new is a special keyword even if there is no library present that supports it.

Ah, cool, thanks. That's interesting. So where do you think new[] and delete[] might be defined on my Ubuntu 12.10 system? (new[] and delete[] work out-of-the box on Ubuntu 12.10... the only reason I'm having to define them again is for folks on older systems).

I'm not sure where exactly it would be but should be in a library or object file somewhere. I believe looking at the Map file will tell you exactly which library file the function new was pulled in from.

This is not the correct thread to diagnose problems about installing avr-gcc. Start a new thread and in it give more detail about what you are trying to do and what does not work. For example where did you get the avr-gcc you are trying to use on Win7 and what happens when you try to install. Do NOT answer in this thread - start a new one with clearer description.