Going from EMBEDDED C to C++

Go To Last Post
48 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now that compilers have largely caught up to it, I like it.

Prior to 2005 or so, give or take a couple years depending on the compiler, C++ was a dog. The Stepanov Abstraction benchmark used to show massive slowdowns for moderate levels of abstraction in many cases. Then, it seemed like everyone caught up, and compilers were peeling those abstractions back to nothing. Zero penalty.

C++ suddenly became rather interesting to me.

Anyone here that does not know C++?

I think I open the various books on C++ and have a bang at her.

Last Edited: Tue. Jan 7, 2020 - 10:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Depends what you mean by. "know" ...

 

But there are still people here that does not know 'C'

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

C++ entangles all my best efforts, so I have to say I do knot.

 

update: https://www.youtube.com/watch?v=...

Last Edited: Mon. Jan 6, 2020 - 10:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From Jack Ganssle's Embedded Muse today:

 

C++ has a very bad rap in embedded systems... because it took C and mostly added a vast range of exciting new ways in which to shoot yourself in the foot. C++-20 is an entirely new and different language to what it was last century, but has added new footguns. 

http://www.ganssle.com/tem/tem38...

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fianawarrior wrote:
Anyone here that does not know C++?
Enough to make a professor wince.

Fianawarrior wrote:
I think I open the various books on C++ ...
The likely fixed-point math addition to the C++ standard has my attention.

IIRC, have one book in a box "somewhere" from a C++ course (CEU)

C++ meta-programming scared me.

 


Bjarne Stroustrup's Homepage

GitHub - johnmcfarlane/cnl: A Compositional Numeric Library for C++ via The Embedded Muse 361 - Tools and Tips

Composition of Arithmetic Types

AVR metaprogramming (C++, article) | AVR Freaks

CEU - Continuing Education Unit

 

"Dare to be naïve." - Buckminster Fuller

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

I can write C programs in C++ - I can even use some of the new features (function overloading is nice.)

 

A lot of "book-learned C++" seems to be "look at all these neat Standard Template Libraries that do great stuff, are heavily dependent on dynamic memory allocation, and unsuitable for embedded use!"  :-(

 

And there are extremists.  I continually shake my head at the example here: https://softwareengineering.stac...

 

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

The following requires some C++ knowledge before embedded-specific training :

Embedded Systems Programming in C++ | Barr Group Training

 

C++ interpreters for educating and training one-self before operating a compiler :

 

"Dare to be naïve." - Buckminster Fuller

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

westfw wrote:

I can write C programs in C++ - I can even use some of the new features (function overloading is nice.)

 

A lot of "book-learned C++" seems to be "look at all these neat Standard Template Libraries that do great stuff, are heavily dependent on dynamic memory allocation, and unsuitable for embedded use!"  :-(

 

And there are extremists.  I continually shake my head at the example here: https://softwareengineering.stac...

 

 

Embedded C++ (EC++) removes templates, etc.   But still I prefer C for small spaces.  If you use only a fraction of code in a C++ class the compiler will drag along all the unused stuff into your flash.

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

Fianawarrior wrote:
I think I open the various books on C++ 

 

Perhaps start here:  https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list

 

and note:

 

The Definitive C++ Book Guide and List wrote:
  Unlike many other programming languages, which are often picked up on the go from tutorials found on the Internet, few are able to quickly pick up C++ without studying a well-written C++ book. It is way too big and complex for doing this. In fact, it is so big and complex, that there are very many very bad C++ books out there. And we are not talking about bad style, but things like sporting glaringly obvious factual errors and promoting abysmally bad programming styles.

 

Fianawarrior wrote:
have a bang at her.

 

See:   http://norvig.com/21-days.html

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Tue. Jan 7, 2020 - 01:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:

I can write C programs in C++ - I can even use some of the new features (function overloading is nice.)

 

Same here. And yeah, the fact that most books teach C++ as if the STL library is the alpha and omega of C++, when it's just a library, and that C++ is all about OOP, also ticks me off.

I don't care about OOP, or "proper C++" or whatever. I care about the features of C++ that help me with code modularity and readability without introducing bloat.

And there are a few, overloading is nice, as you mentioned, default function arguments also help sometimes; references, templates and constexpr can be used as a (vastly more powerful) replacement for the preprocessor.

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

El Tangas wrote:
replacement for the preprocessor

 

Sounds interesting. There was a project I noticed some time back that was well past my understanding, but I think it was doing some of that sort of magic.

 

https://github.com/jfjlaros/simpleRPC

 

Last Edited: Tue. Jan 7, 2020 - 02:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think c++ is a great choice for an mcu. For a small mcu like the avr, you are in a little different world as you don't have access to many things other than the language itself. Move up to 32bit, and you have both a compiler that probably has all the usual c++ things available (libraries), and possibly an mcu with the room to use them.

 

Even without access to all the stuff they show in the books (which are pc focused), there are plenty of things in the language itself that are very nice. There are a number of features that make life easier, and most of them have no cost in terms of code size. Most of the books and info online like to assume you are using a pc, so it does take some sifting to get at the parts that are useful.

 

Very simple example, just create a pin from the Port class/struct (as named in the datasheet), the constructor takes care of setting up the pin- invert in this case so can then use on/off things and they do not have to know that low is on for the led, set the pin in an off state (high in this case), and set the dir to output, then just turn on the led-

 

#include "Port.hpp"
int main(){
    Port<PINS::PA0, PINS::OUTL> led; //output, low is on
    led.on();
    for(;;){}
}

 

resulting asm output, which you are not going to do any better in c (or asm)-

0000026c <main>:
 26c:    80 e8           ldi    r24, 0x80 //set invert bit
 26e:    80 93 10 04     sts    0x0410, r24 //in pinstrl (now inverted, so below out/in cbi/sbi do the opposite)
 272:    08 98           cbi    0x01, 0    ; 1 //off()
 274:    00 9a           sbi    0x00, 0    ; 1 //dir output (dir is not inverted, so sbi)
 276:    08 9a           sbi    0x01, 0    ; 1 //led.on()
 278:    ff cf           rjmp    .-2 

 

you now have a pin with a name, so no need for a define, that pin has methods so no need to use a macro, and if you wanted to create a number of pins in global namespace they will all be init in startup code.

 

You can also start doing things that are not possible in c (this is just an example file I use to test things out)-

https://github.com/cv007/Avr0PlusPlus/blob/master/Example1.cpp

 

for example, I created a struct to take care of eemem (including userrow), that uses operator overloading and a tweak to the default linker script. Now eemem and userrow can be treated as a normal var- read/write. 

 

#include "Nvmctrl.hpp"

URMEM URvar<uint32_t> ur_bootcount; //a uint32_t to count # of boots the mcu has done- 32bits a little excessive :)

int main(){

    ur_bootcount++; //increment boot count

    for(;;){}

}

 

 

Another big benefit in my eyes, is you can mostly do away with defines and macros. In the above github folder there are a total of 4 defines I use, which are for the the above nvmctrl eemem functions and are simply to eliminate the need to use the __atrtibute specifier directly for the section name (URMEM above). In the pic32mm code I have on github, I have a driver for every peripheral and the only defines I had to use were in creating the usb descriptors because there was just no way I could come up with a c++ way to do what I wanted (c++ 11 anyway).

 

Once you eliminate defines and macros, you are now mostly in the compiler world and get the benefit of everything the compiler has to offer without having a word processor in between rewriting everything (defines/macros).

 

I can write some c++ in the pc world, but there are too many other languages or variations that are probably better for many users (c#, python, etc.)., so maybe the pc world in some ways eventually moves on in many areas but the embedded world can certainly make good use of c++ and mostly has not begun to do so. I think the problem we currently have is manufacturers do not seem to want to change, and a c++ user is left either using the c parts provided by the manufacturer (for peripherals) or going it alone and writing your own peripheral drivers.

 

This is basic code I made for a stm32g031 for the gpio class using the same ideas I used for pic32mm, avr0/1-

https://godbolt.org/z/JVJVXy

you can skip down to main to see what usage ends up being- in this case you can just specify which pin you want (and if you want 'low is on'), any of the properties you want set (specified in any order)-

using namespace PINS;

Gpio<PA0L> led(PULLUP, OUTPUT, SPEEDHI); //pullup makes little sense here, but just showing

led.on();

 

So, the 'HAL' layer is both the low level and the high level all in one. There is no need for a upper level interface to some lower level code. There is also no need to traverse some trail of includes to find what is going on, as all the info is in the single file (and in this case is a header only file). Now the problem is there are 30+ other chapters in the datasheet to tackle and if you want to do the same thing for all peripherals you are on your own (which I have done for a pic32mm, and am doing for the avr0/1- but it takes time).

 

 

 

 

 

Last Edited: Sun. Jan 12, 2020 - 10:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fianawarrior wrote:
Anyone here that does not know C++?
I think anyone who dabbles in C++ knows some of it. The problem I have with C++ (that I use professionally) compared to plain C is that it's just too extensive and complex to know all of it. Any reasonable programmer can carry around an almost complete knowledge of C in their head but you'd need to be Spock or Data or 3PO etc. to carry around an entire knowledge of C++ in your head. This is not helped by the fact that the language is still reborn every 3 years (C++08, C++11, C++14, C++17, C++20 etc etc) so just when you thought you'd grasped pretty much all it has to offer they go and add another 50 new things every 3 years that you have to then learn about.

 

That's not to say that it's not worth trying to learn it. It's clearly an infinitely better language than C. It makes for better designed, more robust code implementation with better structure, easier to read and to compartmentalise and control each small part of it. But don't expect to do it without regular reference to texts describing the features on offer to achieve that.

 

Also it's a bit of a shame for anyone (in this era) who leaned C first. To program in C++ requires a different approach and you are kind of tainted if you have already done things the "C way" first. C++ programmers are probably better if they just learned an object oriented language (C++, Java, even Python) first rather than taking a "C view" of the world.

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

Thanks!

...

"Not everyone can become a great artist, but a great artist can come from anywhere." - Anton Ego

...

Bloom, Benjamin (ed.) Developing Talent in Young People, Ballantine, 1985.

...

There are a relative few school districts here that have curricula including computer programming (maybe C++) in some secondary schools.

An issue is not all school districts can afford that; therefore, some young-adults-in-training are missing opportunities.

There's an e-sports stadium here, game software is more likely in C++, guess where the students' interests go.

Here, there's also embedded systems development in C++ but it's the supply and demand principle.

 

Texas school lets students use gaming skills to learn | Fort Worth Star-Telegram

 

edit :

UC Davis Center for Integrated Computing and STEM Education

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Tue. Jan 7, 2020 - 04:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay lads, I've eventually opened a C++ book I've had sitting for years.  Can't wait to come to terms with it.  But the question still remains!  Does C++ have a place in an Embedded environment?

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

Yes - and a growing one.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you live under a rock?? C++ has been alive and well in embedded for many years. Especially with embedded systems running Linux. Ever heard of Qt?

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

Kartman wrote:
Do you live under a rock?? C++ has been alive and well in embedded for many years. Especially with embedded systems running Linux. Ever heard of Qt?

Living in Ireland mate.  We have no class system... ;)

 

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

I raise a glass to your lack of class.....system!

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

Good laugh at the Englisch Sassenachs

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

 

Embedded C++ (EC++) removes templates, etc. 

 Hmmph.  Of the 8 features they excluded, three are things that even I recognize as being useful in embedded systems.

Templates aren't inherently bad, for example - I've seen some wonderful "pin" implementations that use templates.  It's just that "common" use of templates involves dynamically allocating arbitrarily-sized chunks of memory.

"Style casts" are used effectively by Arduino to handle pgmspace stuff; I'm not sure what other dangers exist there that are specific to embedded.

And why did they reject "Namespaces"?  Aren't those strictly a compile-time thing useful for isolating library definitions from user code?

 

The Wikipedia article suggests that EC++ died a long time ago.  The last website activity was apparently in 2002.

(It does offer "rationale" for their choices: http://www.caravan.net/ec2plus/r... )

 

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

westfw wrote:

The Wikipedia article suggests that EC++ died a long time ago.  The last website activity was apparently in 2002.

(It does offer "rationale" for their choices: http://www.caravan.net/ec2plus/r... )

 

2002.   Wow.  I thought it was active more recent than that.  The last C++ coding I did was a few years prior to that. 

In my experience most C++ programmers don't really understand the side effects of what they code.  For example, while some templates are OK for embedded, the fact that others may not be is a reason to eliminate them.

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

most C++ programmers don't really understand the side effects of what they code.

Yeah.  I've been doing some python programming, and it's really unsettling to have so little awareness of how expensive (or not) the high level operations are "underneath."  I'm reduced to "does it run in reasonable time (on the supercomputer we all have now."

I guess that's the point, really.  But still...

 

We once rejected "let's start using C++ on our systems" precisely because we viewed it as "too easy to do something stupid without noticing."

 

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

MattRW wrote:
most C++ programmers don't really understand the side effects of what they code. 

That can equally apply to 'C' programmers

 

westfw wrote:
Templates aren't inherently bad, for example ...   It's just that "common" use of templates involves dynamically allocating arbitrarily-sized chunks of memory

Again, 'C' programmers can make similar false assumptions.

A common one is that linked lists are "bad" for embedded, because they require dynamic allocation ...

 

 

We even see novice assembler programmers doing dumb things like large amounts of verbatim repetition - because they don't know how to use loops or subroutines.

 

My point being that these things are not problems with the languages themselves - just in the way people use them.

 

Just because someone (or many people) uses a tool badly doesn't mean it's a bad tool!

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

westfw wrote:
and it's really unsettling to have so little awareness of how expensive (or not) the high level operations are "underneath." 
It's interpreted so why do you really care anyway? Interpretation (with the possible exception of TIL languages like Forth) is always going to be hugely inefficient compared to compiled anyway.

Fianawarrior wrote:
But the question still remains!  Does C++ have a place in an Embedded environment?
There are some limits in using C++ on low resource micros (like 2K AVR8s with 128 bytes of RAM) because there are some things you can do in C++ that can "eat" memory so when used in small micros you have to be very aware of what you can and can't do (not totally dissimilar to the way you also avoid malloc() in C on small embedded) but anything from about Cortex M3 upwards you probably have enough resource to use C++ as freely as its designer intended and from there up you gain all the major advantages the language has over plain C. By the time you reach Cortex M7 and then the Cortex A processors there's an almost total certainty that stuff wll be written in C++, not just because you can but because on processors with that much resource you are probably going to be using some pretty complex software and that's when you really start to need the modularity advantages that C++ brings.

 

Personally I do all my work on "big iron" (in fact some of the most blazing powerful "embedded processors" you can buy) so have been doing things exclusively in C++ for about a decade now. (a small exception to that is an industry standard way of interfacing in the automotive industry called "Autosar" and that relatively small part is C not C++, which always makes life "interesting" at the C/C++ borders!)

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

clawson wrote:
anything from about Cortex M3 upwards you probably have enough resource to use C++

ARM's mbed uses C++ (and I think it has done from the outset?)

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

MattRW wrote:
most C++ programmers don't really understand the side effects of what they code. 

That can equally apply to 'C' programmers

 

I don't by this argument as the magnitude of misunderstanding is so much smaller in C.   In C there no run-time effect to resolve foo->bar() when foo is an instantiation of a class with multiple inheritance.

To me it's like woodworking with hand tools versus power tools.  Yes the power tools are more productive but you are going to loose a finger if you don't know what you are doing.

Last Edited: Wed. Jan 8, 2020 - 01:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MattRW wrote:
the magnitude of misunderstanding is so much smaller in C.

That's (probably) true, but the effect is still there.

 

eg, many newbies are surprised that they've nearly filled a small micro - just by using printf().

   In C there no run-time effect to resolve foo->bar()

Well, there is the (admittedly, very small) overhead  of dereferencing the pointer.

 

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Oh there are tons of beginners who might think there was no problem in:

void foo(int n) {
    char buff[100];
    if (n) {
        foo(--n);
    }
}

int main(void) {
    foo(20);
}

on an embedded micro ;-)

 

You can abuse any language with little effort!

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

clawson wrote:
You can abuse any language with little effort!

Exactly!

 

surprise

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Oh there are tons of beginners who might think there was no problem in:

void foo(int n) {
    char buff[100];
    if (n) {
        foo(--n);
    }
}

int main(void) {
    foo(20);
}

on an embedded micro ;-)

 

You can abuse any language with little effort!

 

That's not the way to fib.  Try the following.  avr-gcc will generate a tail call (notice no call from fib1 in the assembly).

(btw, on my browser, chrome/linux, the code paste button is broken now, worked last week.)

 

uint8_t fib1(uint8_t n, uint8_t p, uint8_t q) {
  if (n == 1) {
    return p;
  } else {
    return fib1(n - 1, p+q, p);
  }
}

uint8_t fib(uint8_t n) {
  return fib1(n, 1, 0);
}

 

00000080 <fib1>:
  80:    81 30           cpi    r24, 0x01    ; 1
  82:    11 f4           brne    .+4          ; 0x88 <fib1+0x8>
  84:    09 c0           rjmp    .+18         ; 0x98 <fib1+0x18>
  86:    69 2f           mov    r22, r25
  88:    96 2f           mov    r25, r22
  8a:    94 0f           add    r25, r20
  8c:    81 50           subi    r24, 0x01    ; 1
  8e:    46 2f           mov    r20, r22
  90:    81 30           cpi    r24, 0x01    ; 1
  92:    c9 f7           brne    .-14         ; 0x86 <fib1+0x6>
  94:    89 2f           mov    r24, r25
  96:    08 95           ret
  98:    96 2f           mov    r25, r22
  9a:    fc cf           rjmp    .-8          ; 0x94 <fib1+0x14>

 

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

I was simply speaking conceptually. It's pretty evident in my example that char buff[] won't actually be created and put 100 bytes on the stack 20 times either. But in a more extensive implementation, where is was actually used, that might be the case and that's the kind of danger I was talking about - i.e. that a neophyte did not realise that this had the potential to create 2,000 bytes on the stack in less than 10 lines of C.

 

A bit like beginners who just wildly use "int" everywhere may not realise that on a micro uint8_t is often a more appropriate choice - that kind of thing. (especially when you make a [250] array of int that could be uint8_t etc etc)

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

clawson wrote:
beginners who just wildly use "int" everywhere may not realise that on a micro uint8_t is often a more appropriate choice

Or people who have got into this habit on 8-bit micros, and don't realise that it can be counter-productive when they move to 32 bits ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My post was missing the smiley

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

C++ is looking good.  On page 351 after two days.  Just need to code in "Anger" to get to grips with when to use these lovely C++ stuff.

What about C#, that would hardly be used in Embedded systems?

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

Fianawarrior wrote:
What about C#, that would hardly be used in Embedded systems?

If you must:   https://netmf.github.io/

 

https://docs.ghielectronics.com/hardware/fez/intro.html

 

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

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

laugh

Try your axe or sword (Alexander and the Gordian Knot)

 

"Dare to be naïve." - Buckminster Fuller

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

awneil wrote:
But there are still people here that does not know 'C'

THat would be me.....

 

clawson wrote:
You can abuse any language with little effort!

I am proof of that as well!!

 

Fianawarrior wrote:
C++ is looking good.  On page 351 after two days. 

Can't determine if you have an OCD....or a direct tap to a keg of Guinness. Or BOTH?

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

re OCD

One's will is more likely.

Once went through one of a computer language's several (many?) textbooks that is well liked (read, exercises); some books have a student's addition.

 

re beer

Ethanol is a poison and depressant; beer is not conducive to one's education.

Though, have heard that a beer with lunch is common in Germany; likewise with a former co-worker (was a fit for that one and embedded software development)

To each, their beer!

Prosit!

https://en.wiktionary.org/wiki/prosit#German

 

P.S.

From Charles Bamforth, Ph.D "The Pope of Foam" :

https://youtu.be/ldKupG67d6E?t=132 (13s)

in

Onward California: Beer: A Beautiful Artistic Symphony - YouTube (2m25s)

 

P.P.S.

How Beer Saved the World - Top Documentary Films

(might try a VPN to watch the trailer)

 


"C 4 Everyone" Book (Imagecraft Creations) via C for Everyone (The Ganssle Group)

 

"Dare to be naïve." - Buckminster Fuller

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

jgmdesign wrote:

awneil wrote:
But there are still people here that does not know 'C'

THat would be me.....

 

clawson wrote:
You can abuse any language with little effort!

I am proof of that as well!!

 

Fianawarrior wrote:
C++ is looking good.  On page 351 after two days. 

Can't determine if you have an OCD....or a direct tap to a keg of Guinness. Or BOTH?

 

Jim

 

BOTH!

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

gchapman wrote:
have heard that a beer with lunch is common in Germany

Wine with lunch is de rigueur in France

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

How about a new C book. Not read it yet, but I probably should.

 

https://modernc.gforge.inria.fr/

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

Maybe not at the company's bar ... at a staid company ... well, if one's a forklift operator then can comprehend.

France allows employers to ban wine in workplace (year '14)

 

"Dare to be naïve." - Buckminster Fuller

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

Virtual functions are a bit of  headache!

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

You hit the circle,square,triangle=shape thing?

 

The point is that you often have things that are very similar where a lot if the code is the same and could be shared but there's some small aspect that differs and need a small bit if code that's a bit different. So you put the common stuff in the base class with just one or two functions marked virtual then derive each from that and just implement the differing code in each.

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

clawson wrote:

You hit the circle,square,triangle=shape thing?

 

The point is that you often have things that are very similar where a lot if the code is the same and could be shared but there's some small aspect that differs and need a small bit if code that's a bit different. So you put the common stuff in the base class with just one or two functions marked virtual then derive each from that and just implement the differing code in each.

 

Hi Clawson been through most of C++.  function overloading and virtual functions allow polymorphism.  Looks Great.

One killer is the destructor!  What with pointers and everything.  Then you have:

 

Copy Constructor;

Copy Assignment;

Move Constructor;

Move Assignment;

 

what else is great!  Oh, templates!

 

I love the language, Going to use it in a up-and-coming project that is a GUI.  So not until its used in anger will know how to really make the most of these new methods.

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

When I look back at coding an RTOS or IP Stack you can see that the problem domain is just dying to use Classes.