8
\$\begingroup\$

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?

\$\endgroup\$
  • \$\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\$ – clabacchio Feb 17 '12 at 9:38
  • 3
    \$\begingroup\$ For the suitability debate - electronics.stackexchange.com/questions/3027/… \$\endgroup\$ – Toby Jaffey Feb 17 '12 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 Vermeer Feb 17 '12 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\$ – Rocketmagnet Mar 31 '12 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 Ooijen Apr 4 '12 at 21:16
16
+250
\$\begingroup\$

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.


\$\endgroup\$
  • \$\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 S Apr 1 '12 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\$ – Hans Apr 1 '12 at 20:07
  • \$\begingroup\$ Yes, sorry, it wasn't really a great find. Let me add some more things to my answer. \$\endgroup\$ – Rocketmagnet Apr 1 '12 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\$ – AngryEE Apr 2 '12 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\$ – Rocketmagnet Apr 2 '12 at 14:00
5
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Justing a warning for the OP, be very very careful about memory allocation on small memory architectures and embedded always running systems. \$\endgroup\$ – kenny Feb 17 '12 at 15:47
  • \$\begingroup\$ could the "-1"er please comment on why he/she does not agree? \$\endgroup\$ – Jason S Apr 5 '12 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\$ – Peter Green Sep 14 '16 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 S Sep 14 '16 at 19:02
4
\$\begingroup\$

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

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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.
\$\endgroup\$
  • 5
    \$\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 S Apr 2 '12 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\$ – AngryEE Apr 2 '12 at 13:58
  • 1
    \$\begingroup\$ I also beg to differ. \$\endgroup\$ – Rocketmagnet Apr 2 '12 at 14:02
  • 3
    \$\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\$ – Rocketmagnet Apr 2 '12 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\$ – Rocketmagnet Apr 2 '12 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.