Jump to content
43oh

Coding for MSP430 in C++


Recommended Posts

My experience with C++ on the MSP430 has been that it allows for faster, more compact and better organized code.

 

Unusual. MSP430 is a classic CISC machine (they call it RISC in the marketing, but that couldn't be more wrong). It has complex instructions that translate simply to assembly programming methods and non-object-oriented C. Basically, it works best when data elements are grouped together, which is anathema to object-oriented programming models. Granted, all CPUs work best this way, but it will make a huge difference on MSP430 ISA. Possibly your C++ compiler is re-arranging data elements, but GCC doesn't typically do this.

Link to post
Share on other sites

Unusual. MSP430 is a classic CISC machine (they call it RISC in the marketing, but that couldn't be more wrong). It has complex instructions that translate simply to assembly programming methods and non-object-oriented C. Basically, it works best when data elements are grouped together, which is anathema to object-oriented programming models. Granted, all CPUs work best this way, but it will make a huge difference on MSP430 ISA. Possibly your C++ compiler is re-arranging data elements, but GCC doesn't typically do this.

 

mind expanding on what you mean by non-object-oriented c? some examples?

Link to post
Share on other sites

Unusual. MSP430 is a classic CISC machine (they call it RISC in the marketing, but that couldn't be more wrong). It has complex instructions that translate simply to assembly programming methods and non-object-oriented C. Basically, it works best when data elements are grouped together, which is anathema to object-oriented programming models. Granted, all CPUs work best this way, but it will make a huge difference on MSP430 ISA. Possibly your C++ compiler is re-arranging data elements, but GCC doesn't typically do this.

I, for sure, would like to be enlightned on this matter, as it does seem to contradict common kowledge regarding the MSP430 architecture.

 

I believe that C++, properly used, may be effectivelly used to reduce coding effort and keeping the generated machine code as efficient as the equivalent C would.

 

It comes to my mind that using templates to code for several implementations of an USCI driver might accomplish that, with a single template one might easilly implement, for instance, an UART on all USCIs of a given device.

 

--

to

Link to post
Share on other sites

Disclaimer: this is my general opinion based on a lot of experience developing hyper-optimized embedded stuff for communications, RTOS, signal processing, graphics, and crypto, for which I think C++ is horribly suited. There are always exceptions, so it's not a riff at anyone personally who likes C++. Of course, C++ can do everything that C can do, so what we are really discussing are "best practices" of typical C++ coders.

 

That said, I've never seen a good, clean, elegantly optimized piece of C++ code, apart from what I've seen from some game devs. As a case study, in 2010 I was contracted to solve a performance bottleneck caused by OpenCV for BeagleBoard. After taking a month to remove all of the "C++ best practices" in favor of C practices, guess what, 20x performance improvement. I will outline here some of the dumbest C++ practices for embedded & performance-oriented code:

  1. malloc everywhere (or just using objects instead of pointers). Seriously? Are you spawning threads? no? Then why in the name of Zeus are you mallocing?
  2. Passing objects when a pointer will do. You can argue that the compiler might be optimizing these out, but, in my experience, it's a lot better to be able to just scan through the C and find the problems than to have to analyze the crap out of it during runtime or read through generated assembly, required because there isn't a transparent connection between the compiler and the code.
     
  3. Storing sequentially accessed data, often of multiple objects of the same class, in the objects instead of in a coherent data block. In archs that have slow memory access -- MSP430 is one -- this is a great way to waste CPU cycles. On bigger multicore systems with shared L2 Cache it can actually be much, much worse.
     
  4. Inheriting objects into other objects, such that design changes during optimization cause cascaded errors that are difficult to find in large projects.
     
  5. Making efficiency compromises in order to design objects for multiple inheritance.
     
  6. Using conditional logic instead of arithmetic transforms and bit twiddling, and using pointers naively because strong typing is a religion.
     
  7. Hiding-away object class definitions deep into the file structure, or making stuff private when you're building an open source project. Open Source... the guy from Russia who downloaded your shit just changed all the private classes to public, anyway. Save Boris the 30 minutes and just make a comment.
     
  8. On the note of comments, comments are better than "self-commenting code." Self-commenting code is a disgrace. I'm not German, so I'm not trained at an early age to ReadWordsThatAreSixtyLettersLongWithWeirdCapitalizationRules. For whatever reason, I see this practice a lot in C++ and Java, but rarely in C.

I could probably think of more, but those are the ones that come to mind. Anyway, I'll throw down the gauntlet. I will offer a free optimization consultation of C++ source to doubters on this thread.

Link to post
Share on other sites

I was going to reply point-by-point to say which of those are in no way best practices for C++, and which are best practices regardless of language (though not regardless of context), but turns out the "numbered item" feature in the forum software persists when quoting and my response paragraphs were getting numbered too. So t'hell with that.

 

Short version: If your primary goal is optimization, C has some advantages over C++, and macro assembler has the same or more advantages over C. There are several people in the MSP430 community who argue that C is inappropriate for embedded development. C++ can win because it encourages placing simple function implementations in the class definition where they're visible at point-of-use and the compiler can optimize them as inline functions: this feature, and its generalization in templates, are the primary reasons why C++ can be very effective in producing fast code in an embedded system.

 

Personally, I favor maintainability over optimization, except when a clearly stated requirement is not satisfied; c.f. all the quotes on the Wikipedia "Program Optimization" article warning of the dangers of premature optimization. I find the abstraction and information hiding concepts supported by C++ to be a great enabler to getting a system architecture right and evolving it in response to changing needs, enough so that the C I write is often very much like C++.

Link to post
Share on other sites

I second pagibot.

In a way, any language is unsuited for a particular purpuse if used inappropriately. All those items are generally known as coding/design flaws, regardless of using C, C++, java or any other language.

 

The question at hand is not if there are people that know C++ and if these people have the skills to code for an MSP430 in C++. The question is about the possibility of using the features of C++ (only the ones that make sense in an embedded world) to code for the MSP430 without compromising performance and code size.

 

I guess oPossum's links above depict that quite well.

 

--

to

Link to post
Share on other sites

Here is the quote from the beginning (oPossum), that I am specifically countering: "My experience with C++ on the MSP430 has been that it allows for faster, more compact and better organized code."

 

As you now know, my experience is exactly the opposite, and the opinion is generally shared among performance-minded devs. You can certainly use C++ with good results, but for large projects where fast, compact, and easy to navigate code is a requirement, it's a bad choice.

Link to post
Share on other sites

Here is the quote from the beginning (oPossum), that I am specifically countering: "My experience with C++ on the MSP430 has been that it allows for faster, more compact and better organized code."

 

As you now know, my experience is exactly the opposite, and the opinion is generally shared among performance-minded devs. You can certainly use C++ with good results, but for large projects where fast, compact, and easy to navigate code is a requirement, it's a bad choice.

 

I'm reminded of Torvalds qoute on C++.

 

"C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it"

 

Jim

Link to post
Share on other sites

But out of curiosity, I wonder if it is possible to code for the MSP430 in C++. In particular I was thinking of mspgcc which is freely available. Has anyone tried this already?

 

Energia is happily using msp430-g++. Energia is an msp430 port of the Arduino IDE and core objects. You can download it here: http://energia.nu/download/ The code is open source and freely available. I think we have adopted a reasonable approach to using C++ on an embedded platform. We avoid dynamic allocation. We avoid RTTI (Run Time Type Information) and exception handling. Of course we don't use STL as it isn't even an option with msp430-g++. Most of the classes and data structures use composition over multiple inheritance. We have objects that abstract the Serial module with Timer and Hardware versions, the SPI and I2C modules with both USI and USCI. The goal being you can use the ms430g2231, ms430g2553, ms430fr5739 and the soon to be cortex-m4f chips with the same code. There are many examples available that exercise most of the peripherals on the chip. The Energia library is compatible with Arduino code and you can frequently use abitrary Arduino code you find without modification.

 

I'd like to see us take more advantage of C++ templates in the Energia code however one of our overriding goals is to lean towards Arduino compatibility more than absolute performance. C++ templates are the most useful C++ feature you can use on embedded micros. I've previously posted experiments with fast GPIO using C++ templates. I showed some of the asm code it generates and you will find it performs as well or better than generic C with much better readability. I like using C++ templates because it frequently allows you to move run-time code to compile time code. Templates offer compile time type-safe error detection that can't be achieved with straight C code and macros. Developing C++ template code is not beginner friendly, you will get errors that make no sense. However using a well written C++ template library is easy and performs really well. Check out the I2C library that oPossum wrote in C, C++ and C++ templates so you can compare for yourself. The C++ template version is actually the smallest and fastest. With all that said, I think the number of people using C++ templates on micros is pretty small. Most of the code I post is written in simple C or C++ so it can appeal to a wider audience.

 

If you don't like Arduino style coding, you can still use the msp430-g++ binary we provide for linux,mac and win32 and pound out some C++ using makefiles and a simple text editor.

 

So yes, people have tried it and are successfully using it.

 

-rick

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...