f23752164b
From the FreeRTOS documentation, pdFREERTOS_ERRNO_ENOSPC means that timeout occurred before any data could be sent or received. - In the plaintext transport-interface implementation, we would directly return `-pdFREERTOS_ERRNO_ENOSPC`. However, an error like this can occur when the TCP buffer is full, so this ought to be retriable. Libraries that consume the transport interface interpret a return value of 0 to mean that send/recv can be invoked again to get the data. As such, we should appropriately set the return value as 0 when the status is `-pdFREERTOS_ERRNO_ENOSPC`. - In the mbedTLS port, we would directly return whatever `FreeRTOS_send` or `FreeRTOS_recv` returns. However, sometimes, the return value can be an error. In such cases, we ought to map an error from FreeRTOS+TCP to an equivalent error in mbedTLS. In the case of `-pdFREERTOS_ERRNO_ENOSPC`, we map that to `MBEDTLS_ERR_SSL_TIMEOUT`. When the mbedTLS transport-interface send/recv wrapper sees that value, it appropriately returns 0, so that the library can retry the send/recv. I've verified that when the mbedTLS port returns an error, that same error is returned by `mbedtls_ssl_write` & `mbedtls_ssl_read`. - The TCP socket may have a receive block time. If bytesToRecv is greater than 1 then a frame is likely already part way through reception and blocking to wait for the desired number of bytes to be available is the most efficient thing to do. If bytesToRecv is 1 then this may be a speculative call to read to find the start of a new frame, in which case blocking is not desirable as it could block an entire protocol agent task for the duration of the read block time and therefore negatively impact performance. So if bytesToRecv is 1 then don't call recv unless it is known that bytes are already available. Co-authored-by: abhidixi11 <44424462+abhidixi11@users.noreply.github.com> Co-authored-by: RichardBarry <3073890+RichardBarry@users.noreply.github.com>
Getting started
The FreeRTOS.org website contains contains a FreeRTOS Kernel Quick Start Guide, a list of supported devices and compilers, the API reference, and many other resources.
Getting help
You can use your Github login to get support from both the FreeRTOS community and directly from the primary FreeRTOS developers on our active support forum. The FAQ provides another support resource.
Cloning this repository
This repo uses Git Submodules to bring in dependent components.
Note: If you download the ZIP file provided by the GitHub UI, you will not get the contents of the submodules. (The ZIP file is also not a valid git repository)
To clone using HTTPS:
git clone https://github.com/FreeRTOS/FreeRTOS.git --recurse-submodules
Using SSH:
git clone git@github.com:FreeRTOS/FreeRTOS.git --recurse-submodules
If you have downloaded the repo without using the --recurse-submodules argument, you need to run:
git submodule update --init --recursive
Repository structure
This repository contains the FreeRTOS Kernel, a number of supplementary libraries, and a comprehensive set of example applications. Many libraries (including the FreeRTOS kernel) are included as Git submodules from their own Git repositories.
Kernel source code and example projects
FreeRTOS/Source contains the FreeRTOS kernel source code (submoduled from https://github.com/FreeRTOS/FreeRTOS-Kernel).
FreeRTOS/Demo contains pre-configured example projects that demonstrate the FreeRTOS kernel executing on different hardware platforms and using different compilers.
Supplementary library source code and example projects
FreeRTOS-Plus/Source contains source code for additional FreeRTOS component libraries, as well as select partner provided libraries. These subdirectories contain further readme files and links to documentation.
FreeRTOS-Plus/Demo contains pre-configured example projects that demonstrate the FreeRTOS kernel used with the additional FreeRTOS component libraries.
Previous releases
Releases contains older FreeRTOS releases.