forked from espressif/arduino-esp32
-
Notifications
You must be signed in to change notification settings - Fork 0
Ipv6 support v2 #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Create pins_arduino.h * Update boards.txt * Update boards.txt
This update includes the following: - Implemented an additional build step that produces an adjusted bootloader image with updated headers according to selected flash mode and size values. This step is only executed for debugging or uploading via debug probes. - Implemented a basic mechanism to dynamically add an extra UF2 bootloader image if corresponding partition is selected (e.g. for Adafruit targets) - Minor code formatting
Co-authored-by: Jan Procházka <[email protected]>
…#7208) Co-authored-by: Jan Procházka <[email protected]>
Co-authored-by: Jan Procházka <[email protected]>
* Removed option to change CHANNEL * Revert "Removed option to change CHANNEL" This reverts commit b2ec27d. * Fixed the ability to change CHANNEL * WiFi scan only on selected channel
…ressif#7161) * add default SPI pins ifndef in arduino_pins.h * Revert "add default SPI pins ifndef in arduino_pins.h" This reverts commit be35b83. * Add missing default SPI pins * revert change for d32_pro
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: https://github.com/espressif/arduino-esp32/blob/860b104691a28f77896ac544c7745de1ba53642d/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: hathach/tinyusb@556b5d5 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() hathach/tinyusb@b495d6f 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 <[email protected]>
Co-authored-by: Jan Procházka <[email protected]>
Co-authored-by: Rodrigo Garcia <[email protected]>
add boards WiFiduinoV2&WiFiduino32S3
…if#7193) * Initial commit with guide on building libs wirh higher debug level * Added reference to FAQ * Reword portion of core_debug.rst * Removed extra empty line Co-authored-by: Vojtěch Bartoška <[email protected]>
…if#6930) * Changes UART ISR to only trigger on RX FIFO Full and timeout * changes initial RX timeout * Eliminates extra testing for _uart != NULL * reconfiguration with "uartSetFastReading()" * Adds new function "uartSetFastReading()" * changed default onReceive() behaviour * forces User callback in case of error * Error Code Order Set NO_ERROR as first error code, same as ESP_OK = 0
* Adds noInterrupt() and interrupt() functionality * Adds sei/cli Adds back sei()/cli() macros Co-authored-by: Jan Procházka <[email protected]>
…7259) * Add IDF libs from v4.4.2 * Implement build time elf2bin for the bootloader
Issue: Serial data sent during frequency change is corrupted. Fixes corrupt debug message by printing the message after the frequency change is completed.
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.
* Add new board (Deneyap Kart 1A) * Update pins_arduino.h * Add newly board (Deneyap Kart G) New Deneyap Family member, wearable development board
* Doc update: added note about global arduino component * Requested changne IDF -> ESP-IDF
* Added OTA Event Handlers * Overrided verifyRollbackLater Method Co-authored-by: Rodrigo Garcia <[email protected]>
... while readValue
* added test for touch peripheral * removed cfg.json * pass test for unsupported chips * fixed condition * changed released value for S2 * add new chip error
* 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 <[email protected]>
* Add ESP32S3 to libraries support list * Update libraries.rst
* add touch.rst * update touchRead comment in header file * Edited examples * typo changes + updates * about edit
…#7438) which prevent changing to other partition scheme
* Add new board (Deneyap Kart 1A) * Update pins_arduino.h * Add newly board (Deneyap Kart G) New Deneyap Family member, wearable development board * updated Deneyap boards pin_arduino.h files * Update boards.txt * Update pins_arduino.h * updated deneyap boards pins_arduino.h * updated Deneyap boards variants files * updated Deneyap boards pins_arduino.h Co-authored-by: Jan Procházka <[email protected]>
Improves WiFi reconnection
* ESP-IDF v4.4.3
* Added enableScenes API * Added enableScenes API documentation * Added enableScenes API to example Co-authored-by: Jan Procházka <[email protected]>
These instructions are based on esp32-arduino-lib-builder's build process, including https://github.com/espressif/esp32-arduino-lib-builder/blob/master/tools/update-components.sh which explains how to clone tinyusb.
…ressif#7237) * 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 <[email protected]> Co-authored-by: Jan Procházka <[email protected]>
This patch partially depends on: espressif/esp32-arduino-lib-builder#67 Without this patch we will get only Link local IPv6 (still useful for MDNS and etc). With patch we will get also global IPv6 address by SLAAC. By default IPv6 disabled, until it is properly tested. Tested on BasicHttpClient by adding: wifiMulti.IPv6(true); before: wifiMulti.addAP() call Enabling Core Debug Level: verbose If IP6 obtained, in logs will be visible: [ 8028][V][WiFiGeneric.cpp:380] _arduino_event_cb(): IF[0] Got IPv6: IP Index: 0, Zone: 2, fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx [ 8028][D][WiFiGeneric.cpp:852] _eventCallback(): Arduino Event: 8 - STA_GOT_IP6 [ 11028][V][WiFiGeneric.cpp:380] _arduino_event_cb(): IF[0] Got IPv6: IP Index: 1, Zone: 0, 2a0d:yyyy:0000:4000:yyyy:yyyy:yyyy:yyyy [ 11028][D][WiFiGeneric.cpp:852] _eventCallback(): Arduino Event: 8 - STA_GOT_IP6 This is linked to: espressif#6242 Signed-off-by: Denys Fedoryshchenko <[email protected]>
One of most useful features of IPv6 to have arduino accessible from internet, without any port forward and etc. Change is fairly trivial and backward compatible with old code, tested with WiFiTelnetToSerial and AsyncUDPServer. Signed-off-by: Denys Fedoryshchenko <[email protected]>
For RemoteIP and AF_INET6 socket i added support ip6 to ip4 mapping, so .remoteIP will return IPv4 address on dual stack socket, if available. Scenarios tested: WiFiTelnetToSerial, wifiMulti.IPv6(true), connect both from IPv4 and IPv6 WiFiTelnetToSerial, wifiMulti.IPv6(true); but set to listen on IPv4 only. WiFiTelnetToSerial, IPv6 disabled, with or without bind to specific IP4. AsyncUDPServer, without IPv6 support. Signed-off-by: Denys Fedoryshchenko <[email protected]>
To demonstrate new abilities of dual stack WiFiServer and remoteIP6 we add this example. Signed-off-by: Denys Fedoryshchenko <[email protected]>
We need to be able to connect to remote servers over IPv6 too, and thats need different approach in DNS queries and connect(). As i'm trying to keep maximum compatibility, i introduce different behaviour if IPv6 is enabled, and backward compatible (as much as possible), if IPv6 is not enabled. IN future when IPv6 functions are tested well enough, it can be simplified. This implementation tested on esp32 in following scenarios using BasicHttpClient: IPv6 true: IPv6 only website (caveat 1) - OK Website with A and AAAA is present (caveat 1) - OK IPv4 only website - OK IPv6 not enabled: IPv6 only website - wont open (expected) Website with A and AAAA is present - OK, opens over IPv4 IPv4 only website - OK caveat 1 - sometimes SLAAC is slower than DHCPv4, so we might have status WL_CONNECTED, but IPv6 global scope is not ready yet. Signed-off-by: Denys Fedoryshchenko <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch partially depends on:
espressif/esp32-arduino-lib-builder#67
Without this patch we will get only Link local IPv6 (still useful for MDNS and etc).
With patch we will get also global IPv6 address by SLAAC.
By default IPv6 disabled, until it is properly tested.
Tested on BasicHttpClient by adding:
wifiMulti.IPv6(true);
before: wifiMulti.addAP() call
and fetching ipv6.google.com which is ipv6 only address.
Enabling Core Debug Level: verbose
If IP6 obtained, in logs will be visible:
[ 8028][V][WiFiGeneric.cpp:380] _arduino_event_cb(): IF[0] Got IPv6: IP Index: 0, Zone: 2, fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx
[ 8028][D][WiFiGeneric.cpp:852] _eventCallback(): Arduino Event: 8 - STA_GOT_IP6
[ 11028][V][WiFiGeneric.cpp:380] _arduino_event_cb(): IF[0] Got IPv6: IP Index: 1, Zone: 0, 2a0d:yyyy:0000:4000:yyyy:yyyy:yyyy:yyyy
[ 11028][D][WiFiGeneric.cpp:852] _eventCallback(): Arduino Event: 8 - STA_GOT_IP6
This is linked to: espressif#6242
This patch based on prior work , feedback and contributions of @sgryphon
Signed-off-by: Denys Fedoryshchenko [email protected]