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?
\$\begingroup\$
\$\endgroup\$
5
asked Feb 17, 2012 at 9:01
-
\$\begingroup\$ I think it's possible and will remain possible, but AFAIK it's not recommended as it implements high-level structures and functions that are not suitable for strongly hardware-related programming \$\endgroup\$– clabacchioFeb 17, 2012 at 9:38
-
3\$\begingroup\$ For the suitability debate - electronics.stackexchange.com/questions/3027/… \$\endgroup\$– Toby JaffeyFeb 17, 2012 at 11:05
-
2\$\begingroup\$ Since the answer is "Yes, there are C++ compilers already in existence", I'm going to let this one stand, but in the future you should be aware that Stack Exchange questions should be about verifiable facts, not suppositions about the future. \$\endgroup\$– Kevin VermeerFeb 17, 2012 at 22:48
-
2\$\begingroup\$ @clabacchio: Not necessarily true. In C++, you pay only for what you use. See my answer at: electronics.stackexchange.com/questions/3027/… \$\endgroup\$– RocketmagnetMar 31, 2012 at 21:15
-
\$\begingroup\$ "PICs" is a useless generalization. On some low-end PICs (think 10F200) C is almost impossible to use. On some high-end PICs (32MX series) C++ is rumoured to be used right now, and there is certainly no technical reason why it couldn't. So some betterf focussing might give more useable answer, right now everyone is in effect answering a different question. \$\endgroup\$– Wouter van OoijenApr 4, 2012 at 21:16
Add a comment
|
5 Answers
\$\begingroup\$
\$\endgroup\$
15
Is it ever gonna be possible to use C++ for coding PICs?
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.
Is there any hardware limitations that prevents us to use C++?
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.
How much the size of generated .hex file and running time of the program increase when we use C++ instead of C?
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
Is there any future plans or ongoing development on this?
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.
answered Mar 31, 2012 at 22:01
-
\$\begingroup\$ from IAR web page: "Legacy product: IAR Embedded Workbench for dsPIC is a legacy product. IAR Systems does not update it and it is not possible to buy a Support and Update Agreement for it." \$\endgroup\$– Jason SApr 1, 2012 at 0:34
-
\$\begingroup\$ I know IAR products are great, but unfortunately very expensive and it seems 'old'. I know C++ is feasible on any platform as long as you don't use all the features. However, it does add the possibility for an extra layer of abstraction with classes. I don't use templates often, neither do I use dynamic memory allocations at all. Does anyone happen to know any other competitor for C++ on PIC24/PIC32? \$\endgroup\$– HansApr 1, 2012 at 20:07
-
\$\begingroup\$ Yes, sorry, it wasn't really a great find. Let me add some more things to my answer. \$\endgroup\$ Apr 1, 2012 at 20:14
-
1\$\begingroup\$ I would consider C a competitor for C++ on a microcontroller. I can't think of anything I'd want to do in C++ that I can't do in C and there are fewer invisible function calls (constructors, destructors, etc). Makes the code more deterministic and plain. What features of C++ are a must-have that can't be muddled through with C? \$\endgroup\$– AngryEEApr 2, 2012 at 13:55
-
1\$\begingroup\$ One could ask: "What features of C are a must have that can't be muddled through in ASM?" Answer, "Nothing". The benefits are increased ability for the designer to specify the design, and have the compiler check the implementation is correct. See my answer electronics.stackexchange.com/questions/3027/… for a list of the real and immediate benefits of C++ in this regard. \$\endgroup\$ Apr 2, 2012 at 14:00
\$\begingroup\$
\$\endgroup\$
4
How much the size of generated .hex file and running time of the program increase when we use C++ instead of C?
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.
-
\$\begingroup\$ Justing a warning for the OP, be very very careful about memory allocation on small memory architectures and embedded always running systems. \$\endgroup\$– kennyFeb 17, 2012 at 15:47
-
\$\begingroup\$ could the "-1"er please comment on why he/she does not agree? \$\endgroup\$– Jason SApr 5, 2012 at 11:47
-
\$\begingroup\$ I'm not the -1er but templates are a feature that have to be used with great care to avoid code bloat. You can easilly end up with many copies of an algorithm when one would suffice. \$\endgroup\$ Sep 14, 2016 at 13:20
-
\$\begingroup\$ To do that you would actually have to use the template with several different data types, and one copy WOULD NOT suffice unless you are using polymorphic code that has a common base class. (In which case there is a runtime cost.) Templates don't magically cause your code to bloat, they only cause bloated code when you use them with multiple data types when you are not aware of the consequences. \$\endgroup\$– Jason SSep 14, 2016 at 19:02
\$\begingroup\$
\$\endgroup\$
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...
answered Feb 17, 2012 at 11:23
\$\begingroup\$
\$\endgroup\$
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.
\$\begingroup\$
\$\endgroup\$
11
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.
- if you know how to use function pointers etc. You can code like C++, there is no problem there.
-
6\$\begingroup\$ I beg to differ. You can use many features of C++ (classes, templates, operator overloading, references) with little to no runtime cost. Yes, you can do all these things in plain C with hackish constructs, but it's a drag on your brain, and I'd much rather be using C++. (of course I'd much rather be using a better language, but I'd pick a C++ compiler in a heartbeat over plain C.) \$\endgroup\$– Jason SApr 2, 2012 at 2:17
-
1\$\begingroup\$ Classes = structs (with no built-in methods, but if you like, you can store a function pointer in the struct and call that). Templates = you use those??? Operator overloading = yes I would like that too. References = pointers, no? With C at least you get to use only the 'features' of C++ you want without worrying about excess code generation or having to include a random large library just to get something to compile. \$\endgroup\$– AngryEEApr 2, 2012 at 13:58
-
1
-
4\$\begingroup\$ Yes, templates are an extremely powerful way to generate reliable and high performance code. References are a more reliable pointer. With C++ you also only pay for the features you use. I think you really need to understand C++ more. \$\endgroup\$ Apr 2, 2012 at 14:21
-
3\$\begingroup\$ I don't know what you mean by "C is the language of embedded". Sure, it's very popular. Are you saying that it's the best possible language? Surely not. \$\endgroup\$ Apr 2, 2012 at 16:18