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.
* fix typo in WiFiMulti
* clean up trailing spaces
* clean up script file used in cleaning
Co-authored-by: Me No Dev <me-no-dev@users.noreply.github.com>
* improve & fix BLEScan when too many BLE devices
- when wantDuplicates, no need to check duplicate and no more insert into vector
- delete advertisedDevice when not insert into vector, fix memory leak
- add showParse when you just want raw advertised data
Closes#4111.
gcc: I was not able to find an arm64 build on espressif's website so I choosed to put the armhf version, even if this should works this is only ok as temporary, arm64 runs better on arm64 than armhf :)
esptool: being interpreted python its ok
mkspiff: need igrr/mkspiffs#74 to be merged and artifacts added in /package/package_esp32_index.template.json.
Remove device from Peer list if connection fails.
Only call onConnect callback if connection was successful.
Only call onDisconnect callback if the connection was previously connected (ESP_GATTC_DISCONNECT_EVT is fired on a unsuccessful connection attempt also).
Resolves a number of issues with phantom events and callbacks being fired.
::addPeerDevice and ::removePeerDevice are called with m_appId, so should ::updatePeerDevice as all use the same parameter for the underlying map's key.
* Fix for issue #4158: Crash with stack trace originating in Bluedroid
Improved configuration of scan response data in 'BLEAdvertising' avoids the crash:
- Added member variable 'm_scanRespData' to configure scan response differently from advertising data
- Initialization of 'm_scanRespData' in BLEAdvertising constructor
- Use of 'm_scanRespData' within BLEAdvertising::start() to configure the scan response
- 'Flags' and 'Appearance' are cleared in the scan response data
- With this fix, device names of up to 29 characters can be used without causing a crash.
Fixes: #3460
This code has been run in production for 1 month and it looks stable, no data dropped and it definitely fixes the issue described. I think that this can be merged to avoid using custom package referencing in PlatformIO that has been used in quite a few projects for now.
Co-authored-by: Ivan Golubic <ivan@mvt-solutions.com>
The UpdateClass in the Updater component has the ability to update data to
a SPIFFS partition. It selects the first available partition using the
ESP-IDF esp_partition_find_first() function.
That behaviour is problematic if one has multiple SPIFFS partitions.
This change allows a user to pass the label argument (defaults to NULL)
to UpdateClass::begin() so a specific SPIFFS partition can be updated.
Additionally, ArduinoOTA can set this partition label using the
new method ArduinoOTAClass::setPartitionLabel which is optional.
This change does not break compatibility.
* Add partition label argument to SPIFFSSPIFFS currently assumes there is only ever one partition.This change allows a user to pass the label argument (defaults to NULL)to SPIFFS::begin() so a specific SPIFFS partition can be referenced.This change does not break compatibility.
* BLERemoteChar: fix descriptor 2902 write for characteristic notifications
When registering a notification on a characteristic, the 2902 descriptor
(CCCD) value is set to 1 (or 2 for indication).
According to the BLUETOOTH CORE SPECIFICATION Version 5.2, Revision Date
2019-12-31, section 4.12.3 "Write Characteristic Descriptors" (page 1588),
the characteristic descriptor write must expect a response.
Currently, the descriptor write is performed without expecting a reponse,
which prevents the notification to be functional with some BLE stacks.
This commit modify the write to expect the response.
Signed-off-by: Jimmy Durand Wesolowski <jimmy.durand.wesolowski@commsolid.com>
* BLERemoteChar: forward GATT client event to characteristic descriptors
This commits prevents a permanent wait when calling BLERemoteDescriptor
readValue function, on the m_semaphoreReadDescrEvt semaphore.
ESP32 BLE stack calls to remote characteristic
- notification,
- value read
- value write
and remote characteristic descriptor
- value read
are asynchronous.
When such a call is performed by this library, a semaphore is taken prior
to the BLE stack read or write operation, and waited on after it.
Releasing the semaphore is done by the characteristic event handling
function (gattClientEventHandler), when the appropriate event is received.
However, the characteristic descriptor events are discarded, and the
value read semaphore is never released.
This commits forwards the GATT client events from the remote
characteristic down to their remote characteristic descriptor, and
implements their event handling.
Adding a semaphore for the remote characteristic descriptor value write
will be done in a separate commit.
Signed-off-by: Jimmy Durand Wesolowski <jimmy.durand.wesolowski@commsolid.com>
* BLERemoteDescriptor: add semaphore to characteristic descriptor write
This adds a semaphore to characteristic descriptor value write, to mimic
the value read function, and to ensure completion of the operation before
we carry on.
Signed-off-by: Jimmy Durand Wesolowski <jimmy.durand.wesolowski@commsolid.com>
Co-authored-by: Jimmy Durand Wesolowski <jimmy.durand.wesolowski@commsolid.com>
* Corrections of Find, FindUntil and FindMulti
Find has some bug that is not working with Ethernet.find() so, I copied code from Stream.h and Stream.cpp in AVR-CORE library and now it's working perfectly.
I don't know where was the error, but an Ethernet.find compiled to MEGA2560 was working but not working when compiled to esp32, after corrections of code (copy of AVR-Core libraries) it's working perfect.
So probably has some error on original ESP32-Core library.
Below is part of code that was working with MEGA2560 and not with ESP32 libraries.
client.find never return TRUE with ESP32 original library and with AVR it's works.
boolean esp32_fw_update(EthernetClient &client, DecodedHeader &header, const String &field_filename, const String &field_crc) {
char bound[header.boundary.length()+3];
char term[]="\r\n";
strcpy(bound,header.boundary.c_str());
strcat(bound,term);
while (client.find(bound)) {
String line=client.readStringUntil('\r');
* Update Stream.h
* Update Stream.cpp
Co-authored-by: Me No Dev <me-no-dev@users.noreply.github.com>
* Add an aditional (void *) arg to the RMT callback - to allow more flexible handling of the callback (e.g. by passing a private struct or a class pointer). Same pattern as used by the Ticker() and many others. Example updated & new example with a trapoline added.
* Fix example for new API
* Fix lint warnings
* Add a second missed example.
* Correct timeout & improve socket error handling.
