transport_ws can now be read multiple times in a row to read frames larger than the buffer.
Added reporting of total payload length and offset to the user in websocket_client.
Added local example test for long messages.
Closes IDF-1083
DISABLED_FOR_TARGETS macros are used
Partly revert "ci: disable unavailable tests for esp32s2beta"
This partly reverts commit 76a3a5fb48.
Partly revert "ci: disable UTs for esp32s2beta without runners"
This partly reverts commit eb158e9a22.
Partly revert "fix unit test and examples for s2beta"
This partly reverts commit 9baa7826be.
Partly revert "efuse: Add support for esp32s2beta"
This partly reverts commit db84ba868c.
newlib/assert: replace unlikely with likely to keep original assertion
newlib/assert: fix assert macro that uses likely
freertos/port: add the missing sdkconfig.h back
newlib/assert: assert macro back to a single line
esp_common/esp_compiler: renamed esp_macros file to a more specific one
esp_common/esp_compiler: removed CONTAINER_OF macro, it was a duplicate
components/freertos: placed likely macros around port and critical sections
component/freertos: placed likely macros on lists module
components/freertos: placed unlikely macros inside of assertion points, they likely wont fail
components/freertos: added likely macros on queue modules
FreeRTOS queues are one of most hot code path, because to queues itself tend to
be used a lot by the applications, besides that, queues are the basic primitive
to form both mutexes and semaphores, The focus here is to place likely
macros inside lowest level send and receive routines, since they're common
from all kobjects: semaphores, queues, mutexes and FR internals (like timer queue)
components/lwip: placed likely/unlikey on net-interfaces code
components/fatfs: added unlikely macros on disk drivers code
components/spiffs: added unlikely macros on low level fs driver
components/freertos: added likely/unlikely macros on timers and ticker
freertos/event_group: placed likely/unlikely macros on hot event group code paths
components/sdmmc: placed likely / unlikely macros on lower level path of sdmmc
components/bt: placed unlikely macros around bt HCI functions calling
components/lwip: added likely/unlikely macros on OS port code section
components/freertos: fix code style on tick handler
On Xtensa, backtrace can not recover the two most significant bits of
the address, as the window call size is encoded in these bits.
Because of this, __builtin_return_address modifies these MSBs to
match those of the callee, "fixing" the address. An unfortunate side
effect is that the zero return address, which usually terminates the
backtrace, gets converted to 0x40000000. While there is a valid
instruction at this address, its occurrence in the backtrace is
highly unlikely: this is the first instruction of WindowOverflow4
vector, and IDF apps switch VECBASE to an IRAM location very early at
startup.
Even if frame->exccause != PANIC_RSN_CACHEERR, it is possible that
the cache error interrupt status is set. For example, this may happen
due to an invalid cache access in the panic handler itself.
Check cache error interrupt status instead of frame->exccause to
decide whether to do CPU reset or digital reset.
Also remove unnecessary esp_dport_access_int_pause from
esp_cache_err_get_cpuid, since the panic handler already calls
esp_dport_access_int_abort on entry.
* Don't bother checking the chip revision if it looks like the partition
doesn't really contain an app
* Don't print the "info" level about the revision & min revision unless
we're in the bootloader (otherwise it gets printed at random times
during the OTA process)
When node is being reset, the init functions of each sig-defined
models will be invoked again, this will cause memory leak because
some model internal data will be allocated again.
Hence before trying to allocate memory for them, we add some check
to make sure no memory has been allocated previously.
And for client model, when the init functions are invoked again,
we will clear the list items.
Since in b0491307, which has introduced the optimized window spill
procedure, _xt_context_save did not work correctly when called from
_xt_syscall_exc. This was because unlike _xt_lowint1, _xt_syscall_exc
does not save PS and EPC1. The new version of _xt_context_save
modified PS (on purpose) and EPC1 (accidentally, due to window
overflow exceptions), which resulted in a crash upon 'rfi' from the
syscall.
This commit adds restoring of PS and EPC1 in _xt_context_save. It also
slightly reduces the number of instructions used to prepare PS for
window spill.
Unit test for setjmp/longjmp (which were broken by this regression)
is added.
Closes https://github.com/espressif/esp-idf/issues/4541
1. fix the bug when modifying the channel info of peer node
2. fix the crash when modifying peer node between unencrypted and encrypted
3. fix the bug for fetch peer
4. modify the esp_wifi_set_channel() function
5. fix the bug that the channel parameter doesn't work when adding peer node
Closes https://github.com/espressif/esp-idf/issues/2833
Closes https://github.com/espressif/esp-idf/issues/4311
* If esp_vfs_spiffs_register is called with an explicit partition
label, other SPIFFS functions (info, format, unregister) must be
called with the same label.
* On the other hand, if label was NULL in the call to
esp_vfs_spiffs_register and the first matching partition was used,
calls to the rest of the SPIFFS functions should be done with NULL
partition_label argument.
Fix the Doxygen documentation. Update the example accordingly, in case
a user modifies "partition_label" value in esp_vfs_spiffs_conf_t conf
initializer.
Closes https://github.com/espressif/esp-idf/issues/4450
