The following changes have been made:
1. All FreeRTOS kernel source files are now placed in the
freertos/FreeRTOS-Kernel folder to match with the upstream folder structure.
2. All kernel include files are now placed in freertos/FreeRTOS-Kernel/include.
3. All port files are now placed in freertos/FreeRTOS-Kernel/portable.
4. All additions/customizations are placed in freertos/esp_additions.
5. All other miscellaneous files (README, License files etc.) are moved to
freertos/FreeRTOS-Kernel folder to match with the upstream.
6. Updated esp-cryptoauthlib to latest commit to resolve FreeRTOS
include dependencies.
Signed-off-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
ringbuf: Fix bug where comparision between a signed and unsigned operand resulted in incorrect free size for no-split/allow-split buffers
Closes IDFGH-5624 and IDFGH-5649
See merge request espressif/esp-idf!15373
Doc/Make Classic BT related document links only visible for ESP32
Closes IDFGH-5008, IDFGH-6022, and AUD-3378
See merge request espressif/esp-idf!15635
esp_http_client: Fix HEAD request will affect the all next HTTP requests unless we close the HTTP request
Closes IDFGH-6098
See merge request espressif/esp-idf!15707
The issue is related to the non-sequential way of description when
such fields going together sequential.
Related to esp32h2 chip for eFuses: MAC_FACTORY and MAC_EXT.
The issue is in wrong indexes of MAC_EXT.
MAC_EXT got indexes like it is joined to MAC_FACTORY.
const esp_efuse_desc_t* ESP_EFUSE_MAC_FACTORY[] = {
&MAC_FACTORY[0],
&MAC_FACTORY[1],
&MAC_FACTORY[2],
&MAC_FACTORY[3],
&MAC_FACTORY[4],
&MAC_FACTORY[5],
NULL
};
const esp_efuse_desc_t* ESP_EFUSE_MAC_EXT[] = {
&MAC_EXT[6],
&MAC_EXT[7],
NULL
};
This commit fixed it to:
const esp_efuse_desc_t* ESP_EFUSE_MAC_EXT[] = {
&MAC_EXT[0],
&MAC_EXT[1],
NULL
};
This commit fixes a bug in no-split and allow-split ring buffers free buffer size calculation.
When the free size available in the buffers less than the size of one item header,
the function prvGetCurMaxSizeNoSplit/AllowSplit() incorrectly returned the maxItemSize instead of 0.
This is due to the comparision between a negative and a positive value
where both operands are treated as unsigned during the comparision operation,
thereby treating the negative operand as a large integer.
Also added new unit tests to test buffer-full and almost-full conditions
where this scenario is likely to be hit.
Closes https://github.com/espressif/esp-idf/issues/7344
Closes https://github.com/espressif/esp-idf/pull/7371
The release of the semaphore indicating the item was successfully sent must be the last semaphore released. The receiver may be in another task and may delete the Ringbuffer (such as with a return code across tasks design pattern) if they are through with the Ringbuffer.
The function xRingbufferSendAcquire followed by xRingbufferSendComplete had the semaphores released in the proper order and that same pattern should have been used in xRingbufferSend and xRingbufferSendFromISR. This commit fixes this order.
Issue (IDFGH-6030) #7716 describes the problem in more detail.
Closes IDFGH-6030, https://github.com/espressif/esp-idf/issues/7716
Closes IDFGH-6036, https://github.com/espressif/esp-idf/pull/7721
