Raspberry Pi Forums

Posted: **Sun Dec 08, 2019 3:12 am**

I understand what is a class and object I am looking simple example of class and object in c++ for electronics project

Class is a blueprint for an object. Classes describe the type of objects. The object can be of different types: A class can have both data members and functions members associated with it.
A class is defined by:

Code: Select all

class MyClass
{
 /* public, protected and private
 variables and functions */
};

For example There are many types of switches in market https://www.electronicshub.org/switches/

SPST Single Pole Single Throw Switch
SPDT Single Pole Double Throw Switch
DPST Double Pole Single Throw Switch
DPDT Double Pole Double Throw Switch
Push Button Switch

Code: Select all

class SWITCH
{
 /* public, protected and private
 variables and functions */
};

We can say that SPST is an object of the class known as SWITCH. It has only one pin
We can say that SPDT is an object of the class known as SWITCH. It has only three pins

I am looking meaningful examples of class and object in context of embedded programming. Can anyone give me some meaningful example of class and object in embedded programming

Posted: **Sun Dec 08, 2019 6:40 pm**

Your definition of Class is quite good, but you have not described an Object well.

In your example, a SWITCH is a class - a definition or blueprint of what properties/attributes a switch has and what methods/functions it has, i.e what it can do. In this case it represents ALL types of switches, or at least the common behaviour of all switches, so we can call it a BASE class.

You then go on to explain different types of switches - SPST, SPDT etc. But these are not yet objects. They are still definitions or blueprints of more specialised types of switches, so they are still CLASSES. Because they all INHERIT the same behaviour of the base switch, and include all their common behaviour and properties, we call them a SUBCLASS. So what you are actually explaining is INHERITANCE, which leads onto POLYMORPHISM.

An OBJECT is an actual implementation of a class blueprint (not a TYPE of a class).

As we are talking about blueprints, let's look at an analogy of a house.
We can all write a definition of what a HOUSE is, and create a BLUEPRINT for one, having a door, some windows etc.
But It's just a class definition, not a real house.
If you go to a new housing estate, the showroom will show you looks of plans of differnt types or designed of houses: a Belmont, a Bellview, a Warwick etc. Again these are just class definitions. they still have a door, some windows etc, but they may look a bit different, or have a different number of bedrooms.
But you don't want to buy the class (blueprint), you want to buy your own real house. This is the implementation of one of those house designs. i.e. not just A Belmont type, but a particular one, with an address, and your choice of bathroom suite and kitchen untis etc. All the Belmonts will have the same features, but only yours will be unique to you.

So back to your switches, an SPST is a particular type of switch, but you could have several of them performing specific functions. So they would be implemented as OBJECTS/instances. i.e SPST1, SPST2, SPST3 etc.

In C/C++

Code: Select all

class CSwitch
{
 /* public, protected and private
 variables and functions */
};

class CSPST : public CSwitch
{
 /* public, protected and private
 variables and functions */
};

int main(...)
{
    CSPST MySPST1 = new CSPST();    /* Create an Object of SPST */
    CSPST MySPST2 = new CSPST();    /* Create an Object of SPST */

   /* Do something with your switches */

   delete MySPST1;   /* Delete your instance/object. It no longer exists! */
   delete MySPST2;  /* Delete your instance/object. It no longer exists! */
}

So a CLASS is a definition. The definition always exists.
An OBJECT is an implementation of that class and has a LIFETIME. i.e. it only exists within a particular scope within your program.

Hope that helps.

*(House names are fictitious and any resemblance to actual house styles is purely coincidental!)

Posted: **Sun Dec 08, 2019 9:43 pm**

abhi143,

We can say that SPST is an object of the class known as SWITCH. It has only one pin
We can say that SPDT is an object of the class known as SWITCH. It has only three pins

No. We cannot. An SPST is a kind of Switch. An SPDT is a different kind of switch. They are not the same class. Besides, all real switches I know have at least 2 pins.

There is no short answer to your question. There is no short example of use of classes and objects in C++ that will make it clear.

At some high-level of abstraction what is a "switch"?

1) It is a device with some states of being: ON or OFF or perhaps many other states if it is a multi-way switch: 0, 1, 2, 3 or whatever.

2) It can only be in one state at a time.

3) It has some input that can cause it to change state. ON to OFF. 3 to 4 etc.

4) Notionally it has some number of inputs, call it N. And some number of outputs, call in M.

5) In each state it connects some of the inputs N to some of the outputs M. According to some rules.

So, we might model this concept of a "switch" as a class called "Switch". It has some definition of "state". It has some definition of control input. It has some definition of some number of inputs and outputs (N and M).

So what about our SPST and SPDT switches?

They are classes derived from our Switch class by inheritance. They further specify exact numbers of states and number of inputs and outputs. They exactly specify how inputs are connected to outputs in each state.

As you can imagine this gets quite complicated. Modeling things in the Object Oriented way is hard. Even for a simple switch! There are perhaps other ways you would organize your classes to model switches. Depending on how your application might use them.

All in all I would suggest learning more about C++ and object oriented programming before you start worrying about classes in embedded programming.

If, like me and many others now a days, you work at this for 20 years you might realize that OOP is the wrong approach anyway...

Posted: **Sun Dec 08, 2019 9:57 pm**

An electronics example is actually quite a tough one to start with because there will lots of hidden things depending on how much detail is required. I also haven't done analog electronics for nearly 4 decades!

Using the first diagram from the link you provided here's a rough template..

Code: Select all

#include <iostream>

//<description> (header)
class Battery   {
protected:
unsigned        voltage,        //mV
                capacity;       //aH

public:
                Battery();
};

class Switch    {
protected:
bool    closed;

public:
        Switch(bool);
};

class Lamp      {
protected:
unsigned        resistence;     //mOhm

public:
                Lamp(unsigned);
};

class CircuitTypeOne : public Battery, Switch, Lamp     {
bool            active;

private:
double          CalcCurrent(void)const;

public:
                CircuitTypeOne(bool active_);
double          Current(void)const;
};
//</description>

//<implementaion> (code)
Battery::Battery(
) :     voltage         (1300),
        capacity        (2000)
{
}

Switch::Switch(
        bool closed_
) :     closed  (closed_)
{}

Lamp::Lamp(
        unsigned resistence_
) :     resistence      (resistence_)
{}


double
CircuitTypeOne::CalcCurrent(
)       const
{
 return double(voltage) / resistence;
}

CircuitTypeOne::CircuitTypeOne(
        bool    active_
) :     Switch  (active_),
        Lamp    (1000)
{}

double
CircuitTypeOne::Current(
)       const
{
 return closed ? CalcCurrent() : 0;
}
//</implementaion>

using namespace std;

int
main ()
{CircuitTypeOne c1      (false),
                c2      (true);
//^^^class      ^^objects

 cout << c1.Current() << endl;
 cout << c2.Current() << endl;

 return 0;
}

Those switches could be implemented using inheritance when there's only a few kinds. A generic solution needs to cater for any number of inputs potentially connected to any number of outputs so I suspect that would be designed differently. Inheritance isn't used as much in the real world as you'd first think - unless you program java (shudder) - oh, now I feel a bit faint!

Posted: **Sun Dec 08, 2019 10:18 pm**

swampdog,

Oh boy. That is a thing. You have introduced a hundred other concepts besides "switch". Volts, amps, batteries, lamps, the whole circuit simulation!

Posted: **Sun Dec 08, 2019 10:38 pm**

Heater wrote: ↑
Sun Dec 08, 2019 10:18 pm
swampdog,

Oh boy. That is a thing. You have introduced a hundred other concepts besides "switch". Volts, amps, batteries, lamps, the whole circuit simulation!

The switches seemed too complex. They might arc. You'd need to take electromagnetic interference into account so there'd be a "radio broadcast" subclass and each component would have to specify its susceptibility levels. Physical distances, ariel(*) characteristics and not forgetting hydraulics and so forth for those bigger busbars: once we get to substations there's the weather to consider.

(*) typo. I mean't aerial but left it in because it brings up the possibility of considering shorting by foreign objects, typically birds but a substation in africa might have a gazelle leap into it.

Hmm, time I got some sleep!

Posted: **Sun Dec 08, 2019 10:56 pm**

swampdog,

The switches seemed too complex. They might arc....

Indeed.

But switches need not be electrical. I have worked on control systems with a lot of hydraulic switches. Spool valves. It's amazing what logic you can do with those. Then you have issues of fluid pressure and so on.

I have also built a two bit binary counter out of 1 meter long pneumatic rams and pneumatic spool valves.

All with designed with something similar to the abstract "Switch" class I spoke of above. Except I had no C++ or even a computer in those days.

Posted: **Mon Dec 09, 2019 12:57 am**

The important things about a switch is it has states as heater correctly described it PIN M connects to PIN N.
So what you can more easily describe is the states so if we go with M and N you can describe it as a state or enumeration of pole connections

Your description of the switch themselves do that the M is the POLES
SP OR 1P = SINGLE POLE
DP OR 2P = DOUBLE POLE
TP OR 3P= TRIPLE POLE
QP OR 4P = QUAD POLE

Your next description is the N or number of throws
ST or 1T = SINGLE THROW ... aka one connection one no connection
DT or 2T = DOUBLE THROW ... aka two connections
TT or 3T = TRIPLE THROW .... aka three connections
QT or 4T = QUAD throw ... aka four connections

In four letters I can completely describe the switch and that is the hint to how to abstract it

You can even get complex constructions with addition work out what this switch does
SPST+DPDT .... hint is it actually describes two switches mechanically connected
Try SPQT .. its should be obvious what it does.

The number of connections to the switch is defined by the formula (poles + poles * throws)
SPST = 1 + 1*1 = 2 PINS
SPDT = 1 + 1*2 = 3 PINS
DPDT = 2 + 2*2 = 6 PINS
DP4T = 2 + 2*4 = 10 PINS

So this might be a good start as it describes the behaviour of the switch

Code: Select all

int Poles;
int throws;

Posted: **Mon Dec 09, 2019 3:22 am**

Heater wrote: ↑
Sun Dec 08, 2019 9:43 pm
abhi143,
.
All in all I would suggest learning more about C++ and object oriented programming before you start worrying about classes in embedded programming.
Thanks to all of you for excellent advice's

@Heater I am totally agree with you. I am not very good at c++ programming but I am practicing on it to improve my skills.

I saw so many general example for object oriented programming

For example , Vehicle is blue print for all objects we can create one class of objects called "Vehicle" and call the same code for
"objects" are defined by their similarities and differences with other objects.

Vehicles Parts: wheels, engine, brakes, steering wheel

Vehicles Property: speed, wheel size, window size, fuel capacity

Each Vehicle has a different wheels, engine, brakes, steering wheel , speed, wheel size, window size, fuel capacity we can create a single set of properties and methods for all Vehicles

I can tell other examples for example animals,, employee, fruits and so many

I just asked some oop example in context of Embedded because I just looking meaningful example of oop in embedded programming. It would easy to understand

I gave one example switch, Now can you give one simple meaningful example of class in embedded programming ?

Posted: **Mon Dec 09, 2019 4:12 am**

Your statement above is illogical ... embedded has no relationship to class.

Embedded device simply means the device runs a fixed set of tasks that have limited ability to change.
So all of your classes above may exist on an embedded system it depends what it does.

The main reason you are classing things is so you can re-use the code. Now if you are after the obvious
most common thing on any system that is probably classed even if not thru OOP but interface would be
device drivers. The reason is obvious the code to drive them may be complex and you will get variations
of same device and you will want to use the code on various boards. You don't want to write that complex
code multiple times so you will class it in some way. The upshot of the above is complex device layers are
generally classed in both embedded and desktop systems.

For the above in C you will probably hide the class behind function pointers and struct variants (we dont
call them classes but that is what they are), while on C++ you could easily use OOP.

It is worth a note deep inheritance OOP is rare these days as the modern principle is Composition over inheritance
https://en.wikipedia.org/wiki/Compositi ... nheritance
If you have ever used MFC on windows you will know why Microsoft stopped with it

Posted: **Mon Dec 09, 2019 6:03 am**

abhi143:

Now can you give one simple meaningful example of class in embedded programming ?

Your question does not make much sense. Or is very vague anyway.

When people think of "embedded system" programming they often mean programming some computer that is part of some other system and running some fixed program that makes that system work. That could be anything from a tiny 8 bit micro-controller with no operating system to bigger things like the Pi running Linux.

C++ used in such systems is much the same as using C++ anywhere else. Except your classes may now be modeling things like GPIO pins, the hardware registers of a serial port and all kind of other peripherals.

Posted: **Mon Dec 09, 2019 9:28 am**

Heater wrote: ↑
Mon Dec 09, 2019 6:03 am
Your question does not make much sense. Or is very vague anyway.

I am agree lthere is no much difference between general c++ programming and Embedded c++ programming. only difference is that we use general c++ programming to write program for PC for example MFC on windows. we use embedded c++ program to program microcontroller such as ARM, Aruino, PiC

If someone has basic knowledge of c programming and if he want's to start to write embedded program then my advice to start with very basic and simple example.

1. Write program for LED blinking
2. Write a program to on/off LED if switch is activated
3. Write a program to on/off Motor if sensor is activated
4. try to on/off two LED's with two switches
5. Write program to display name on the screen
6. Make calculator using keypad and LCD display
7. Uart : Send data from microcontroller to PC
8. I2C : write a program to transfer/ receive data from master to slave read temprature signal via i2c
9. SPI : write a program to transfer/ receive data from master to slave read temprature signal via SPI

if someone knows the c language and he is directly trying to write code for LCD display I think He will get trouble He should start with some simple examples first

I am following same approach I want to write embedded program using OOP concept. If we remove oop concept in c++, then c++ is same as c. My focus is to write a embedded program with OOP.

My question Have you used inheritance in real time project. Can you tell me with few lines why did you think you should use inheritance

Posted: **Mon Dec 09, 2019 10:42 am**

It depends on the complexity of your project.
If it's simple you may be able to solve it using C.
For me C++ makes it easier to solve the coding challenges I face, including many (but not all) OOP concepts. I don't think I could solve the challenges with C alone.

/Mogens

Posted: **Mon Dec 09, 2019 10:44 am**

Heater wrote: ↑
Sun Dec 08, 2019 10:56 pm
swampdog,
The switches seemed too complex. They might arc....
Indeed.

But switches need not be electrical. I have worked on control systems with a lot of hydraulic switches. Spool valves. It's amazing what logic you can do with those. Then you have issues of fluid pressure and so on.

I have also built a two bit binary counter out of 1 meter long pneumatic rams and pneumatic spool valves.

All with designed with something similar to the abstract "Switch" class I spoke of above. Except I had no C++ or even a computer in those days.

That all sounds rather cool!

Posted: **Mon Dec 09, 2019 12:02 pm**

abhi143 wrote: ↑
Mon Dec 09, 2019 9:28 am
I am following same approach I want to write embedded program using OOP concept. If we remove oop concept in c++, then c++ is same as c. My focus is to write a embedded program with OOP.

My question Have you used inheritance in real time project. Can you tell me with few lines why did you think you should use inheritance

That almost sounds like an exam question?

Graphics is by far the most obvious candidate for inheritance. You could write the entire GUI in C++ without actually drawing anything visible. All you'd require is an arc drawing base class and derive all other shapes from that. It would not be efficient but it could be done.

The STL is where you'll see inheritance used most in C++ and that isn't really the oop concept you seem to have in mind. When you use (say) "cout" there's a whole load of inherited stuff. Goto https://en.cppreference.com/w/cpp/io/cout and hover your mouse over the [C++][Input/output library][std::basic_ostream] tabs at the top.

You need a concrete definition for "embedded" otherwise it's not possible to proceed. Embedded system A might only have a serial port whereas embedded system B (like a pi) might have a graphics chip. You could even define a headless machine in a server rack as embedded if your definition is "no graphics" (or even no hard disks) but that doesn't stop those machines doing graphics (or accessing disks): the displaying (or disk access) just needs to be done elsewhere.

For want of a better definition, my idea of an embedded system is one which has no operating system. This means it is not possible to launch a program normally (C, C++ or any language) so either you write a rudimentary OS for it (not embedded any more in my book) or you choose to fire it up from assembler (and you'll still need to write a runtime startup). In the latter case, it's likely there aren't enough resources so you'd choose C over C++ making the question largely(*) moot.

(*) If you consider (eg: a modern graphics card) an embedded system then it has a ton of ram so C++ could be used but either you'll need to write a memory manager (starting off down the write an OS route again) or not use any feature which might allocate ram so we're back to C.

Posted: **Tue Dec 10, 2019 8:11 am**

Swampdog,

...my idea of an embedded system is one which has no operating system...

Which is not the commonly accepted meaning in the industry. Which is more like what you read here: https://en.wikipedia.org/wiki/Embedded_system

I have worked on embedded systems that were far bigger than a micro-controller. We use Raspberry Pi and Linux in embedded systems. There is a plethora of operating systems used in embedded systems: https://en.wikipedia.org/wiki/Category: ... ng_systems Most of the embedded operating systems I have used are not on that list!

Posted: **Tue Dec 10, 2019 10:17 am**

LdB,

The main reason you are classing things is so you can re-use the code.

Could you elaborate on what you mean by "classing things" and "re-use" there?

Certainly one creates instances of objects from classes, in a way that is reusing the same code of the class for many objects.

Certainly one uses classes from libraries in many different programs. Which is code reuse.

That is all well and good but not much different from reuse of functions and structs in C.

But if you mean using classes and inheritance to create modified versions of existing code in your program. That is not what classes and object oriented programming is about. It's bad practice. It will get you into a mess. It's been advised against in books and elsewhere for years.

Summed up as "Use OOP to model "is-a" relationships, not for code reuse". See:

Effecive C++ 3rd Edition : Scott Meyers

C++ Coding Standards : Hurb Sutter and Andrei Alexandrescu

Beginners should start here:
https://www.youtube.com/watch?v=32tDTD9UJCE

Posted: **Tue Dec 10, 2019 2:47 pm**

You are getting sidetracked into stuff which has nothing to do with the OP question and is outside my care factor with C++.
Lets just say I agree with whatever the book and you say about C++ to end that argument and get back to the OP.

So the OP even asked you directly

I am following same approach I want to write embedded program using OOP concept. If we remove oop concept in c++, then c++ is same as c. My focus is to write a embedded program with OOP.
My question Have you used inheritance in real time project. Can you tell me with few lines why did you think you should use inheritance

So you stated

Summed up as "Use OOP to model "is-a" relationships, not for code reuse

So show him an example of a "is-a" relationship.

Posted: **Tue Dec 10, 2019 2:52 pm**

Heater wrote: ↑
Tue Dec 10, 2019 8:11 am
Swampdog,
...my idea of an embedded system is one which has no operating system...
Which is not the commonly accepted meaning in the industry. Which is more like what you read here: https://en.wikipedia.org/wiki/Embedded_system

I have worked on embedded systems that were far bigger than a micro-controller. We use Raspberry Pi and Linux in embedded systems. There is a plethora of operating systems used in embedded systems: https://en.wikipedia.org/wiki/Category: ... ng_systems Most of the embedded operating systems I have used are not on that list!

I'm trying to get the OP to define what he means. We could debate what the wiki says there but methinks all we'd end up doing is going round in circles defining what an operating system is.

Posted: **Tue Dec 10, 2019 3:01 pm**

swampdog wrote: ↑
Tue Dec 10, 2019 2:52 pm
I'm trying to get the OP to define what he means. We could debate what the wiki says there but methinks all we'd end up doing is going round in circles defining what an operating system is.

To me you are the one going in circles, so lets just define it as like circle (a pun) from rst that is an entire general O/S for the Pi in C++
https://github.com/rsta2/circle
I take it that is the sort of thing he is trying to do.

What he is asking is how should he start out with the class and inheriting, what is the best practice approach.
Not my cup of tea I write O/S's in C, so can someone with a strong C++ background help.

Posted: **Tue Dec 10, 2019 3:34 pm**

LdB wrote: ↑
Tue Dec 10, 2019 3:01 pm

swampdog wrote: ↑
Tue Dec 10, 2019 2:52 pm
I'm trying to get the OP to define what he means. We could debate what the wiki says there but methinks all we'd end up doing is going round in circles defining what an operating system is.
To me you are the one going in circles, so lets just define it as like circle (a pun) from rst that is an entire general O/S for the Pi in C++
https://github.com/rsta2/circle
I take it that is the sort of thing he is trying to do.

What he is asking is how should he start out with the class and inheriting, what is the best practice approach.
Not my cup of tea I write O/S's in C, so can someone with a strong C++ background help.

I'm not about to wade through all the code but there's nothing in the README.md that says it's an OS. It does say it's a "bare metal programming environment" because they appear to think like I do: it's not an operating system.

However. It's a good link because it may well be what the OP is trying to achieve but we won't know until they clarify.

Posted: **Tue Dec 10, 2019 10:42 pm**

swampdog,

...they appear to think like I do: it's not an operating system.

What is an operating system?

Posted: **Wed Dec 11, 2019 12:20 am**

He is playing mental hijinx where something like Circle isn't an O/S because it doesn't have apps, some sort of console to launch them and so on and whatever rubbish your swampdog O/S definition says. Circle is more like an RTOS which most of us would still call an O/S but not swampdog it fails his definition. It is of zero help to the OP but makes you look ever so clever all without having to actually deal with what is asked. The question you should have asked is why post at all it is of zero help or interest, you know the rule don't feed the trolls which is why I left it alone.

There is a bit takeaway humor but because an RTOS will not be an OS if circle isn't so what do the last two letters stand for

Posted: **Wed Dec 11, 2019 9:48 am**

LdB wrote: ↑
Wed Dec 11, 2019 12:20 am
He is playing mental hijinx where something like Circle isn't an O/S because it doesn't have apps, some sort of console to launch them and so on and whatever rubbish your swampdog O/S definition says. Circle is more like an RTOS which most of us would still call an O/S but not swampdog it fails his definition. It is of zero help to the OP but makes you look ever so clever all without having to actually deal with what is asked. The question you should have asked is why post at all it is of zero help or interest, you know the rule don't feed the trolls which is why I left it alone.

There is a bit takeaway humor but because an RTOS will not be an OS if circle isn't so what do the last two letters stand for

There's no need to get abusive. I came up with some code. I gave examples of what may or may not be considered embedded and I tried to prevent exactly this discussion taking place which on the mention of "circle" you posted your link thereby causing exactly what needed to be avoided, seemingly having not read any other part of my post - and no definition of your own of what an OS is. There isn't one. It's a generic term.

Let us calm down.

The OP has to figure out what they mean by embedded. I'm as happy as the next man to use the term OS generically. In this instance though that term is not good enough on its own - as we're all proving!

Posted: **Wed Dec 11, 2019 9:56 am**

swampdog wrote: ↑
Tue Dec 10, 2019 2:52 pm

swampdog wrote:
LdB wrote: ↑
Tue Dec 10, 2019 3:01 pm

To me you are the one going in circles, so lets just define it as like circle (a pun) from rst that is an entire general O/S for the Pi in C++
https://github.com/rsta2/circle
I take it that is the sort of thing he is trying to do.

What he is asking is how should he start out with the class and inheriting, what is the best practice approach.
Not my cup of tea I write O/S's in C, so can someone with a strong C++ background help.
I'm not about to wade through all the code but there's nothing in the README.md that says it's an OS. It does say it's a "bare metal programming environment" because they appear to think like I do: it's not an operating system.

However. It's a good link because it may well be what the OP is trying to achieve but we won't know until they clarify.
I'm trying to get the OP to define what he means. We could debate what the wiki says there but methinks all we'd end up doing is going round in circles defining what an operating system is.

I started to learn c++ programming on PC. I write c++ code on PC and get result on on PC screen. My domain is embedded system I want to develop software application for microcontroller. I want to practice on OOP concept using C++ Programming for microcontroller .

Let assume I understand inheritance in oop and I have written and practiced some examples on PC

Here are peoples know more then me still I am not exert but I am practicing more to improve my skills.

Here are some question for you

Have you ever used inheritance for real time project? and if yes then what was that ?
Do you really think inheritance was really necessary for the project?
Why did you think that inheritance is the right option for the project. ?

Raspberry Pi Forums

Simple example of class and object

Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object

Re: Simple example of class and object