megaAVR + Arduino + FreeRTOS + C++ = Teaching Platform

41 posts / 0 new
Last post
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The only negative thing about C++ in embedded systems, as well as in many other environments, is that it takes a long time to get good at it. This is particularly obvious when it comes to embedded systems where you have rather limited resources.

As a lot of people think the availability of features means they have to use them, even skilled C programmers fail to realize that they can get immediate advantages from C++ without doing anything OO. Anything sensible you can do in C, you can do in C++. There are a few things you are not allowed to do in C++, and those are things you shouldn't do in the first place.

A good first step that comes at no performance cost is to compile all your C sources as C++. First get rid of all the errors, then get rid of all the warnings, and the quality of your code has improved (unless you "fix" everything with a cast).

From there, you have access to all the improvements of C++ including function overloading, template functions, loop variables and all sorts of other neat features – still without doing anything OO unless you want to.

It is possible to gradually make the transition to C++ without messing up your existing systems.

(EDITed to fix character set problems (' and "))

Sid

Life... is a state of mind

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
Quote:
...convinced me that C++ is a win in the embedded space. But perhaps not for beginners.

You mentioned Arduino as the "easy" environment. They seem to be doing a pretty good job of leveraging C++ features to make things easier for beginners. Though not without the occasional hiccup...
I honestly believe that this decision was a mistake on their part. Sort of like the one that requires them to use a 0.05" space between two 0.1" headers - a dumb glitch that everyone now has to live with to be 'Arduino'.

I have rewritten most of the Arduino library in regular C and IMHO it is just as easy to use as their version which mixes C and C++ in a most perplexing way. This is especially true for Cliff's example for the 'simple' Serial.xxx functions. You have to write long lists of these commands to get what you get immediately with printf.

By mixing C and C++ they pretty much assure that a novice will never go under the hood and grok what is going on with the core functions. It is difficult enough to learn C or C++ from scratch, but seeing code written in both and mixed willy-nilly doesn't give the student the opportunity to see either the strengths or the weaknesses of either language displayed logically.

Mind you, I think the Arduino is the greatest thing since sliced bread. But I tend to make my own bread and slice it myself. To me the Arduino is absolutely the best place for novices to start. But if they want to move on, they need to quickly get away from the underlying Arduino code and look elsewhere for a logical progression in programming knowledge.

Okay, this is a rant in which I am justifying a bunch of stuff I've been pushing for the past several years, but it is also something I believe.

And sorry if this is to OT, but it seems the thread has already gone this way so... Back on topic, I think the OP suggestion to start with C++ is not as viable as starting with C, but I also think starting with C++ is MUCH preferable to starting with mixed C and C++.

Smiley

FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Joe!

Any reaction to my "it depends on where you come from"?

Also: I always thought that the Arduino framework was designed primarily for people who did not have as their primary interest neither to learn about the hardware nor to design performance-critical stuff.

There was examples like artists mentioned.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

You have to write long lists of these commands to get what you get immediately with printf.

I still use printf() in C++ code. I find the overloading of << painful at best. I know it's "clever" that the same thing can print a sting or a float but I still prefer good ole %s and %f ;-) One day perhaps I'll "get it". The hoops you have to go through for %04.2f are especially painful with all that setw() and setfill() nonsense. Exactly who thought this was an improvement?

Cliff "The Luddite"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I mostly agree cliff. For just outputting a few variables and/or literals w/o demands on specific formatting the streams might be easier. For most any structured output, printf() is my use also.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Joe!

Any reaction to my "it depends on where you come from"?

Well, thiat is an excellent consideration.

However, I come from the bottom end of things and don't really feel like I understand C++ well enough to explain it to novices, so I stick with what I know. I also think that those coming from OOP must at some point learn that OOP is about the way humans think, while C is about the way computers work. For systems with the resources it only makes sense to offload the expensive human time to the cheap processor time and use OOP. But for restricted microcontrollers it still seems to me that it makes more sense to use human time to cater to system constraints. Finally, if a person never learns C and dare I say, assembler - they never really know what the machine is doing and are poorer for that. AND yes I admit that most folks, Arduino users included, could give a flip about how the thing works. But I chose not to deal with those folks. I am hungry for knowledge and just don't get folks who aren't.

I can see a pedagogical justification for using C++ with a more capable system, but for a 'real' engineer, I'd want to know that they had a good feel for the architecture, the assembler, and C before they get into the higher conceptual paradigm of OOP and C++.

JohanEkdahl wrote:
Also: I always thought that the Arduino framework was designed primarily for people who did not have as their primary interest neither to learn about the hardware nor to design performance-critical stuff.
Absolutely! And when the few that get curious about how this thing is really working, I pity them that look at the underlying code and think that it provides a path to real world embedded system development. It is the phase of 'Moving Beyond the Arduino' that concerns me, and I think that these folks should be learning something that mimics the underlying architecture as C does, rather than the way a human brain works as C++ sort of does.

JohanEkdahl wrote:
There was examples like artists mentioned.
That is who the system was designed for and is perfect for them. Remember - I am an Arduino fan, but I also understand that it has serious limits. But now everybody is using them and while it provides and easy start, I think it also creates a gulf between what the Arduino does and what can be done with a micro. In a way it is a bit like BASIC in that respect. BASIC does a bunch of things well, but there are things a micro can do that just aren't part of the BASIC implementations I've seen. To move on to serious programming you have to abandon BASIC for assembly or C, and I think the exact same case holds for Arduino. Our argument is whether they abandon it for C or a mix of C and C++. I think the latter just puts up a barrier for most intermediate folks.

Perhaps someone should take the opposite tactic that I'm taking and provide a path for the high level folks that teaches an entirely C++ version of Arduino and then if the folks want to understand the low level stuff, then a path to C and assembler can be given.

Yeah, I'm overthinking this.

Smiley

FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I still use printf() in C++ code. I find the overloading of << painful at best. I know it's "clever" that the same thing can print a sting or a float but I still prefer good ole %s and %f ;-) One day perhaps I'll "get it". The hoops you have to go through for %04.2f are especially painful with all that setw() and setfill() nonsense. Exactly who thought this was an improvement?
Overloading operators is not necessarily bad. It's not the overloading that causes lousy performance and awkward syntax.

The streams implementations, on the other hand, generally suck big time and no C++ programmer that knows his head from his axx uses them extensively.

printf() et al are a part of the C++ libraries anyway. Just some moron creating an alternative to the older libraries doesn't mean we have to use the alternative.

Sid

Life... is a state of mind

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
For just outputting a few variables and/or literals w/o demands on specific formatting the streams might be easier.
Not if you're concerned about program size. Including a streams implementation in your executable is likely to cost you.

Sid

Life... is a state of mind

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ChaunceyGardiner wrote:
stevech wrote:
There are plenty of advantages besides "dots in the function name".
In the context of embedded processor code that is easily maintained by other than the author, what are the C++ advantages? I've spent a lot of time learning C++ (coming from decades of C), and haven't yet found what's better than good modularized C with lots of typedefs and structs (for embedded).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
ChaunceyGardiner wrote:
There are plenty of advantages besides "dots in the function name".
In the context of embedded processor code that is easily maintained by other than the author, what are the C++ advantages? I've spent a lot of time learning C++ (coming from decades of C), and haven't yet found what's better than good modularized C with lots of typedefs and structs (for embedded).

Function overloading, template functions, loop variables, reference variables and type safety for starters. Those are just off the top of my head, the list is much longer.

For the skilled C++ developer - classes, class templates, inheritance, improved resource handling, easier creation and use of reusable code, less duplication of code and so on.

Sid

Life... is a state of mind

Pages