Currently, if a second connection occur in Bluetooth, this second connection is automatically disconnected (line 284).
This disconnection trigger the ESP_SPP_CLOSE_EVT, which clear the bit SPP_CONNECTED.
But the first connection remain active, and this flag shouldn't be cleared.
This fix the issue, by clearing the flag only if the last connection is closed
Co-authored-by: Rodrigo Garcia <rodrigo.garcia@espressif.com>
* feat: add ESP-C3-M1-I-Kit board to variants
* docs: rename file to slug format
* Fixes GPIO definitions
* Adds ESP32 C3 M1 I Kit to the board list
Fixes board.txt file to add the new ESP32_C3_M1_I_KIT variant
* fixes extra board separator
* Keeps only 4MB flash option
* Fix it to Flash 80Mhz QIO only
* Undo a change by mistake
Co-authored-by: Rodrigo Garcia <rodrigo.garcia@espressif.com>
* Workaround for when USB CDC is unplugged
* Considers default TX timeout
Sets back default TX timeout whenever USB is plugged, otherwise it is kept as zero.
* fixed left over code
* Correct upload tool name for "ESP32 FM DevKit"
The upload tool name was changed from `esptool` to `esptool_py`. The author of the "ESP32 FM DevKit" board definition used the old tool name and evidently never tested it, since the upload fails:
java.lang.NullPointerException
at cc.arduino.packages.uploaders.SerialUploader.uploadUsingProgrammer(SerialUploader.java:295)
at cc.arduino.packages.uploaders.SerialUploader.uploadUsingPreferences(SerialUploader.java:90)
at cc.arduino.UploaderUtils.upload(UploaderUtils.java:77)
at processing.app.SketchController.upload(SketchController.java:732)
at processing.app.SketchController.exportApplet(SketchController.java:703)
at processing.app.Editor$UploadHandler.run(Editor.java:2055)
at java.lang.Thread.run(Thread.java:748)
* Add protocol-explicit `upload.tool` properties required for pluggable discovery compatibility
A new flexible and powerful "pluggable discovery" system was added to the Arduino boards platform framework. This system
makes it easy for Arduino boards platform authors to use any arbitrary communication channel between the board and
development tools.
Boards platform configurations that use the old property syntax are automatically translated to the new syntax by
Arduino CLI:
https://arduino.github.io/arduino-cli/latest/platform-specification/#sketch-upload-configuration
> For backward compatibility with IDE 1.8.15 and older the previous syntax is still supported
This translation is only done in platforms that use the old syntax exclusively. If `pluggable_discovery` properties are
defined for the platform then the new pluggable discovery-style `upload.tool.<protocol_name>` properties must be defined
for each board as well.
This platform was converted to use the new pluggable discovery platform properties syntax, so those properties are
required. Although such properties were added to board definitions at the time the syntax was changed, some board
definitions were missed at that time, or added later without the required properties.
Those missing properties caused uploads to fail for users of the recent versions of Arduino IDE and Arduino CLI with an
error of the form:
Error during Upload: Property 'upload.tool.<protocol_name>' is undefined
(where `<protocol_name>` is the protocol of the selected port, if any)
It is also important to provide compatibility with versions of Arduino development tools from before the introduction of
the modern pluggable discovery system. For this reason, the old style `<board ID>.upload.tool` properties are retained.
Old versions of the development tools will treat the `<board ID>.upload.tool.<protocol_name>` properties as an unused
arbitrary user defined property with no special significance and the new versions of the development tools will do the
same for the `upload.tool` properties.
Adding generic Code of Conduct created by GitHub to this repository.
It's well written and covers all different scenarios.
In other commit, I will update the Readme with short description and link to this file.
This PR brings updates according to the latest changes in the Arduino core:
- Bootloader binaries are now generated from elf files
- Updated CI scripts
- Updated esptoolpy to v4.2.1
- Minor clean-up by removing obsolete code
Resolves#7572
This commit addes an example showing how to receive messages using the TWAI
driver interface and a CAN transceiver. Specifically, the example demonstrates:
- How to configure and install the TWAI drvier
- How to poll for TWAI events (i.e., alerts) using twai_read_alerts()
- How to handle the various events (such as TWAI_ALERT_RX_DATA)
Closes https://github.com/espressif/arduino-esp32/pull/7430
Co-authored-by: Stephan Martin <designer2k2@gmail.com>
* Add I2C and SPI pin definitions to wt32-eth01 pins
Added missing pins based on testing using a RTC (I2C) and SD card reader (SPI).
* Remove define macros
Co-authored-by: Rodrigo Garcia <rodrigo.garcia@espressif.com>
Co-authored-by: Jan Procházka <90197375+P-R-O-C-H-Y@users.noreply.github.com>
* Added enableScenes API
* Added enableScenes API documentation
* Added enableScenes API to example
Co-authored-by: Jan Procházka <90197375+P-R-O-C-H-Y@users.noreply.github.com>
* Add the Partition Scheme Menu to HELTEC LoRa32 V1
This is missing from many boards, i may add that to all of them
* reordered heltec_wifi_lora_32 partition options
Co-authored-by: Jan Procházka <90197375+P-R-O-C-H-Y@users.noreply.github.com>
