I have to do this all the time.
The general rule is: Don't write the same code twice.

Instead of creating multiple command functions, I would let one function do the job:

send_cmd( cmd, parameter_list);

 

C++ is just some way to use, to spell C language. What is expressed as C++ can be boiled down to C.
And C language is just some way to spell assembler.
The C compiler removes the hardware dependency.

You could use an external large RAM, and maintain linked lists, spawn some "objects", remove them again.

Back in the old MSDOS days, applications mostly were exclusive, occupying the whole RAM.
And there was not much of it.
Now we have gigabytes, and loads of apps all active at the same time.

So, dynamic memory allocation is used, objects are spawned in memory and these include references to executeable code, as well data pointers. If you know Visual C++ and compare it to Embedded C, you can see its far more complex, and there is a framework for Windows as well. But in the end, it could be converted to plain C.

You can do this on 8bit embedded, maintain references to executeable code, so called function pointers.
Some MCUs could execute code from RAM but many can not, so you could also emulate this.
Object orientated is just a way of spelling code, a way of looking at it.

 

C++ is just some way to use, to spell C language. What is expressed as C++ can be boiled down to C.
And C language is just some way to spell assembler.
The C compiler removes the hardware dependency.

You could use an external large RAM, and maintain linked lists, spawn some "objects", remove them again.

Back in the old MSDOS days, applications mostly were exclusive, occupying the whole RAM.
And there was not much of it.
Now we have gigabytes, and loads of apps all active at the same time.

So, dynamic memory allocation is used, objects are spawned in memory and these include references to executeable code, as well data pointers. If you know Visual C++ and compare it to Embedded C, you can see its far more complex, and there is a framework for Windows as well. But in the end, it could be converted to plain C.

You can do this on 8bit embedded, maintain references to executeable code, so called function pointers.
Some MCUs could execute code from RAM but many can not, so you could also emulate this.
Object orientated is just a way of spelling code, a way of looking at it.

No! This is exactly the mistake I said should not be done!

 

I have to do this all the time.
The general rule is: Don't write the same code twice.

Instead of creating multiple command functions, I would let one function do the job:

send_cmd( cmd, parameter_list);

what about say in my packet_send(payload, parameter_list), I need to do some manipulation to my payload, and I need do this multiple times. And I have multiple functions like these, what would you recommend?

// my basic packet send
void packet_send(payload, len, other_stuff);

// a wrapper for packet_send() to send special packet
// some manipulation need to be done to the payload
//  this func is expected to be called multiple time
void packet_send_special_cmd1(src, dst, other_parameters){
  // work out the payload from source, destination and
  // other parameters
  payload = some_secret_method_to_work_out_payload;
  packet_send(payload, len, other_stuff);
}

// similar to above
void packet_send_special_cmd2(other_parameters_2);
void packet_send_special_cmd3(other_parameters_3);
...
void packet_send_special_cmd4(other_parameters_4);

This is an example to show what I mean, I don't usually have that many special commands, usually only 2 - 3, but things can adds up.

 

I would add that to the function parameters:

send_cmd( cmd, parameter_list, action);

 

If you like C and like the idea of encapsulation, then just use unions and structures.... I use structures ( types in basic) to encapsulate similar data... Then I wrap it in a union so It's dead easy to serialize..

Lets assume you have four ADC inputs and each of the four are similar in nature.

I always have a Analouge min and max and a digital min and max These four are saved for calibration.
This is the idea:-

union SENSOR{
   Struct {
      long amax. amin;
      long dmax, dmin;
      long aspan,dspan;
      long inval, outval;
      };
    unsigned char serialize[16];
} Sensor1, Sensor2, Sensor3, Sensor4;

I only serialize to members I need to store....