Allow passing beacon interval to SoftAP config

[piotrcurious]

Allow passing beacon_interval to SoftAP config.
Beacon interval affects DTIM and affects overall energy efficiency of AP (and responsiveness).
Decrease to make AP more realtime
Increase to make AP (and it's nodes) more energy and spectrum efficient.

Afffects waking up of nodes from light sleep too.

[piotrcurious]

I think whole point of preinitalizing variables by compiler is that it is code designed for embedded system, so this leaves chance for compiler to cut some slack during optimization phase f.e. by reusing constants. Leaving them uninit and adding extra code to return defaults would make sense in bigger environment, but it will just add bloat on embedded syste

…

-------- Original Message --------

On Dec 16, 2022, 14:44, david gauchard wrote: @d-a-v commented on this pull request. --------------------------------------------------------------- In [libraries/ESP8266WiFi/src/ESP8266WiFiAP.h](#8695 (comment)): > @@ -37,8 +37,8 @@ class ESP8266WiFiAPClass { public: - bool softAP(const char* ssid, const char* psk = NULL, int channel = 1, int ssid_hidden = 0, int max_connection = 4); - bool softAP(const String& ssid,const String& psk = emptyString,int channel = 1,int ssid_hidden = 0,int max_connection = 4); + bool softAP(const char* ssid, const char* psk = NULL, int channel = 1, int ssid_hidden = 0, int max_connection = 4, int beacon_interval = 100); + bool softAP(const String& ssid,const String& psk = emptyString,int channel = 1,int ssid_hidden = 0,int max_connection = 4,int beacon_interval = 100); I don't know if I was clear and sorry for that. I meant it is preferable to do this, in case of subclassing / overloading. bool softAP ( const char * ssid, const char * psk = NULL , int channel = 1 , int ssid_hidden = 0 , int max_connection = 4 ) { return softAP (ssid, psk, channel, hidden, max_connection, 100 ); } + bool softAP ( const char * ssid, const char * psk, int channel, int ssid_hidden, int max_connection, int beacon_interval); — Reply to this email directly, [view it on GitHub](#8695 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ASY4EOBUMNUDK6L6GACZIILWNRW2BANCNFSM6AAAAAARJHJK2E). You are receiving this because you authored the thread.Message ID: ***@***.***>

[piotrcurious]

For binary stability one can use immediate binary wrapper functions, solving incompatibility, bit like LDPRELOAD mechanism in linux. For embedded system with opensource environment expecting binary compatibility is quite high aim, certainly not achieveable for such a volatile target like 8266 which will most likely disappear once trade sanctions will take traction. Even worse, i guess to crumble sanctioned entities, entire architecture will be convoluted leaving recompile as only option, so caring about binary compatibility in this very moment of history would be unethical really.

…

-------- Original Message --------

On Dec 17, 2022, 11:09, Max Prokhorov wrote: @mcspr commented on this pull request. --------------------------------------------------------------- In [libraries/ESP8266WiFi/src/ESP8266WiFiAP.h](#8695 (comment)): > @@ -37,8 +37,8 @@ class ESP8266WiFiAPClass { public: - bool softAP(const char* ssid, const char* psk = NULL, int channel = 1, int ssid_hidden = 0, int max_connection = 4); - bool softAP(const String& ssid,const String& psk = emptyString,int channel = 1,int ssid_hidden = 0,int max_connection = 4); + bool softAP(const char* ssid, const char* psk = NULL, int channel = 1, int ssid_hidden = 0, int max_connection = 4, int beacon_interval = 100); + bool softAP(const String& ssid,const String& psk = emptyString,int channel = 1,int ssid_hidden = 0,int max_connection = 4,int beacon_interval = 100); I don't believe this matters in our case too too much? Ambiguous overload is resolved at build time, everything is ok on that part. If we worry about faulty default method used, arguments are expanded left-to-right so user will magically use the new method after upgrading our version. If we worry about binary stability and preserving existing function signature in the .o file... idk how does one need to build its software for it to matter :) — Reply to this email directly, [view it on GitHub](#8695 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ASY4EOFHCOLD2BG6GAULEFDWNWGMHANCNFSM6AAAAAARJHJK2E). You are receiving this because you authored the thread.Message ID: ***@***.***>