Jump to content
43oh

Recommended Posts

Hi, 

 

I'm new in the MSP430 MCU's I have already written app to drive servos and steppers, now I want to clean up the code to make it a library and I was curious about moving to C++ for code clarity and nice object based code.

 

Because my library will be time critical (I have to use 16MHz to drive 3 steppers and 8 servos at once with customizable stepper speed to reduce servo jitter to zero), my concerns are:

 

- performance hit?

- RAM usage - anything significant?

- any other not so obvious drawbacks?

Link to post
Share on other sites
  • Replies 32
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Point is, you're the only one arguing about what is best, and what is not.  My whole stance has been ( going back what now ? 2-3 months ). Be flexible, and use what makes sense.  Of course, if your ex

Again . . .    Being a bad programmer makes you a bad programmer. You and Linus can both agree all you two want, but that does not make either of you right.   C can not do function overloading . .

I think you'll find, at least with the "original" digital guys ( who are still around ) assembly is the real go to language. I find that most of these guys who truly know their stuff, know assembly ve

See these two threads:

 

Why, why not? http://forum.43oh.com/topic/2808-coding-for-msp430-in-c/

Example of efficient use of C++ templates: http://forum.43oh.com/topic/2358-software-iic-master-in-c-c-class-and-c-template/

 

I'd say it has its benefits, but might come at a performance and RAM hit too big for the limited resources of an MSP430 if not done carefully.

Link to post
Share on other sites

Plain C++ objects take only a few bytes (2) of extra ram. They do however execute all code on member variables which are rrelative to the object. This is no more slow than local variables, but it's z little slower than global variables.

Try to avoid dynamic instantiation of objects (e.g.: the user of the new keyword), as our will invoke a lot of memory allocation functions and requires runtime management of ram. Instead, make objects as you would make primitive types:

Class Object;

Instead of:

Class* Object = new Class();

Link to post
Share on other sites

I'd say it has its benefits, but might come at a performance and RAM hit too big for the limited resources of an MSP430 if not done carefully.

 

Just like C . . .

 

You just need to pay attention is all, just like when using any other language.

 

About a month or so ago, one user on these forums was experiencing issues with their MSP430G2553 project. They were not  sure of the problem, but when I examined the code I noticed 2-3 different issues. One drawing my attention more than the rest.

 

char somevariable[50]; <--- as a global ! Not sure of the actual number, but it was using roughly 400 bytes, all the time.

 

Second problem was running a fairly deep function "queue". Needless to say, the program would run briefly before crashing.

 

Anyway, my point being. It really does not matter which language you use. You need to pay attention to what you do no matter what.

 

Also, there are some bonuses to using each language. Such as the template classes used with opossum's template class code. When "something" is known at compile time, this "something" can be taken care of at compile time, versus run time. Thus, making the code *possibly* smaller, and faster. Again, you need to pay attention to whats going on.

 

Personally, coming from an OOP background in the last several years of my programming "career"( quoted because it is a hobby, and not a profession). I am a very strong advocate of using just about any OOP type language. With that said however, there is no reason why not to in this case to mix C with C++. Use each where it makes most sense. No point in being a purist, when being a purist will only work against you.

Link to post
Share on other sites

My opinion is that C makes you a better programmer, and C++ a worse one.  Sure, there are exceptions to every rule, but I've been doing this a long time, and I haven't ever had a reason to change my opinion.

 

To get another, slightly less philosophical perspective, see linus.  Bascially, I agree 100%.

 

In microcontrollers, the difference isn't so much with the standard libraries... because they don't exist.  The difference is the fact that object oriented design philosophy usually leads to architectures that are less conducive for performance and power optimization.  Contiguous memory is a big deal in systems that have lousy memory movement (like MCUs).  If you ever think you might care about optimization, it's better to avoid object orientation and instead think about data type orientation.  C++ without object orientation might as well be C.

Link to post
Share on other sites

My opinion is that C makes you a better programmer, and C++ a worse one.  Sure, there are exceptions to every rule, but I've been doing this a long time, and I haven't ever had a reason to change my opinion.

 

To get another, slightly less philosophical perspective, see linus.  Bascially, I agree 100%.

 

In microcontrollers, the difference isn't so much with the standard libraries... because they don't exist.  The difference is the fact that object oriented design philosophy usually leads to architectures that are less conducive for performance and power optimization.  Contiguous memory is a big deal in systems that have lousy memory movement (like MCUs).  If you ever think you might care about optimization, it's better to avoid object orientation and instead think about data type orientation.  C++ without object orientation might as well be C.

Again . . . 

 

Being a bad programmer makes you a bad programmer. You and Linus can both agree all you two want, but that does not make either of you right.

 

C can not do function overloading . . . C can not do templates . . . C++ *can* do anything C can do and more.

 

Templates can lend towards faster, more efficient, and smaller code. Sometimes which can be hard to reproduce even with carefully hand crafted assembly language. 

 

Just a few points there, some being more significant than you, or Linus realize, apparently.  But running the risk of sounding like an ass, where I am not trying to be. It seems to me that you, and Linus are both of the mindset that C++ is bad, without actually laying hands on C++. However, I really have no idea how Linus actually thinks, just going by what you're saying. Whatever the case, it matter little to me, as I tend to think for myself.

 

So, if you have a specific case to bring up that does not rely on developer coding style/habits. Which are based on fact, then perhaps you're on to something. However, with that said, I really do not think you can bring anything up that has already been rendered as moot. C++ relies heavily on C. So I feel that if a bit of C code would do a specific job better, that it would be foolish to not use C in that given case. However, the reverse is also true.

 

So yeah I am of the opinion that purist ideals hold no real "value" in this context. But feel free to do as you please :)

Link to post
Share on other sites

Thanks all of You,

 

looks like there is a lot to try and see how well it works. I'll try to examine assembly created by CCS, maybe I will come out with something interesting.

 

Also I'll check this GPIO template stuff for performance improvement.

 

Sounds as though you're on the right path for you. On a personal level, I really do not care which language you do use. Basically whatever makes *you* happy, but I think if you do for yourself as oPossum has demonstrated a few times on these forums. That you'll be pleasantly surprised, with what you can do / come up with using C++. It wont be like using standard C++ for x86, but it can make your life a whole lot easier / better. And there will be some trade off's between C/C++.

 

For example. . .

 

With my own Serial implementation that I currently use( which is largely based on other peoples code, "twisted" for my own use). I made such a trade off by overloading the "<<" operator to use cout like syntax. At the cost of 15-20 bytes of FLASH, for every use. Depending on the project I use this for, I find this more than acceptable. However, if code size is getting close to max, I can always remove this Feature, and use Object.Print("Sometext"); with no additional overhead.

 

Anyhow, the two people to talk to really would be Rickta59, and oPossum. Both seem to know ASM, C, and C++ very well , and have done extensive testing. Me, I am just following in their footsteps, and finding  some really interesting results.

Link to post
Share on other sites


// Generic char, and string template
template<class T> inline Debug_t &operator << (Debug_t &obj, T param){obj.Write(param); return obj;}
// int32_t type specialization.
template<> inline Debug_t &operator << <int32_t>(Debug_t &obj, int32_t param) {obj.Write(param, BASE); return obj;}
...
// uint8_t type specialization.
template<> inline Debug_t &operator << <uint8_t>(Debug_t &obj, uint8_t param){obj.Write(param, BASE); return obj;}


 

You tell me :) Either way, I am perfectly happy with this code.
Link to post
Share on other sites

This is an interesting topic....

For a 4k/16k code space microcontroller I'm in the "I prefer C camp"

The C compiler basically maps your C program directly into machine code.
This means you have more direct control over what machine code is generated.
This is most important when trying squeeze the last ounce of function out of each rom byte.


When you use the OO features of C++ then the implementation in machine code level is not
so obvious and intuitive. (not unless you are a C++ compiler expert).

Secondly when trying to explain to somebody the basics of how a piece of code turns into
the ones and zeros that are flashed into the rom, it is much easier to demonstrate this using
simple C constructs like simple 'for' loops. In fact virtually every C statement can be easily
explained.  High level OO constructs would introduce too much abstraction. 

 

Link to post
Share on other sites

Being a bad programmer makes you a bad programmer. You and Linus can both agree all you two want, but that does not make either of you right.

That's a central point for both me and Linus, though.  If you have an open source project, it is easier to manage if it is being worked-on by a smaller number of good programmers than a larger number of less-than-good programmers.  If I can use C to prevent less-than-good programmers from contributing code, that's a great attribute of C.  Generally, I find this works, too.

 

It is important to understand that I am not interested in the language features of C++ or, really, any programming language in particular.  Programmers who argue about one language feature against another aren't really people I want on my projects.  Coders who obsess about language features tend not to obsess about the performance of the product.  The hallmark of modern language features -- maintainability of source trees in group programming -- is not really important for embedded products due to the way hardware is released.  Performance, however, is very important.  (I'd also argue that Git and things like it make source-tree maintainability a different issue than it was when C++ and Java were being developed).

 

Lastly, "being right" in this matter is purely a function of doing.  Most great software and firmware is still done in C (especially true with open source software).  If you make a great piece of C++ software, then it is right.

Link to post
Share on other sites

That's a central point for both me and Linus, though.  If you have an open source project, it is easier to manage if it is being worked-on by a smaller number of good programmers than a larger number of less-than-good programmers.  If I can use C to prevent less-than-good programmers from contributing code, that's a great attribute of C.  Generally, I find this works, too.

 

It is important to understand that I am not interested in the language features of C++ or, really, any programming language in particular.  Programmers who argue about one language feature against another aren't really people I want on my projects.  Coders who obsess about language features tend not to obsess about the performance of the product.  The hallmark of modern language features -- maintainability of source trees in group programming -- is not really important for embedded products due to the way hardware is released.  Performance, however, is very important.  (I'd also argue that Git and things like it make source-tree maintainability a different issue than it was when C++ and Java were being developed).

 

Lastly, "being right" in this matter is purely a function of doing.  Most great software and firmware is still done in C (especially true with open source software).  If you make a great piece of C++ software, then it is right.

 

Point is, you're the only one arguing about what is best, and what is not.  My whole stance has been ( going back what now ? 2-3 months ). Be flexible, and use what makes sense.  Of course, if your experience is limited, your options for what makes sense  is also by default going to be limited.

 

I bet you would make little fuss about someone talking about using inline ASM right ? Same difference here, think about it.

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