C++ learning project

Thread Starter

JMac3108

Joined Aug 16, 2010
348
I'm a passable C programmer (microcontrollers) and have been assigned to write a C++ program at work, for the purpose of learning C++.

I'm looking for an idea for a program to write. The first requirement is that the target is a microcontroller. I'll use an MSP430 since I have several boards I've designed with them, and a couple development boards. The next requirement is that the program demonstrate several classes, polymorphism, overloading functions, constructors, and destructors.

I've done enough studying to know the basics of what these are. I just need a good idea for a program to demonstrate them. They don't care what I write, as long as it demonstrates an understanding of these concepts.

Any ideas would be much appreciated. Thanks!
 

tshuck

Joined Oct 18, 2012
3,534
I would recommend a base serial class from which to inherit. Derive SPI, I2C, and UART classes from each and overload some of the functionality of the base serial class. In each constructor, you could setup the device for the specified class.

This way, your program could easily be to correlate to your job.

-Tim
 

kubeek

Joined Sep 20, 2005
5,794
What tshuck recommended looks like a nice example to me. However I don´t see the point in using C++ on such small chip as an MSP430 in the real world. Yes for learning c++ anything can do, but I see it much better suited for larger and more complex chips like 32bit. The overhead of c++ may be too much for such small micro.
Anyway I would be interested in seeing the listing of the assembler and comparing it to the C++ code.
 

Thread Starter

JMac3108

Joined Aug 16, 2010
348
Well, I agree, I'm not yet convinced that C++ buys a lot on a small micro. However, my boss has written extensive C++ for micros, including a very nice RTOS that he designed. So if he says C++, then C++ it is!

I thought about the serial application (UART, SPI, I2C), but my boss has already written a comprehensive set of serial communication classes in C++ and uses them on various micros including the MSP430. Anything I wrote on this topic would be second-best and he would not be satisfied.

I was thinking of writting a program to draw shapes on an LCD. Perhaps a base class called SHAPE and then various derived classes such as RECTANGLE and CIRCLE. I can define basic functions such as setting or moving the origin of the shape in the SHAPE class. The SHAPE class could also include virtual functions such as Draw() of Fill() that would be over-ridden in the derived classes.

What do you think?
 

kubeek

Joined Sep 20, 2005
5,794
That is not a bad idea, however everything depends on how much is this just a coding excersise and how much it has to be finished in the end. But if you can actually get some code that allows you to draw on the lcd then why not.
 

Thread Starter

JMac3108

Joined Aug 16, 2010
348
Kubeek,

As I said, I don't yet see the advantage of C++ in the smaller micros.

But, I'm not sure that overhead is a problem here. The increase in overhead would be if I included a bunch of C++ libraries as you do when programming in a desktop environment. On a 16-bit micro such as the MSP430, programming in C++ just means setting up and manipulating data structures in the C++ methodology. The program is more data focused than procedurally focused. Compilers are smart these days, and I'm not sure that the approach really makes a big difference in the code size. Any opinions on this? I'm new to C++ so I'm still figuring this out.
 

kubeek

Joined Sep 20, 2005
5,794
I am no expert on compilers and c++, but I would think that the biggest overheads are when you create and destroy lots of small objects, comapred to just keeping track of the stored data by yourself.
I don´t have any c++ compiler for micros right now, so you can try writing some equivalent code in C and C++ and tell us what the differences are ;)
 

Thread Starter

JMac3108

Joined Aug 16, 2010
348
Its just a programming exercise. Does not have to be a practical application.

I'd like to do what you suggest, and probably will later, but for now I'm not knowledgeable enough in C++ to write "equivalent code". There is probably some level of skill involved in managing objects in memory in C++ and without knowing what I'm doing I might unfairly bloat the code.

In any case, I have a bunch of C++ code written on my whiteboard to create a SHAPE class, and a RECTANGLE class derived from it. The LCD details will be stubbed out for now, I just want to see if I can get it to compile and run. I just got a TI Launchpad MSP430 development board running using IAR - wrote a hello world program to blink an LED.
 

kubeek

Joined Sep 20, 2005
5,794
You migt as well try compiling the code without the msp specific parts in a standard c++ compiler and debugger and run it on pc, it will free you of constant loadng and testing it inside the msp.
 

Thread Starter

JMac3108

Joined Aug 16, 2010
348
I don't have a desktop c++ environement to work in. And I don't like the free ones like MinGW that run in a command shell.

I'm using IAR for the MSP430 and it has a really nice IDE to work in. Downloading the code into the MSP and running the debugger takes only the click of a single button in the IDE. I program the MSP430's every day so its no problem for me.

Also, once I decide I can get the C++ coded, I'll get an LCD and actually implement it on the MSP. Much more interesting that just putting stuff on the PC screen.

BUT, I admit that its harder to debug on the MSP because right now I have no external interface on my development board other than an LED to blink. Makes it tedious to debug. I may wire up a serial port and connect it to a PC running HyperTerm for better debug capability.
 

kubeek

Joined Sep 20, 2005
5,794
IIRC the msp is programmed by a serial link, so if you hook resistors between the programming pins and the uart RX and TX, you can print debug messages. That is resistors R12 and R13 in that pdf.
 

Attachments

Last edited:

Thread Starter

JMac3108

Joined Aug 16, 2010
348
Not sure what IIRC is?

I program the MSP430 boards I design using JTAG through the TI FET debugger which is USB. And right now I'm using a TI Launchpad development board which also uses JTAG via USB.

But the MSP430G2553 chip in my Launchpad has a UART. And I have a small adapter board I made with a MAX232. So its just a matter or a couple wires and a little code to get my serial link if I want it.

Thanks :)

BTW, this afternoon I wrote some C++ code to creat classes and was able to get it to compile and run on the MSP430. I created an abstract class called SHAPE, and derived a class called RECTANGLE from it. Still not seeing the benefit of all this, but I'm going to stick with it and see.
 

Thread Starter

JMac3108

Joined Aug 16, 2010
348
Status update ...

Serial port running and sending debug messages from my MSP430 launchpad board to a PC.

Wrote a SHAPE class and derived a Rectangle and Circle class from it.

Will order an LCD today so that I can actually draw and manipulate these objects.

For now I stubbed out the code with debug messages that I send to the PC. The code creates an instance of a rectangle and moves it around the edge of the LCD screen. It also creates an instance of a circle, and bounces it from top to bottom of the screen. Of course when I say I'm moving a shape, all I mean is that I'm sending debug messages to the PC that show the x,y coordinates that it would be placed at if I had an LCD.

Still not sold on the benefits of C++ for microcontrollers, but will proceed ...
 

takao21203

Joined Apr 28, 2012
3,702
It is beneficiary for instance if you want to maintain a "treeview" list.

This has been done using plain C, but it is very complicated. OOP makes things like this much easier.

C++ is not automatically beneficiary.

So you can also blend in regular C into C++.

C++ mainly makes sense for larger projects, maintained by more than one person. Data becomes incapsulated together with correlating functions into "classes". Multiple instances can be spawned in memory.
 
What you could do is to take some of your existing C projects and visualize them as object-oriented projects. The _only_ difference between C and C++ is C++ support OOP. When your boss says that he wants you to learn C++, he (or she) is really asking you to learn OOP. So, let's say you've written a library of some sort to support a 1602 LCD. What you want to do is encapsulate that code and data into a C++ class. It would be best to start with a base class that is general to all LCD displays, and the derive new classes for more specific implementations of different LCDs.
AFA C++ code taking more memory or processing power, I say "not at all". Your C++ may take more coding, but it doesn't mean that more code is generated. Man, if not most of my C++ implementations have come out faster and less memory consuming than the C code that they replaced. I think maybe because OOP forces you to think out your design more thoroughly. After a couple of sucessful C++ projects, you'll never want to write C again!
 

takao21203

Joined Apr 28, 2012
3,702
What you could do is to take some of your existing C projects and visualize them as object-oriented projects. The _only_ difference between C and C++ is C++ support OOP. When your boss says that he wants you to learn C++, he (or she) is really asking you to learn OOP. So, let's say you've written a library of some sort to support a 1602 LCD. What you want to do is encapsulate that code and data into a C++ class. It would be best to start with a base class that is general to all LCD displays, and the derive new classes for more specific implementations of different LCDs.
AFA C++ code taking more memory or processing power, I say "not at all". Your C++ may take more coding, but it doesn't mean that more code is generated. Man, if not most of my C++ implementations have come out faster and less memory consuming than the C code that they replaced. I think maybe because OOP forces you to think out your design more thoroughly. After a couple of sucessful C++ projects, you'll never want to write C again!
You can design any program on the principles of OOP. Spawn a lot of stuff on the heap, and it is kind of OOP, even if it based on assembler. If you don't have a heap, simulate it using large Arrays...

Visual C++ is some kind of standard what you can do with modern C++, and what you for instance can not really do with embedded C. Most small controllers have some 100 bytes RAM to a few KBytes, at max. Be it, you add large external memories...

If you use dynamic elements like for instance the treeview I have mentioned, then it makes sense to use a dynamic language.

You can do static "OOP", build up a base library, and extend it using a hirarchy. Sooner or later you'll run into trouble because there is no encapsulation.

And what if you need two instances at once? There will be common variables, and they will be changed by the other thread. So if you have class design, you can spawn a new instance on the heap. This is something you can not do easily manually, even if it is thinkable. Assembler programmers have done a lot of weird things over the years.

I have used OOP for a number of years, and recently I have learned new C++ entensions. I still don't really know if I understand all of the above elaborations. And I also saw old C code which implemented dynamic structures (like for instance tree lists). Quite complicated, actually horrible.

So I think OOP came to life due to a neccecity, together with modern GUI operating systems.
 
Without trying to add a lot of confusion I'd like to clarify (at least) one thing. Opp is not about where things are stored. They are stored in the same manner as in any other language. For instance, if you create 2 instances of a class, there is really only one instance of the methods. 2 instances of the class properties (variable) must be created and their location is of no concern. They have to live somewhere. The encapsulation provided by the class simply, programatically prevents access by methods outside the class. Even if the properties are declared as public, an instance of the class must be used to refer to the property ( int i = objecta.aInt ).
Class SerialPort
{
SerialPort(int aSpeed, int aPort);
~SerialPort();
private:
int speed;
int port;
char buffer[256];
public:
const char* receive();
int send(char* buff);
}
int main(int, char**)
{
const char* msg;
SerialPort portA = SerialPort(9600, 2); // an instance of a serial port
SerialPort portB = SerialPort(9600, 3); // another instance
while ((msg = portA.Receive() != NULL)
portB.send(msg);
}
// ignore rules about "best practice ;-}

Both of these instances were allocated exactly as the would have been if it were a standard C program.
or you could:
SerialPort portA = new SerialPort(9600,2);
const char* msg = portA->receive();
and all of the variables would reside on the heap.
within the lass you could have done:
char* buff = new char(256);
and the buffer would reside on the heap. This would give us the advantage of rewriting our class as class SerialPort
{
SerialPort(int aSpeed, int aPort, unsigned buffsz)

So that you could size the buffer to your needs when the instance is created. Note that the buffer would be allocated on the heap;

Whether it lives on the heap or in program memory matters not; you still have to have a place to put it. The good thing about variables stored on the heap is that the memory is released when you dispose of the object or the object goes out of scope.

Also, don't think that just because a class object has its own methods means that with 2 objects, 2 copies of the methods are created. Nope, both objects use the same methods in the same location. A reference to the instance of the object is passed when calling the method so that it knows with object's data to deal with.

If you don't have enough memory to store the variables in C++ you won't have enough memory to store them in ASM. If you need more data than your chip will store, think about adding an SD card and using the SD card as virtual memory. This is what I've done so I can store a week's worth of TV Guide on my ATTINY 85 based appliance.

You _can_ do object-oriented programming in C or even ASM. C++ just provides the syntactic sugar that makes it sooo much sweeter. :)
 
BTW, JMac...
AFA a useful C++ project, has you boss written an LCD Class. Since you know how to write to an LCD, I assume you may have the occasion to use different types of LCD displays. So you could write a base class something like
class GenericLCDDisplay
private:
int rows;
int cols;
protected:
virtual int putPixel(int x, int y, int color);
virtual int putchar(int aRow, int aCol);
...
}
class 1602LCDDisplay()
{
public:
1602LCDDisplay() : rows(2), cols(16)
int putPixel(int x, int y);
int putchar(int aRow, int aCol);
...
}
class 3204LCDDisplay()
{
public:
3204LCDDisplay() : Rows(4), cols(32)
int putPixel(int x, int y color);
int putChar(int row, int col);
....
}
class 1602ColorLCDDisplay() : public 1602LCDDisplay
{
public:
1602ColorLCDDisplay { 1602LCDDisplay() };
int putPixel(int x, int y, int color);
int putChar(int row, int col, int color);
}
You get the idea... I haven't looked into the LCD Display's internals because I use somebody else's class library and I don't need to know the internals of it. Nice thing about oop - don't you agree :)
 

Thread Starter

JMac3108

Joined Aug 16, 2010
348
Thanks Chris, good idea. I've written classes to creategraphics objects. Now I'll create classes for the LCD as you said.

BTW, Smyrna? I used to live in Smyrna GA.
 
Top