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

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

It's easy to get into a C versus C++ argument because both parties are right.

I'm old enough (almost a brain in a jar connected to wires and tubes) that I remember the assembler versus C arguments when I was writing real-time stuff for PDP-11s in assembler. And the assembler folks are right too. In the 1990s even as I was writing in C++ for one chip on a board I was also writing code in assembler on DSPs on the same board. Just depends on the circumstances.

But part of my goal in this project was to figure out if the C++ techniques I'd been using since 1996 on PowerPC and ARM processors could be carried over to eight-bit microcontrollers. The answer, for me, was "yes". Not that it doesn't take discipline and care. You can write inefficient, hard to maintain, buggy code in C++, just as you can in C, and for that matter in assembler.

C++'s greatest strength is also it's greatest weakness: it allows you to climb higher on the abstraction ladder. This can reduce your development costs, both short term and long term, and can also reduce your project to a smoking heap of crap. Climbing higher on the abstraction ladder does not free you from having to know what's going on under the hood.

This is really always true, but is especially always true in highly resource constrained environments. ("Especially always" meaning elsewhen you can get away with being ignorant without being bitten right away... unfortunately.)

I don't believe C++ is a good language for students just starting out to learn programming. It's just too darn complicated. I like Java, or script-like languages like Python (which I've never used, but colleagues whose opinions I trust recommend it).

But for more experienced students who are beginners at embedded, I think C++ is a win. And for very experienced embedded developers who are looking for more capability from their language, it is a big win.

I like OO design. My first experience at OO design was working with the OS/360 I/O Subsystem written circa 1969, although I first started poking at it in 1976. No, I'm not kidding. Almost all the mechanisms that C++ uses under the hood I first saw in IOS.

Algorithms have two big picture components: action, and state. The question "which is more important, action or state?" is meaningless, it's like asking "which is more important to life, blood or oxygen?"

OO languages are a way of combining action and state into a single lexical component, with some rules to prevent developers from inadvertently dealing with one but not the other. Back when I was using C for pretty much all development, i found myself writing in a style that combined action and state (structures and functions). C++ gave me the means to combine the two in a way that the language supported what I wanted to do automatically.

Thank you, thank you, I'll be here all week. Don't forget to tip the bartender!

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

coverclock wrote:
Algorithms have two big picture components: action, and state. The question "which is more important, action or state?" is meaningless, it's like asking "which is more important to life, blood or oxygen?"

OO languages are a way of combining action and state into a single lexical component, with some rules to prevent developers from inadvertently dealing with one but not the other. Back when I was using C for pretty much all development, i found myself writing in a style that combined action and state (structures and functions). C++ gave me the means to combine the two in a way that the language supported what I wanted to do automatically.

This is an excellent statement - thank you!

I've often said that anyone who does enough assembly programming will eventually invent C-like methods for organizing his code. I'm guessing the same applies for C, anyone who does enough of it (especially in teams) will likely develop methods that are C++-like.

There is a lot of gray in the area for folks starting out on microcontrollers. I'm coming to take to Johan's idea that lots of folks will be coming from higher level programming and therefore will already be OOP oriented so they could start out with C++. Unfortunately from my perspective, I don't honestly think I have the experience to lead that charge, so I'll stick with the never-ever programmed folks and continue to promote C. I'll just be fairer when I hear the novice C or C++ argument.

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

Quote:

I've often said that anyone who does enough assembly programming will eventually invent C-like methods for organizing his code. I'm guessing the same applies for C, anyone who does enough of it (especially in teams) will likely develop methods that are C++-like.

Well said. That has been my experience exactly. Before I ever heard the term "structured programming" back in the 1970s I found myself writing structured programming constructs in assembler just because it was the only way I'd found to write reliable, debuggable, understandable code.

BTW, different sub-thread, I have written some on using C++ templates in embedded projects. As usual, the higher level the language, the more tools it gives you to shoot yourself in the foot, so approach with caution.

http://coverclock.blogspot.com/2007/01/generic-embedded-programming-using.html

I would NOT recommend trying to use the C++ STL on an eight-bit microcontroller (the underlying library won't have the STL stuff anyway, so non-issue). But careful use on less constrained PowerPC and ARM platforms has been a win in my experience, and use of your own templates even on AVRs etc. can be a win if done very carefully. Templates used correctly also fall into the category of "automating what you were doing by hand anyway" and depending on the application may have zero additional overhead. Templates are a form of code generation, just like the C preprocessor, and like the CPP, can be great or terrible.

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

smileymicros wrote:
I'll stick with the never-ever programmed folks and continue to promote C.

Nothing wrong with that, but why dismiss the approach I suggested ? No matter how far you go, you will benefit.

For instance, if you just compile your C code as C++, the compiler will enforce some very good programming habits.

From there, you may be tempted to take advantage of several easy to understand C++ improvements, while your source code still looks pretty much like C.

Sid

Life... is a state of mind

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

Quote:

From there, you may be tempted to take advantage of several easy to understand C++ improvements, while your source code still looks pretty much like C.

I'd agree this is the best approach. Start with C in .cpp files but then maybe start to dabble in namespaces or classes with member functions (the infamous class.function() syntax), then use things like function over-loading.

A bit like when you make the transition to C99 you just start to use the new bits then wonder how you ever lived without them.

I'd be interested to hear from the C++ experts here what is the best 10 features to dabble in first(*). A bit like when the MCU programmer starts and does:

1) light LED
2) blink LED with delay loops
3) blink LED with timer
4) PWM LED to fade up/down
5) read pot using ADC and use to vary blink/fade/etc.
6) and so on...

(*) with emphasis on MCU usage!

 

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

coverclock wrote:
As usual, the higher level the language, the more tools it gives you to shoot yourself in the foot, so approach with caution.

Quote:
"C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do you blow your whole leg off." - Bjarne Stroustrop

I'll probably wait a few more years and then start working on teaching materials for embedded Linux on an ARM using C++. It seems to me we really are in a transition point where transistors are becoming so cheap that adequate systems will be available for a few dollars. Really the only thing in the way in the moment are well documented free and easy tools like WinAVR. I assume in the next few years these tools and documents will become available.

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'd be interested to hear from the C++ experts here what is the best 10 features to dabble in first(*).

(*) with emphasis on MCU usage!

My first attempt at such a list :
    1) declare variables at first use 2) loop variables
    3) bool data type
    4) function overloading
    5) default parameters
    6) new[] and delete[]
    7) template functions
    8) simple classes, i.e. C-style structs with the addition of non-virtual member functions
    9) simple class inheritance
    10) exception handling (if the overhead is acceptable)
Some of those may be included in C99 ? I ditched C for C++ more than 20 years ago, so I don't stay fully updated on C.

Sid

Life... is a state of mind

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

Quote:
8 ) simple classes, i.e. C-style structs with the addition of non-virtual member functions

I'd probably have that as #1 . Apart from the "addition of member functions" you also have to deal with access specificers (public-protected-private), constructors and destructors. And then you have the concept of aggregation (ie objects within objects) and then you will have to return to talking about constructors and destructors and the order in which they are executed. And I'm probably missing a lot of things. There is enough here for items #1 to #5 on the list...

Quote:
7) template functions

No opinion on that ordering, but I'd say that template classes should be on the list and are more important than template functions. I've taught C++ many times (a three day introductory course), and while we always introduced templating with template functions I am actually wondering if that is the wise way. Don't get me wrong - both are usable, but while template functions are convenient template classes are about something much bigger. Think "Abstract Data Types" if that term is familiar.

Quote:
3) bool data type

I could deem this a detail, if it wasn't for another big difference between C and C++: While C has the type concept, there is very little inherent type safety. C++ is a lot stronger here. And the notion of "a real boolean type" is an indicator of that C++ was designed with types as a central concept.

Quote:
9) simple class inheritance

I'd have this fairly early on the list, definitively before any templating.

Quote:
6) new[] and delete[]

Where did new and delete disappear? Quatum leap to dynamic allocation of arrays of objects - oh my! :wink:
Quote:

1) declare variables at first use
2) loop variables
4) function overloading
5) default parameters

All details in the big picture. Not simply syntactic sugar perhaps, but not central to "thinking in C++".

Quote:
10) exception handling (if the overhead is acceptable)

I'll have to think about this..

-----

I have a few "mental mantras" about OO:

Mantra 1: Encapsulation, Inheritance, Polymorphism

Mantra 2: Favour aggregation instead of inheritance.

Mantra 3: Program against an interface.

Mantra 4: Initialize in the constructor, tear down in the destructor (a.k.a RAII).

Those would control and influence the items, and the order of them, on my C++ list.

"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

Johan,

My list is ordered more or less according to ease of use for the experienced C developer.

What I wrote about “simple” classes is aimed at this audience. They would be better served by starting with C structs, only adding non-virtual member functions, as this adds no implicit overhead. Throw in constructors, destructors and aggregation and you increase the demands on the developer’s knowledge considerably – especially in the context of embedded systems. Also, starting with a C struct means that you don’t have to deal with access specifiers. Keep it simple, once people master the basics they may (or may not) decide to learn more.

Simple function templates are useful and easy to understand. Big gain, small cost.

new and delete should be avoided whenever they are not needed, for the skilled C developer it’s best to avoid them completely unless he is mallocing structs in his C code.

new[] and delete[] on the other hand is a type-safe alternative to malloc()/calloc() (to create C arrays), and easy to understand for the skilled C developer.

Template classes are best avoided until you are fully competent on classes.

What you refer to as “details in the big picture” are simple little things that improves your source code, and they most likely appeal to the skilled C developer that can immediately use them. They are small details to you and me, but good points for convincing others that there may be something to this other language even without years of study.

I don't disagree with you about C++ but you have the wrong focus for this audience.

Sid

Life... is a state of mind

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

Regarding slowly transitioning from C to C++: this is something I've had to deal with for some time in large product line code bases (where code is shared across many embedded products, including ones with different processors, not just different models but completely different architectures. I wrote a blog article about some techniques to ooze C++ into an existing C code base.

http://coverclock.blogspot.com/2011/02/cant-we-all-just-get-along-c-and-c.html

Pages