Merge branch 'main' into posix-dont-break-external-threads

This commit is contained in:
John Boiles 2025-01-21 08:32:02 -08:00 committed by GitHub
commit 05d9a93cdf
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
4 changed files with 67 additions and 62 deletions

View file

@ -150,16 +150,25 @@ jobs:
with:
path: ./FreeRTOS/Source
- name: Install MSP430 Toolchain
- env:
stepName: Install MSP430 Toolchain
shell: bash
run: |
sudo apt-get -y update
sudo apt-get -y install gcc-msp430 build-essential
# ${{ env.stepName }}
echo -e "::group::${{ env.bashInfo }} ${{ env.stepName }} ${{ env.bashEnd }}"
curl -L -O https://dr-download.ti.com/software-development/ide-configuration-compiler-or-debugger/MD-LlCjWuAbzH/9.3.1.2/msp430-gcc-full-linux-x64-installer-9.3.1.2.7z
sudo apt update -y
sudo apt install -y p7zip-full
7z x ./msp430-gcc-full-linux-x64-installer-9.3.1.2.7z
chmod +x ./msp430-gcc-full-linux-x64-installer-9.3.1.2.run
sudo ./msp430-gcc-full-linux-x64-installer-9.3.1.2.run --prefix /usr/bin/msp430-gcc --mode unattended
echo "::endgroup::"
echo -e "${{ env.bashPass }} ${{ env.stepName }} ${{ env.bashEnd }}"
- name: Build msp430_GCC Demo
shell: bash
working-directory: FreeRTOS/Demo/msp430_GCC
run: make -j
run: make -j CC=/usr/bin/msp430-gcc/bin/msp430-elf-gcc OPT="-Os -I/usr/bin/msp430-gcc/include -L/usr/bin/msp430-gcc/include"
MicroBlaze-GCC:
name: GCC MicroBlaze Toolchain

View file

@ -43,12 +43,12 @@
* writer and reader to be different tasks or interrupts, but, unlike other
* FreeRTOS objects, it is not safe to have multiple different writers or
* multiple different readers. If there are to be multiple different writers
* then the application writer must place each call to a writing API function
* (such as xMessageBufferSend()) inside a critical section and set the send
* block time to 0. Likewise, if there are to be multiple different readers
* then the application writer must place each call to a reading API function
* (such as xMessageBufferRead()) inside a critical section and set the receive
* timeout to 0.
* then the application writer must serialize calls to writing API functions
* (such as xStreamBufferSend()). Likewise, if there are to be multiple
* different readers then the application writer must serialize calls to reading
* API functions (such as xStreamBufferReceive()). One way to achieve such
* serialization in single core or SMP kernel is to place each API call inside a
* critical section and use a block time of 0.
*
* Message buffers hold variable length messages. To enable that, when a
* message is written to the message buffer an additional sizeof( size_t ) bytes
@ -306,12 +306,12 @@ typedef StreamBufferHandle_t MessageBufferHandle_t;
* writer and reader to be different tasks or interrupts, but, unlike other
* FreeRTOS objects, it is not safe to have multiple different writers or
* multiple different readers. If there are to be multiple different writers
* then the application writer must place each call to a writing API function
* (such as xMessageBufferSend()) inside a critical section and set the send
* block time to 0. Likewise, if there are to be multiple different readers
* then the application writer must place each call to a reading API function
* (such as xMessageBufferRead()) inside a critical section and set the receive
* block time to 0.
* then the application writer must serialize calls to writing API functions
* (such as xStreamBufferSend()). Likewise, if there are to be multiple
* different readers then the application writer must serialize calls to reading
* API functions (such as xStreamBufferReceive()). One way to achieve such
* serialization in single core or SMP kernel is to place each API call inside a
* critical section and use a block time of 0.
*
* Use xMessageBufferSend() to write to a message buffer from a task. Use
* xMessageBufferSendFromISR() to write to a message buffer from an interrupt
@ -409,12 +409,12 @@ typedef StreamBufferHandle_t MessageBufferHandle_t;
* writer and reader to be different tasks or interrupts, but, unlike other
* FreeRTOS objects, it is not safe to have multiple different writers or
* multiple different readers. If there are to be multiple different writers
* then the application writer must place each call to a writing API function
* (such as xMessageBufferSend()) inside a critical section and set the send
* block time to 0. Likewise, if there are to be multiple different readers
* then the application writer must place each call to a reading API function
* (such as xMessageBufferRead()) inside a critical section and set the receive
* block time to 0.
* then the application writer must serialize calls to writing API functions
* (such as xStreamBufferSend()). Likewise, if there are to be multiple
* different readers then the application writer must serialize calls to reading
* API functions (such as xStreamBufferReceive()). One way to achieve such
* serialization in single core or SMP kernel is to place each API call inside a
* critical section and use a block time of 0.
*
* Use xMessageBufferSend() to write to a message buffer from a task. Use
* xMessageBufferSendFromISR() to write to a message buffer from an interrupt
@ -516,12 +516,12 @@ typedef StreamBufferHandle_t MessageBufferHandle_t;
* writer and reader to be different tasks or interrupts, but, unlike other
* FreeRTOS objects, it is not safe to have multiple different writers or
* multiple different readers. If there are to be multiple different writers
* then the application writer must place each call to a writing API function
* (such as xMessageBufferSend()) inside a critical section and set the send
* block time to 0. Likewise, if there are to be multiple different readers
* then the application writer must place each call to a reading API function
* (such as xMessageBufferRead()) inside a critical section and set the receive
* block time to 0.
* then the application writer must serialize calls to writing API functions
* (such as xStreamBufferSend()). Likewise, if there are to be multiple
* different readers then the application writer must serialize calls to reading
* API functions (such as xStreamBufferReceive()). One way to achieve such
* serialization in single core or SMP kernel is to place each API call inside a
* critical section and use a block time of 0.
*
* Use xMessageBufferReceive() to read from a message buffer from a task. Use
* xMessageBufferReceiveFromISR() to read from a message buffer from an
@ -610,12 +610,12 @@ typedef StreamBufferHandle_t MessageBufferHandle_t;
* writer and reader to be different tasks or interrupts, but, unlike other
* FreeRTOS objects, it is not safe to have multiple different writers or
* multiple different readers. If there are to be multiple different writers
* then the application writer must place each call to a writing API function
* (such as xMessageBufferSend()) inside a critical section and set the send
* block time to 0. Likewise, if there are to be multiple different readers
* then the application writer must place each call to a reading API function
* (such as xMessageBufferRead()) inside a critical section and set the receive
* block time to 0.
* then the application writer must serialize calls to writing API functions
* (such as xStreamBufferSend()). Likewise, if there are to be multiple
* different readers then the application writer must serialize calls to reading
* API functions (such as xStreamBufferReceive()). One way to achieve such
* serialization in single core or SMP kernel is to place each API call inside a
* critical section and use a block time of 0.
*
* Use xMessageBufferReceive() to read from a message buffer from a task. Use
* xMessageBufferReceiveFromISR() to read from a message buffer from an

View file

@ -40,12 +40,12 @@
* writer and reader to be different tasks or interrupts, but, unlike other
* FreeRTOS objects, it is not safe to have multiple different writers or
* multiple different readers. If there are to be multiple different writers
* then the application writer must place each call to a writing API function
* (such as xStreamBufferSend()) inside a critical section and set the send
* block time to 0. Likewise, if there are to be multiple different readers
* then the application writer must place each call to a reading API function
* (such as xStreamBufferReceive()) inside a critical section section and set the
* receive block time to 0.
* then the application writer must serialize calls to writing API functions
* (such as xStreamBufferSend()). Likewise, if there are to be multiple
* different readers then the application writer must serialize calls to reading
* API functions (such as xStreamBufferReceive()). One way to achieve such
* serialization in single core or SMP kernel is to place each API call inside a
* critical section and use a block time of 0.
*
*/
@ -514,12 +514,12 @@ typedef void (* StreamBufferCallbackFunction_t)( StreamBufferHandle_t xStreamBuf
* writer and reader to be different tasks or interrupts, but, unlike other
* FreeRTOS objects, it is not safe to have multiple different writers or
* multiple different readers. If there are to be multiple different writers
* then the application writer must place each call to a writing API function
* (such as xStreamBufferSend()) inside a critical section and set the send
* block time to 0. Likewise, if there are to be multiple different readers
* then the application writer must place each call to a reading API function
* (such as xStreamBufferReceive()) inside a critical section and set the receive
* block time to 0.
* then the application writer must serialize calls to writing API functions
* (such as xStreamBufferSend()). Likewise, if there are to be multiple
* different readers then the application writer must serialize calls to reading
* API functions (such as xStreamBufferReceive()). One way to achieve such
* serialization in single core or SMP kernel is to place each API call inside a
* critical section and use a block time of 0.
*
* Use xStreamBufferSend() to write to a stream buffer from a task. Use
* xStreamBufferSendFromISR() to write to a stream buffer from an interrupt
@ -615,12 +615,12 @@ size_t xStreamBufferSend( StreamBufferHandle_t xStreamBuffer,
* writer and reader to be different tasks or interrupts, but, unlike other
* FreeRTOS objects, it is not safe to have multiple different writers or
* multiple different readers. If there are to be multiple different writers
* then the application writer must place each call to a writing API function
* (such as xStreamBufferSend()) inside a critical section and set the send
* block time to 0. Likewise, if there are to be multiple different readers
* then the application writer must place each call to a reading API function
* (such as xStreamBufferReceive()) inside a critical section and set the receive
* block time to 0.
* then the application writer must serialize calls to writing API functions
* (such as xStreamBufferSend()). Likewise, if there are to be multiple
* different readers then the application writer must serialize calls to reading
* API functions (such as xStreamBufferReceive()). One way to achieve such
* serialization in single core or SMP kernel is to place each API call inside a
* critical section and use a block time of 0.
*
* Use xStreamBufferSend() to write to a stream buffer from a task. Use
* xStreamBufferSendFromISR() to write to a stream buffer from an interrupt
@ -718,12 +718,12 @@ size_t xStreamBufferSendFromISR( StreamBufferHandle_t xStreamBuffer,
* writer and reader to be different tasks or interrupts, but, unlike other
* FreeRTOS objects, it is not safe to have multiple different writers or
* multiple different readers. If there are to be multiple different writers
* then the application writer must place each call to a writing API function
* (such as xStreamBufferSend()) inside a critical section and set the send
* block time to 0. Likewise, if there are to be multiple different readers
* then the application writer must place each call to a reading API function
* (such as xStreamBufferReceive()) inside a critical section and set the receive
* block time to 0.
* then the application writer must serialize calls to writing API functions
* (such as xStreamBufferSend()). Likewise, if there are to be multiple
* different readers then the application writer must serialize calls to reading
* API functions (such as xStreamBufferReceive()). One way to achieve such
* serialization in single core or SMP kernel is to place each API call inside a
* critical section and use a block time of 0.
*
* Use xStreamBufferReceive() to read from a stream buffer from a task. Use
* xStreamBufferReceiveFromISR() to read from a stream buffer from an

View file

@ -65,10 +65,6 @@
#include <time.h>
#include <unistd.h>
#ifdef __APPLE__
#include <mach/mach_vm.h>
#endif
/* Scheduler includes. */
#include "FreeRTOS.h"
#include "task.h"