Global single instance object (similar to EEPROM from Particle)


I want to have global access to certain objects in my code and guarantee there is only ever one instance. This is mainly for access to hardware peripherals as I have gotten bored of all the boiler plate code needed for dependency injection.

I am looking for something like the EEPROM functionality provided by Particle that allows me to call EEPROM.write() etc from anywhere in my code.

Should I be using global objects, singletons or something else?


Something like a singleton is best in this case.

I usually create a separate cpp/h file for this object, and have all members be static.

A good example is the spark_wiring_rgb.cpp/h files. Take a look:

Just remember to create your object, i would usually do it in the cpp file.
ie: RGBClass RGB ; usually goes at the end of my cpp file. Now any file that I #include "spark_wiring_rgb.h" knows that the object RGB exists and can access it.

1 Like

Thanks for the link, I will definitely create an object.

I don’t think I quite understand how it should be used though…

  • Where should the constructor/deconstructor go (public/private) and how do I ensure it gets called on first use only?
  • What does the extern RGBClass RGB; line do and do I need it?
  • Does adding RGBClass RGB; at the end of the cpp file instantiate an instance and allow me to access it like RGB.control()?


These three questions answer eachother when just look at them last to first


RGBClass RGB; // at the end of the cpp file instantiates AND constructs a global object


extern RGBClass RGB; // in the header tells everybody who uses it that there already is a global object to use 

application.h includes it, hence every module including it (so all) will be informed

answered by above

1 Like

OK its starting to make sense.

When will the constructor get called? I ask because my code seems to be working but does not printf any messages from the constructor.



Here is my class, please let me know if I have done anything incorrectly, if there is a better way to do it and any potential issues I may have - mainly around the order constructors are called.



#include "ExternalEeprom.h"

    _spieep = new SPIEEP(24, 256, 131072);

    if(!_spieep->test_chip()) Serial.printf("Eeprom NOT FOUND!!\r\n");
    else Serial.printf( "Finished Eeprom initialisation\r\n");

ExternalEeprom::~ExternalEeprom() {}

void ExternalEeprom::readSettings(byte* settings, uint16_t size)
    _spieep->readn(0, settings, size);

void ExternalEeprom::writeSettings(byte* settings, uint16_t size)
    _spieep->writen(0, settings, size);

ExternalEeprom _externalEeprom;




#include "application.h"
#include "SPIEEP.h"

class ExternalEeprom
    virtual ~ExternalEeprom();

    void readSettings(byte* settings, uint16_t size);
    void writeSettings(byte* settings, uint16_t size);

    SPIEEP* _spieep;

extern ExternalEeprom _externalEeprom;


I use this from other classes like this: _externalEeprom.readSettings(_buffer, 64);

Thanks for your advice :smiley: )

Constructors of seperate modules will be executed in an “unpredictable” order.
So your constructor might be called before Serial object gets instantiated.
This is the reason why you should initialize your object but not do work in the constructor on these devices - hence most classes feature a begin() methode to be called in setup() or before first use.

OK cool, so with a begin() method controlling init order is this pattern generally accepted to be correct and safe?

Is there any way to throw a compile time error if the class is used before begin() has been called?

unfortunately not at compile time. That would be equivalent to solving the halting problem.

any other workaround or solutions? I can check that a begin flag has been set in every function but then i’m back to boiler plate code.