Default constructor request

[edwino-stein]

The RF24 class does not have a default constructor and, in some projects, may force heap allocation when the instance must be created and initialized during runtime. Heap allocation is a bad idea on microcontrollers like Arduino.

For example, in my project, I need inicializate an instance of RF24 with dynamic data during runtime, but because Arduino compatibility, the instance must be allocated in stack.

My sugestion is for implementation of a default constructor, and a new begin method with paramters of the current constructor.

RF24::RF24():
p_variant(false), payload_size(32),
dynamic_payloads_enabled(false), addr_width(5), csDelay(5)
{
    pipe0_reading_address[0]=0;
}

bool RF24::begin(uint16_t _cepin, uint16_t _cspin)
{
    // Initizalize the ce_pin and ce_pin values
    this->ce_pin = _cepin;
    this->csn_pin = _cspin;

   // Call the old begin method
    return this->begin();
}

[2bndy5]

How would we go about preventing mis-use of this feature? Example:

#define RF24_CE 7
#define RF24_CS 8

RF24 radio();

void setup() {
  radio.begin(RF24_CE); // this is a bad scenario; complier will weep
  radio.begin(RF24_CS); // this is a bad scenario; compiler will weep
  radio.begin();        // this is a bad scenario because we used the blank c'tor above
  radio.begin(RF24_CE, RF24_CS); // this is the only proper way to use the suggested feature.

  // ...
}

Initially I think begin() should return false if either pins are 65535 (as set by the empty c'tor), but not many people that post code use the begin() method's return value in debugging (judging from the code I've seen when helping troubleshoot these issues).

[2bndy5]

begin() should return false if either pins are 65535

Found isValid(); an artifact function from maniacBug days that assumes the ce_pin and csn_pin is of uint8_t datatype. I'm adjusting this to utilize the full bit length of uint16_t (and moving the definition into the RF24.cpp like everything else is).