AVR and C++

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

Does the GCC compiler for AVR support C++ or only C? I want to have a play with using C++ in an embedded environment for a change just for learning sake...

Cheers

Ashley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup... It does work! To get a C++ project compiling in AVR Studio:

1 - Start a new gcc project.
2 - In the Project->Configuration Options->Custom Options, untick use WinAVR.
3 - Set the avr-gcc path to "winavr install directory"\bin\avr-g++.exe
4 - Set the make path to "winavr install directory"\utils\bin\make.exe

Done...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ashley!

This has been up here before. There are a few tricks that you might need eventually, eg. implementeing support for new and delete (and maybe their vector equivalents). Some other tricks has also been mentioned in earlier threads.

Do a search.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"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
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's actually a tutorial on this:

[TUT] [C++] AVR C++ Micro How-To

Best of luck!

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thats a good post... Wonder why I didn't find it in my search? Anyways, I will have more of a play and see how it goes. Thanks for the help...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As that thread says, it really ought to be made a sticky or used to form a tutorial at the very least.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Wonder why I didn't find it in my search?

Because unfortunately the forum search function can't find the string "C++".

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With C++, wouldn't one need an AVR with a LOT of RAM, or avoid things which trigger lots of malloc() and free(), especially for irregularly sized objects?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well yes, but that would apply with C also.

It's a confusing subject and I can't explain it well.

I'll just say that I use "new" at startup to construct classes that persist for the duration. I don't use delete. As always, temporary classes or other objects can be put on the stack.

I don't include malloc and free in my code because I don't need it and it consumes memory. I use a simple new operator function that allocates memory from the heap. I don't have anything that puts the memory back on the heap, and I don't need it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
With C++, wouldn't one need an AVR with a LOT of RAM, or avoid things which trigger lots of malloc() and free(), especially for irregularly sized objects?
One is not required to use all the features of C++.
Neither namespaces nor templates
require malloc, free, new or delete.
Care might be required with templates.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have 36k RAM on my board so that will improve the situation only. I have also now declared the new and delete operators to use my own custom heap management (works basically the same as malloc but allows you to see what is going). The application I was hoping to change to object oriented was already stressing the M128 so it is time to upgrade...

So far I havn't found any problems using C++ in the 8 bit AVR. Even AVR studio seems to behave quite well. The funny thing is the debugger wont go into the class constructor but will the go into the base classes constructor, but hey I should be happy it works as well as it does considering it wasn't designed for C++.

I have decided to move my C++ learning onto my Xilinx board and continue playing on that. It has 64MB of RAM and uses Eclipse IDE so probably better for playing and learning.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ashesman wrote:
The funny thing is the debugger wont go into the class constructor but will the go into the base classes constructor,

Welcome to the C++ club. As you've noticed, the rest of the world does it's best to discourage us, but we persist. :)

I've noticed AVR Studio won't usually step into constructors, but occasionally it does. I never figured out the difference. I haven't used AVR Studio much lately so I don't remember the details of how I debugged constructors, but I know I did it. One thing I recall is putting a breakpoint in the constructor. Another thing I did was put the constructor code into another function and call that function from the constructor. Maybe it steps into that function. I don't remember.

Another thing I found with the debugger is it doesn't see class data members. If I want to see the data I copy it into something else. Externals or automatics, I guess.

There ought to be a GCC C++ hints and tips sticky. One thing you will find is GCC makes two copies of the constructor and destructor if you put them into the .cpp file. But if you put them into the header file it inlines them so this "automatic" duplication doesn't occur. That works great if it's a class that's only instantiated once, or maybe two or three times.

Of course any class function that is only called once can be put into the header file. Sometimes it saves memory and sometimes it doesn't. But always it's more convenient. At least I find it so. I've got a bunch of classes that exist only in header files. It makes coding easy and quick, with no duplication of function headers in two files, and no scoping either. When I invent C+++, everything will be that way. :)

I just remembered one other thing about GCC C++. Don't use virtual functions unless you have a lot of program memory and a huge amount of RAM. I assume there's a bug there somewhere.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

steve17 wrote:
ashesman wrote:
The funny thing is the debugger wont go into the class constructor but will the go into the base classes constructor,

[snip]

I've noticed AVR Studio won't usually step into constructors, but occasionally it does. I never figured out the difference. I haven't used AVR Studio much lately so I don't remember the details of how I debugged constructors, but I know I did it. One thing I recall is putting a breakpoint in the constructor. Another thing I did was put the constructor code into another function and call that function from the constructor. Maybe it steps into that function. I don't remember.

[snip]

There ought to be a GCC C++ hints and tips sticky. One thing you will find is GCC makes two copies of the constructor and destructor if you put them into the .cpp file. But if you put them into the header file it inlines them so this "automatic" duplication doesn't occur. That works great if it's a class that's only instantiated once, or maybe two or three times.


I seem to recall that these two issues are related. Here's what I believe is a related post: http://gcc.gnu.org/ml/gcc-prs/2003-04/msg01207.html

Essentially the "double constructor" is a bug in gcc which is compounded by the fact that in gdb the breakpoint is placed on the constructor copy that never gets accessed.

--Phil.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

follower wrote:

Essentially the "double constructor" is a bug in gcc which is compounded by the fact that in gdb the breakpoint is placed on the constructor copy that never gets accessed.

--Phil.

I think you are right. I tried stepping into an in-line constructor and that worked okay. I guess AVR Studio's debugger works like GDB in this regard.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

follower wrote:
steve17 wrote:
ashesman wrote:
The funny thing is the debugger wont go into the class constructor but will the go into the base classes constructor,

[snip]

I've noticed AVR Studio won't usually step into constructors, but occasionally it does. I never figured out the difference. I haven't used AVR Studio much lately so I don't remember the details of how I debugged constructors, but I know I did it. One thing I recall is putting a breakpoint in the constructor. Another thing I did was put the constructor code into another function and call that function from the constructor. Maybe it steps into that function. I don't remember.

[snip]

There ought to be a GCC C++ hints and tips sticky. One thing you will find is GCC makes two copies of the constructor and destructor if you put them into the .cpp file. But if you put them into the header file it inlines them so this "automatic" duplication doesn't occur. That works great if it's a class that's only instantiated once, or maybe two or three times.


I seem to recall that these two issues are related. Here's what I believe is a related post: http://gcc.gnu.org/ml/gcc-prs/2003-04/msg01207.html

Essentially the "double constructor" is a bug in gcc which is compounded by the fact that in gdb the breakpoint is placed on the constructor copy that never gets accessed.

I think that there was a thread on this earlier.
IIRC the current gnu C++ ABI requires three default constructors.
They are supposedly for three different things,
but I was never clear on what different things.
From a reference from this thread,
I gather that at least two of them are required to be in different sections or something,
even if, as is the usual case, they are otherwise identical.
That would seem to make it very difficult to fix without changing the ABI.

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I read something about that. All I know is when I put a constructor in a .cpp file, there will be two identical ones in the .lst file. When I put the constructor in the header file, making it eligible for inlineing, there is no constructor in the .lst file.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another problem that I've found recently is that the AVRStudio debugger will only do source-line debugging in the .text linker section.

The default for C++ constructors is to be put into the .ctors section and the destructors into the .dtors section.

I came across this when I tried putting all of my function pointer targets into a single section (on an ATmega2560, this is important). Simply moving the code from the default .text section to my .fptr_target section made the code "invisible" to the debugger.

You can debug in assembly, but not source-line.

I've submitted this as a bug the AVRStudio folks.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Adding these two switches below removes the extra constructor and the destructors.

-ffunction-sections
-Wl,--gc-sections
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's a blog of someone who say's he fixed the breakpoint problem with GDB.

http://vladimir_prus.blogspot.co...