Is it ever gonna be possible to use C++ for coding PICs? Is there any hardware limitations that prevents us to use C++? How much the size of generated .hex file and running time of the program increase when we use C++ instead of C? Is it practically possible to use C++ for current PICs? Is there any future plans or ongoing development on this?
Tell me more
×
Electrical Engineering Stack Exchange is a question and answer site for
electronics and electrical engineering professionals, students, and enthusiasts. It's 100% free, no registration required.
|
Yes, it is possible now. For dsPIC, there is the IAR Systems C++ Compiler (although it's very old and not supported). Another option is to use a C++ to C converter. Using a pre-build step, convert the C++ to C, then give the (nasty looking) C to your normal C compiler. Take a look at LLVM or Comeau's C++ compiler which both do that. Comeau's is only $50, but it will probably take some effort to get the whole toolchain and libraries working properly.
Short answer, no, there are no hardware limitations. Long answer, C++ certainly encourages the use of a heap and / or stack, which smaller MCUs with limited RAM will struggle with. Why do they struggle with a heap/stack? For two reasons: A) many MCUs have limited RAM, not enough for a heap certainly, and barely enough for a stack. B) many MCUs don't handle pointers well, so use of variables on the stack really kills performance. When people ask about using C++ on an MCU, I find it constructive to compare C++ to C. The exact same questions were (and still are) asked about C on an MCU. People used to balk at the idea. A high level language, on 256 byte RAM MCU ?? Impossible. But now we all know it's possible. I've written C for a PIC12. No problem. It's possible because A) the software developers know that they have to be a little bit careful: don't use malloc() etc. and B) the compiler has been written especially for the MCU. The compiler will also be extra careful with memory allocation, it won't try to create a heap and may not create a stack. Some C compilers simply won't let you write re-entrant (recursive) code which absolutely requires a stack. Knowing that it's possible to write C for an MCU, the same answers apply to the question of writing C++ on an MCU. As long as the compiler understands the limitations of the target device, and the user understands the language too, there's really no problem. In C++, you only pay for what you use. It's perfectly possible to write C++ (with objects and everything) that produces the exact asm output you would have got if you'd used C. Now, PIC32s certainly can cope with C++. They have up to 64kB RAM, and are based on the MIPS core, which is a properly grown up 32-bit processor. It can deal with pointers and a stack as well as a PC. Indeed, there are PCs based on the MIPS (or at least, there used to be). Sadly, there is so much misunderstanding surrounding C++. Even very experienced coders seem to have no idea how the language works. See my answer on why C++ is suitable on embedded CPUs.
As I said, there may be no difference. Bjarne Stroustrup did a comparison of a bunch of C/C++ compilers to compare time and space performance for a number of operations. The results varied widely. In some cases, the C++ came out slower and larger, some cases slower and smaller, or faster and larger, and even faster and smaller! So, the answer to your question is that it depends heavily on the compiler, but in general, it need make no difference at all. For more detail, see the Technical Report on C++ Performance
That I don't know. I do know that the Microchip C32 compiler is open sourced, and you can download the source. I also know that someone I worked with actually found some instructions online and managed to get the compiler to compile C++ code. But he left the company before he was able to set me up with a proper tool chain. UPDATE Microchip now has a C++ compiler available for its PIC32 range of embedded MCUs. |
|||||||||||||
|
Depends what features you use. If you use the core object-oriented features (class + methods), likely to have very little effect (mangled variable/function names longer so symbol table likely will increase somewhat). Templates shouldn't add much with a good compiler, either. If you go all-out crazy and pull in things like the Standard Template Library, and use dynamic memory allocation and exceptions, then you're likely to run into code bloat. |
|||
|
There are c++ compilers for pic already, for example http://www.sourceboost.com/Products/BoostCpp/Overview.html I've not used this and know nothing about it other than it exsists... |
|||
|
|
|
Generalizing your question somewhat, there are ARM processors that are built for the embedded market that contain an MMU (memory management unit). Memory size and allocation made languages like java and c++ poor embedded choices. As embedded processors continue to get faster and more powerful, and as memory becomes denser and cheaper, the language choices available to embedded engineers changes dramatically. A 32-bit 600MHz ARM processor with MMU and a 64G Flash card is a great candidate for c++ applications. Whether it fits the definition of the classic embedded processor is another issue. |
|||
|
|
|
Probably yes.. but you shouldn't anyway... C is the language of embedded and there are no advantages of using C++. Or rather, advantages of C far outweighs the advantages of C++ for embedded. Don't waste your time.
|
|||||||||||||||||
|
