Group Actions
Engagement
  • Author Author: Jan Cumps
  • Date Created: Date Created
  • Views 921 views
  • Likes 6 likes
  • Comments 11 comments
Related
Recommended

embedded C++: manage a resource with a tiny* object

Jan Cumps

*tiny like in: 0 bits of data, 0 code instructions added, 0 clock ticks

scenario: you have a resource that needs to be initialised before use, and deactivated when done. We usually do that by calling some code before the actions, and some code after we're done. 

// ... code before you want to activate stepper driver

activate_stepper_driver(true);

// code where you use the stepper
step(15, left);
step(185, right);

activate_stepper_driver(false);

// ... code after you deactivated the driver

We do the bookkeeping ourselves, and take care that we call both functions.

There's a C++ design pattern (RAII) that can handle this for us. You create an object when you need to activate the resource, and it 'll deactivate when it gets out of scope.

Example class - a real world case where my motor burns 0.6 A when the stepper driver is active (motor "hold" current):

class wakeup_drv8711 { // driver out of sleep as long as object in scope
public:    
    inline wakeup_drv8711() { gpio_put(nsleep, 1); }
    inline ~wakeup_drv8711() { gpio_put(nsleep, 0); }
};

... and its use:

    // ... code before you want to activate stepper driver

    { // enter scope. w constructor gets called
        wakeup_drv8711 w;
        // code where you use the stepper
        step(15, left);
        step(185, right);
        
    } // leave scope, w destructor gets called

    // ... code after you deactivated the driver

The driver is activated at line 4 (3 actually), and deactivated at line 8

Thoughts are welcome.

  • in reply to DAB

    yes. And if you can do that, guaranteed, by just putting an object in scope, that's efficient.

    In particular because that object does not consume any resources of the hardware.

  • I like it.

    Many people forget that peripheral equipment need to be carefully activated and put away.

    If not, you can get some very unwanted effects or even life threatening consequences.

  • in reply to Jan Cumps

    this code was used for the comparison:


    C

    inline void activate_stepper_driver() { asm("nop"); }
    inline void deactivate_stepper_driver() { asm("nop"); }

    int main() {
        asm("nop");
        activate_stepper_driver();

        // code that uses the stepper here

        deactivate_stepper_driver();
        asm("nop");
        return 0;
    }
    C++
    class wakeup_drv8711 { // driver out of sleep as long as object in scope
    public:    
        inline wakeup_drv8711() { asm("nop"); }
        inline ~wakeup_drv8711() { asm("nop"); }
    };

    int main() {
        asm("nop");
        {
            wakeup_drv8711 w;

            // code that uses the stepper here

        }
        asm("nop");
        return 0;
    }

  • Pre-empting the question: but how much overhead?

    image

    none.

    The "nop" calls are there to "do something" so that the optimiser doesn't completely remove this example code.

  • in reply to embeddedguy

    there is no dynamic memory allocation involved in this.

    (edit:

    you can see that because there is no new() involved in this code.

    also; because there is no data member, this object actually takes 0 bytes, nothing. It only exists in the C++ "conceptual realm".  you don't find anything back in the runtime.

    The only effect is that the code in the constructor is inserted where the scope is entered, and the code in the destructor is inserted where we leave the scope.

    Exactly same effect as the C code at the start the blog
    )