* Fixed issue where esp32 won't reconnect to WiFi AP if the AP was restarted
* Added the autoReconnect condition and removed the reconnect reason
* Chenges on the WiFi reconnection and added new example
* Added new line at the end
* Changes reverted with some minor changes. New example remained
* Changes reverted and sync
Co-authored-by: pedro.minatel <pedro.minatel@espressif.com>
* ESP Insights: Added library support
* ESP Insights: Added Examples
* ESP Insights: Added custom partitions file
* ESP Insights: Added API documentation.
* Added recipe and script to create Insights package
* Updated ESP Insights examples.
* Changed Insights Firmware package output directory
* Changed license to include SPDX license
* Fix Insights package for Windows
* Updated .exe of insights script
* Added coredump partition to all schemes
* Updated header files of Insights diagnostics
* hotfix: Added elf-sha256-offset flag in elf2bin
builder
* Update API to be more Arduino-like and partitions offsets
Co-authored-by: Me No Dev <me-no-dev@users.noreply.github.com>
* adds extended HardwareSerial examples
* Adds new example with Serial RxTimeout
* adds and improves Serial onReceive expamples
* adjust includes CMake - UART example
* adjust includes CMake - UART example
* fixes CMake and CI
* adds ESP/Serial to CMakeList
* adds ESP/Serial to CMakeList
* fixes demo include
* fixes BREAK demo
* fixes onReceive demo
* Changes FIFO Full criteria
Changed the "1-by-1" Serial only when baud rate is 57600 or lower.
* example code replacement
* replaces functions in hal
* Update `WiFiScan` example to show more useful data
* Add channel to output.
* Add type of encryption to output.
* Format output as table.
* Update outdated example description.
* Add `scanDelete()` as hint to free memory.
* added 32 chars SSID + readme edit
Co-authored-by: Jan Procházka <90197375+P-R-O-C-H-Y@users.noreply.github.com>
* replaced original iBeacon example with a known-good one
* addressed VojtechBartoska's comment
* incorporated P-R-O-C-H-Y's change
Co-authored-by: Jan Procházka <90197375+P-R-O-C-H-Y@users.noreply.github.com>
* refactor(toString method): Add RSSI / serviceData
These are key characteristics of the BLE advertising packet. Really useful, adding to this method allows data to be easily obtained and passed over TCP/IP for processing.
* fix: remove line 565 bug
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>
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>
* 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>
Fixed#7406 . The "reason2str" macro in WiFiGeneric.cpp tries to read memory from index "-1" in "system_event_reasons" array when handling STA_DISCONNECTED event with reason 0. Dealing with reason 0 as a reason 1 (WIFI_REASON_UNSPECIFIED) will solve the problem (the reason for this event to arrive with reason 0 is unknown). #7406
The original code assumes 100Hz FreeRTOS tick rate and just supplies vTaskDelay with the assumed number of ticks required for the wanted delay. This patch simply fixes it to use portTICK_PERIOD_MS, thereby working correctly regardless of what tick rate FreeRTOS has been configured to run at.
The HID semaphore allows USBHID::SendReport() to wait for the completion of
report sending.
With a zero timeout xSemaphoreTake() after calling tud_hid_n_report(),
occasionally, the following would happening:
1. USBHID::SendReport() would send a report by calling tud_hid_n_report().
2. The send would complete and (presumably on another thread)
tud_hid_report_complete_cb() would be called and it would xSemaphoreGive()
the semaphore.
3. In USBHID::SendReport(), the zero timeout xSemaphoreTake(sem, 0) would
succeed, taking the semaphore.
4. On the next line, xSemaphoreTake(sem, timeout_ms ...) would timeout
because the semaphore was already taken by the previous line of code.
The result would be waiting timeout_ms for no reason.
The purpose of the zero timeout xSemaphoreTake() is to clear the semaphore in
case a previous SendReport() timed out waiting for the semaphore. In that case,
tud_hid_report_complete_cb() may be called after the timeout, giving the
semaphore. Then the next SendReport() would start with the semaphore given,
which isn't desired if we want to call xSemaphoreTake(sem, timeout_ms ...) on
it.
There have also been other cases where tud_hid_report_complete_cb() is called
an extra time, causing the same situation.
The fix is to move the zero timeout xSemaphoreTake() before the call to
tud_hid_n_report(). This eliminates the race between the zero timeout
xSemaphoreTake() and tud_hid_report_complete_cb() in the common case when no
timeout occurs.
There is still a possible race condition between the zero timeout
xSemaphoreTake() and tud_hid_report_complete_cb() in the case of a timeout,
but that should be rarer.
Arduino-esp32 2.0.4 was released with a version of TinyUSB hid_device.h
that uses uint16_t for the last argument:
https://github.com/espressif/arduino-esp32/blob/2.0.4/tools/sdk/esp32s2/include/arduino_tinyusb/tinyusb/src/class/hid/hid_device.h
TU_ATTR_WEAK void tud_hid_report_complete_cb(uint8_t instance, uint8_t const* report, uint16_t len);
But USBHID implements this callback with uint8_t:
https://github.com/espressif/arduino-esp32/blob/2.0.4/libraries/USB/src/USBHID.cpp
void tud_hid_report_complete_cb(uint8_t instance, uint8_t const* report, uint8_t len){
if (tinyusb_hid_device_input_sem) {
xSemaphoreGive(tinyusb_hid_device_input_sem);
}
}
The result is that when USBHIDKeyboard sends a report to the host, it
times out, waiting 100 ms for the callback to be called. It does this
once for pressing the key and once for releasing the key, so
100 ms * 2 = 200 ms.
The latest version of hid_device.h reverts the last argument to uint8_t:
860b104691/tools/sdk/esp32s2/include/arduino_tinyusb/tinyusb/src/class/hid/hid_device.h
TU_ATTR_WEAK void tud_hid_report_complete_cb(uint8_t instance, uint8_t const* report, /*uint16_t*/ uint8_t len );
But these commits suggest that the last argument will eventually be
changed to uint16_t:
556b5d5044
change report len in hid API from uint8_t to uint16_t
since HS interrupt endpoint can be up to 1024, 8-bit is not enough.
affected APIs are:
- tud_hid_n_report() / tud_hid_report()
- tud_hid_report_complete_cb()
b495d6f8ec
temporarily revert len back to uint8_t in tud_hid_report_complete_cb() for up coming release
To prevent this from becoming broken again, in preparation for the change
to uint16_t, make USBHID resilient to any type for the last argument for
tud_hid_report_complete_cb() by using some C++ template metaprogramming,
adapted from https://stackoverflow.com/a/22632571.
Co-authored-by: Rodrigo Garcia <rodrigo.garcia@espressif.com>
* Removed option to change CHANNEL
* Revert "Removed option to change CHANNEL"
This reverts commit b2ec27de1d2d4703a15f6397550a46896413828a.
* Fixed the ability to change CHANNEL
* WiFi scan only on selected channel
