| Author |
Message |
|
|
 Posted: Apr 17, 2012 - 04:28 PM |
|
Joined: Mar 08, 2012
Posts: 13
Location: Denver Colorado USA
|
|
So this is the latest idea that I've gotten all obsessive-compulsive over: using Arduino, FreeRTOS, and C++ to teach real-time software design and embedded software development. I like the combination as a platform to teach both introductory students (using the Arduino Uno, SW and IDE), and to advanced students (using Arduino Mega or clone, FreeRTOS, C++, Eclipse, make, etc.). I really like the progression of starting out on the Uno with Arduino 1.0 and progressing to a multitasking RTOS, interrupt driven device drivers, etc. I like FreeRTOS because it's small, understandable, and it works. I like C++ because having spent many years in commercial product development (after having spent part of graduate school teaching real-time software design) I believe you need to climb as high on the abstraction ladder as you can to control costs, yet you need to see what's going on under the hood. The combination of Arduino and FreeRTOS hits a sweet spot of "just complex enough to be worth learning about".
So I started out doing exactly that: learning the AVR architecture on the Uno using Arduino 1.0, got FreeRTOS running on a Freetronics EtherMega (a Mega clone that incorporates the equivalent of an Ethernet Shield on the same board), wrote C++ OO wrappers around the FreeRTOS facilities (Task, MutexSemaphore, PeriodicTimer, etc.), wrote interrupt-driven device drivers in C++ (Serial, SPI), and a main program using a simple unit test framework that exercises all of it and demonstrates how it works. And there's plenty of room for student projects to write software for various applications, shields, hardware control, etc.
Recent blog articles I've written on this project:
http://coverclock.blogspot.com/2012/03/ ... -city.html
http://coverclock.blogspot.com/2012/04/ ... doing.html
Link to tarball can be found on project page:
http://www.diag.com/navigation/downloads/Amigo.html
For years I've futzed around with stuff like an Atmel AT91 evaluation board, a couple of BeagleBoards, etc. But even though I've spent years doing commercial development with Linux on ARM and PowerPC targets, I think when you throw in a memory management unit and the machinations that Linux goes through to be platform-independent, the result is too complicated for anything other than an advanced course. An RTOS like VxWorks, for which I've done a lot of commercial development, is too big, complex, and expensive, to use in anything except an advanced class. But once students got though Arduino, and then FreeRTOS, I think they could easily progress to VxWorks, and even to Linux, without much problems. The progression of Arduino and FreeRTOS would give them the confidence that they could figure out the more complex stuff.
I know this is my thing and I don't necessarily expect anyone else to be interested in it. But here it is.
-- Chip |
|
|
| |
|
|
|
|
|
|
Posted: Apr 17, 2012 - 04:47 PM |
|
Joined: Mar 27, 2002
Posts: 18581
Location: Lund, Sweden
|
|
|
Quote:
I know this is my thing and I don't necessarily expect anyone else to be interested in it.
Thank you very much for posting this. I will most certainly read the blogs this evening. I am especially interested in your "interrupt-driven device-drivers in C++", but I'll have a look at it all. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 17, 2012 - 06:28 PM |
|
Joined: Nov 17, 2004
Posts: 6137
Location: Great Smokey Mountains.
|
|
I personally question skipping over C and jumping directly into C++ for microcontrollers. I can see how an ARM or such like with an OS can be an appropriate platform for programming to preexisting libraries, but on an ATmega328 using the UNO? I know that the Arduino mixes C and C++ in its libraries, but I think that leads to a lot of problems for novices trying to transition from the restrictions of the Arduino libraries to doing regular embedded system tasks that lack pre-built libraries.
Isn't learning about microcontrollers difficult enough without adding the extra layer of complexity involved in using C++. Isn't it better to teach C and the AVR architecture as programmed in C (and assembly) first so that the student really understands what is going on under the hood and once they have mastered the core concepts, them moving on to C++ when they are ready to work on very large projects with teams of other programmers? I see two courses, the first C based course introduces how to program to the hardware with C and the second introduces how to program to the software system using C++. The low-level hardware versus high-level system concepts are quite different from my perspective, one requiring an understanding of hardware systems and the other requiring an understanding of hardware systems (like OSs) and I can't see how trying to teach it all in one go would be useful for the vast majority of folks wanting to learn this.
I know we keep going over this, but I still think C++ is a major jump in complexity from C and for novices it just makes a nearly impossible task, fully impossible.
Smiley |
_________________
FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com
|
| |
|
|
|
|
|
|
Posted: Apr 17, 2012 - 08:33 PM |
|
Joined: Mar 27, 2002
Posts: 18581
Location: Lund, Sweden
|
|
OK, so now we're going (at least slightly) OT again:
I largely agree with you, Joe. But..
While I suppose historically most people have come to "C in embedded" from assembler, I think we see a growing crowd of people coming from today's PC programming - and that is dominated by OO languages i.e. Java and C#/VB.NET.
I suspect that a substantial part of the posts we see here where novices wonder why it isn't enough to include "that header file" to get the program to build are due to the fact that in both C# and Java the specification of "libraries to link in" is not merely as explicit as in C.
I believe that if you come from one of those languages, and have actually learned it well, then the paradigm shift of going from an OO approach to a "plain procedural approach" is also a major jump. To rub in an old running example we've used before, they might come here with the concepts they are familiar with and go "All-right, I want to write a class that handles serial communication, perhaps using this USART". Should we tell them "No, you shouldn't do that. Instead you should create a struct that you will pass around explicitly to a bunch of functions which are 'coupled' only by the fact that they take this struct as a parameter." They might be just as flabbergasted over this as e.g. an AVR C programmer that tries to write his first C# or Java program on, say, a Windows system.
What the "OO-thinking AVR novices" will still meet is the same hardware, which might be low level but none the less complex. This is no different from someone coming from e.g. C on Windows, and the way to handle those "details" is no different in C++. You access the same bits in the same SFRs using the same notation.
For someone coming from C in a non-embedded context it makes sense to stay with C (but that species is diminishing and will one day be more or less extinct). For someone coming from e.g. BASIC it makes sense to start with C. But for someone actually thinking object-oriented I'm not so sure.
Go visit ten universities and see what the first programming courses on the EE and CS programmes are using. If you find more than one that uses something else than Java or C# the next beer is on me! 
This is where the world has been moving, and while small(ish) embedded systems are the last in the line it will hit us it will happen. Mind you, I'm not thinking Java or C# on a 8K flash AVR - I suspect no meaningful Java or .NET run-time will ever be compact enough for that (I gladly accept being proven wrong, though). But this is where C++ is different - you pay only for what you use. The language was explicitly designed not to bloat, and to a large extent it succeeds.
To summarize this rant: IMO it depends on where you are coming from, and the world is changing. Perhaps slowly, but it is changing. The nice thing is - there is room for us all!
-----
Now I'm off to read your blogs, Chip! If you think this OT/tread-jacking was wrong just let me know and I'll talk to a moderator about breaking it out to it's own thread.
Code:
Freak johan = AVRfreaks.GetMember("johanekdahl");
Freak chip = AVRfreaks.GetMember("coverclock");
foreach (Blog blog in chip.GetWebSite().blogs)
{
johan.Read(blog)
}
...or, if you wish...
Code:
Freak johan = ForumGetMember(AVRfreaks, "johanekdahl");
Freak chip = ForumGetMember( AVRfreaks("coverclock");
WebSite webSite = GetWebSite(chip);
for (int i = 0; i < webSite.blogCount; i++)
{
ReadBlog(johan, webSite.blogs[i];
}
Your call.. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 17, 2012 - 08:43 PM |
|
Joined: Mar 27, 2002
Posts: 18581
Location: Lund, Sweden
|
|
Chip!
I just skimmed the two blogs for the last two minutes. I think I will have to waste a part of a tree and print them out, sit (ok, more lie than sit...) down in a sofa with some tea. Looks very interesting!
The second one touches on some of the things I have also thought. I will read the passage on templates extra carefully.
Just in case you've missed it: Let me point to the columns of Dan Saks at embedded.com . A lot (as in "A LOT!") of C++-for-embedded goodies there. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 18, 2012 - 09:21 PM |
|
Joined: Mar 08, 2012
Posts: 13
Location: Denver Colorado USA
|
|
Thanks for all the kind words and just generally taking the time to respond.
I started out doing embedded stuff in assembler in the 1970s on PDP-11s. But my experience in large embedded development organizations, mostly at Bell Labs, has convinced me that C++ is a win in the embedded space. But perhaps not for beginners.
I have the privilege of knowing Dan Saks. Back when I was teaching this stuff in the 1980s, he and I were both faculty members at the same university and had offices across the hall from one another. I believe he may have been on the C standards committee at that time. I still keep up with him via email from time to time even though we're 1200 miles apart now. He's been kind enough to correct me from time to time on my blog when I've misspoke.
Thanks again. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 19, 2012 - 03:36 AM |
|
Joined: Jun 19, 2002
Posts: 957
Location: SF Bay area
|
|
|
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... |
|
|
| |
|
|
|
|
|
|
Posted: Apr 19, 2012 - 03:54 AM |
|
Joined: Dec 18, 2001
Posts: 4717
|
|
IMO (uh oh)
C++ on a small memory micro- where you don't use "new" (from malloc) and "delete" and constructors are ill-advised, leads you to the only advantage being dots in the function names. The objects are static.
The code is cute. But no real difference in just using prudent names in plain C.
I abhor function name overloading. Really obtuse code.
But, C++ may have some other advantage in a small micro that hasn't hit me. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 19, 2012 - 11:50 AM |
|
Joined: Jul 18, 2005
Posts: 62354
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
I abhor function name overloading. Really obtuse code.
But that is, for example, one of the "advantages" of Arduino. It overloads the Serial.print() stuff so you can say:
Code:
int n = 12345;
char c = 'A';
char text[] = "Hello";
float f = 3.141592;
Serial.begin(9600);
Serial.print(n);
Serial.print(c);
Serial.print(text);
Serial.print(f);
|
_________________
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 04:36 PM |
|
Joined: Apr 21, 2012
Posts: 1
|
|
I am an engineer with over 25 years industry experience and have taught both seminars and semester-length CS and mech courses to high school students for several years as a part-time gig at two parochial schools. I have noted following:
1. The kids know a lot more than you realize.
2. The kids know a lot less than you assumed.
3. C++ and Java do not work for a semester or less.
4. Python works for general CS introduction.
5. C works for embedded introduction.
6. Embedded systems should not be used an instructional vehicle for introduction to programming or CS. The people using the Arduino contradict this, but represent a subset having an abnormally high motivation level. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 05:41 PM |
|
Joined: Mar 09, 2012
Posts: 1452
Location: North Carolina, USA
|
|
|
stevech wrote:
C++ on a small memory micro- where you don't use "new" (from malloc) and "delete" and constructors are ill-advised, leads you to the only advantage being dots in the function names. The objects are static.
Huh ? You should never use new if you can achieve the desired object lifespan without it. There are plenty of advantages besides "dots in the function name". |
|
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 06:02 PM |
|
Joined: Mar 09, 2012
Posts: 1452
Location: North Carolina, USA
|
|
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 ")) |
Last edited by ChaunceyGardiner on Apr 21, 2012 - 11:14 PM; edited 1 time in total
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 07:10 PM |
|
Joined: Nov 17, 2004
Posts: 6137
Location: Great Smokey Mountains.
|
|
|
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
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 07:51 PM |
|
Joined: Mar 27, 2002
Posts: 18581
Location: Lund, Sweden
|
|
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. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 08:31 PM |
|
Joined: Jul 18, 2005
Posts: 62354
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
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" |
_________________
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 08:54 PM |
|
Joined: Mar 27, 2002
Posts: 18581
Location: Lund, Sweden
|
|
| 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. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 08:58 PM |
|
Joined: Nov 17, 2004
Posts: 6137
Location: Great Smokey Mountains.
|
|
|
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
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 09:08 PM |
|
Joined: Mar 09, 2012
Posts: 1452
Location: North Carolina, USA
|
|
|
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. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 09:09 PM |
|
Joined: Mar 09, 2012
Posts: 1452
Location: North Carolina, USA
|
|
|
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. |
|
|
| |
|
|
|
|
|
|
Posted: Apr 21, 2012 - 10:44 PM |
|
Joined: Dec 18, 2001
Posts: 4717
|
|
| [quote="ChaunceyGardiner"]
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). |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
