Compiler complains on unused parameter pCharacteristicMap:
framework-arduinoespressif32\libraries\BLE\src\BLERemoteService.cpp: In member function 'void BLERemoteService::getCharacteristics(std::map<short unsigned int, BLERemoteCharacteristic*>*)':
\framework-arduinoespressif32\libraries\BLE\src\BLERemoteService.cpp:246:89: warning: parameter 'pCharacteristicMap' set but not used [-Wunused-but-set-parameter]
void BLERemoteService::getCharacteristics(std::map<uint16_t, BLERemoteCharacteristic*>* pCharacteristicMap) {
Added guarded define to set the stacksize on the main looptask.
Advantage of this is that build_flags can be used to provide a different value for the stack size should it be neccessary
default behaviour is unaffected
The goal is to allow custom configuration for `variants_dir` to define our own board variant directly in the project.
With this functionnality, we are now allowed to define in our projects a custom board **AND** a custom variant.
https://docs.platformio.org/en/latest/platforms/creating_board.html#custom-embedded-boards
Here is an example of how to define a custom board with custom variant:
```
my_project
├── boards
│ └── custom_esp32dev.json
└── variants
└── custom-esp32dev
└── pins_arduino.h
```
custom_esp32dev.json
```json
{
"build": {
"arduino":{
"ldscript": "esp32_out.ld"
},
"core": "esp32",
"extra_flags": "-DARDUINO_ESP32_DEV",
"f_cpu": "240000000L",
"f_flash": "40000000L",
"flash_mode": "dio",
"mcu": "esp32",
"variants_dir": "variants",
"variant": "custom-esp32dev"
},
"connectivity": [
"wifi",
"bluetooth",
"ethernet",
"can"
],
"debug": {
"openocd_board": "esp-wroom-32.cfg"
},
"frameworks": [
"arduino",
"espidf"
],
"name": "My Custom Espressif ESP32 Dev Module",
"upload": {
"flash_size": "4MB",
"maximum_ram_size": 327680,
"maximum_size": 4194304,
"require_upload_port": true,
"speed": 460800
},
"url": "https://en.wikipedia.org/wiki/ESP32",
"vendor": "Espressif"
}
```
See #3960 for more details of the problem and the solution. I only implemented what was proposed in this ticket, as it solves my problem, which was the same as in this ticket. Credits for the code going to @etrinh ;-)
This also is a more consistence behaviour compared to esp8266, where it also is possible to restart the wifiserver immediately on the same port.
