Hi guys

What's your thought on using C++ on a 8 bits MCU, I see more and more reasons to use C++ because you can write an object. With the advancement (my assumption) of modem compiler, is it a good idea to use C++ now instead of C?

What's your thoughts??

 

The language you use is more a matter of personal preference or convenience. I get along fine with plain C. If I used C++, the code would look like C anyway because I don't have any formal training in object oriented programming; and, at this stage of my life (retired), I don't need to.

 

Lets tow a brick house with a VW bug instead. The OO abstractions needed for embedded 8-bit applications can be done within the C language easily.

 

Lets tow a brick house with a VW bug instead. The OO abstractions needed for embedded 8-bit applications can be done within the C language easily.

I am interested, would you mind showing me a smiple example??

 

https://www.embedded.com/electronics-blogs/object-oriented-c/4397794/Object-oriented-C-is-simple-
https://www.embedded.com/electronic...utm_source=embedded&utm_medium=relatedcontent
https://dmitryfrank.com/articles/oop_in_c

The question is why would you want to use the full OOP (a programming paradigm) style of programming possible with C++ when the non-abstract details of hardware are important? An important use of OO in embedded C is abstract hardware details into a device interface instead of a specific implementation.

 

https://www.embedded.com/electronics-blogs/object-oriented-c/4397794/Object-oriented-C-is-simple-
https://www.embedded.com/electronic...utm_source=embedded&utm_medium=relatedcontent
https://dmitryfrank.com/articles/oop_in_c

The question is why would you want to use the full OOP (a programming paradigm) style of programming possible with C++ when the non-abstract details of hardware are important?

I will read the samples later on today.

I reason I want to use C++/OOP is I can use object? Say I can put a group of functions that serve one purpose into an object instead of lots of different functions. I find it much more readable, and easier to manage code.

// using C++
packet_class packet(source, dest, ptr_to_output_func);
// then I cann do
packet.send_cmd_1();
packet.send_cmd_2();
//... ...
packet.send_cmd_n();

// if using c
void packet_send_cmd1(src, dst, ptr_to_output_func);
void packet_send_cmd2(src, dst, ptr_to_output_func);
// ... ...]
void packet_send_cmdn(src, dst, ptr_to_output_func);

 

What can be said? You dance with the girl you've got.

 

I think you are going about it backwards. You scope out the application first and then decide on the HW and SW platform to get the job done.
If you anticipate using an 8-bit system then it is very unlikely that it would have the resources to run C++.

 

No matter what language and hardware you use; there is no substitute for the right algorithm. Get that right and all will be well.

 

Just download Arduino platform... It is mainly 8 bit and C++.. Have a play!

 

Hi guys

What's your thought on using C++ on a 8 bits MCU, I see more and more reasons to use C++ because you can write an object. With the advancement (my assumption) of modem compiler, is it a good idea to use C++ now instead of C?

What's your thoughts??

C++ is not made for MCUs, especially 8 bit ones. It is made for OS. More and more I see the bad practice of using C++ for MCUs, because programmers do not know anything about the hardware.

 

C++ is not made for MCUs, especially 8 bit ones. It is made for OS. More and more I see the bad practice of using C++ for MCUs, because programmers do not know anything about the hardware.

Agreed. I even use C when I'm messing with the chipkit32 ( on the arduino platform ) C++ is designed with multiple programmers in mind.
Don't get me wrong, I like OOP, but it has its place.... Tiny 8 bits aren't one of them.

 

In my experience, C++ can be made comparatively small to C, therefore memory footprint may not be a problem. However, this strips a lot of C++ advantages and, as others have said, depending on what you are doing this may be quite taxing to processing performance (especially if you have a lot of context switching/memory arithmetic going on).

 

In my experience, C++ can be made comparatively small to C, therefore memory footprint may not be a problem. However, this strips a lot of C++ advantages and, as others have said, depending on what you are doing this may be quite taxing to processing performance (especially if you have a lot of context switching/memory arithmetic going on).

Correct. You can write 'bad' (for a good C++ programmer using most of the language) C++ or good C on a 8-bit MCU.

 

In my experience, C++ can be made comparatively small to C, therefore memory footprint may not be a problem. However, this strips a lot of C++ advantages and, as others have said, depending on what you are doing this may be quite taxing to processing performance (especially if you have a lot of context switching/memory arithmetic going on).

The main thing about c++ I am interested in is be able to use class. What’s other advantages of C++ you are referring to？

 

The main thing about c++ I am interested in is be able to use class

Classes can be done in C or Assembler... In fact C++ compiles to C then to MC so theoretically all languages are capable of producing OOP to some degree...

Take a host of variables then write several functions to work with them variables keep them in a piece of code called myClass.c..Then make certain functions available to the rest of the code but keep the variable scope local to that piece of code.... That's basically a class...

 

Classes can be done in C or Assembler... In fact C++ compiles to C then to MC so theoretically all languages are capable of producing OOP to some degree...

Take a host of variables then write several functions to work with them variables keep them in a piece of code called myClass.c..Then make certain functions available to the rest of the code but keep the variable scope local to that piece of code.... That's basically a class...

Classes are not needed in MCUs. Please stop applying the programmer's approach to hardware!

To begin with all things were written in C until recently (including windows and internet explorer).
Second there is an extension of C, called object oriented C.
Third objects are not used with MCUs and just because it works, does not means you should do it.

You are just trying to take the easy way, which is what programmers normally do and then someone else takes the blame for the problem, when the great programmer with years of experience fails. He does not know why, it must be the hardware's fault, after all the code works...... I am tired of dealing with the easy way, which is a part of the bad engineering practices that we discussed earlier!

 

Agree, 100%

What we have been witnessing for the past 40 years is code bloat, where programmers, applications and operating systems are demanding higher MIPS and more memory. Features are being added simply for visual aesthetic reasons with no functional advantages. Programmers take the lazy way out instead of writing efficient code.

Take a look at page turning features on many apps.You can turn the page as if it were a real piece of paper. On the next side of the page as you turn the page will be a full rendition following the curvature of the page to resemble a real piece of paper. Very clever. How much data processing is required to present this virtual reality? What functionality does this add to the app?

For my undergrad computer course, I wrote a chess playing program on a DEC PDP-8/S with 4k words of memory.
I designed and marketed an instrument that calculates dewpoint from temperature and relative humidity in 2k bytes on an 8-bit MCU.

We have a parallel thread going on Fault tolerant HW and SW systems. As complexity grows, so does the likelihood of system failure.

Keep it simple, smarty!

 

Classes are not needed in MCUs. Please stop applying the programmer's approach to hardware!

I totally agree with you...

WBahn mentioned in another post to stop using global variables...… No! if I'm a lone programmer and no passing to functions, well all the better.

I read David brackeen's C code optimising for quick graphical routines.... No C++ here!! He recommended global variables to speed up things and register variables if there has to be local variables...

As I said before C++ has its place... But not on tiny 8 bit MCU's...

 

So I got the message, stick with C.

The reason I asked this question is I want a better way to organize my code. The project I am working on, it needs to use 4 UARTs to talk to different stuffs, a LCD module, IOs control, a couple timer, handle user commands from one of the UART.

So I often have something like these:

// basic
lcd_send(uint8_t *payload, uint8_t len, ptr_to_output_function);
lcd_send_cmd1(some variables for this command);
lcd_send_cmd2(some variables for this command);
...
lcd_send_cmdn(some variables for this command);

bus_packet_send(uint8_t *payload, uint8_t len, ptr_to_output_function);
bus_packet_send_cmd1(some variables for this command);
bus_packet_send_cmd2(some variables for this command);
...
bus_packet_send_cmdn(some variables for this command);

...
and others commands

How would you organized these, I thought C++ is the solution because I can group them in one object. But I guess not.