Update the documentation contained in the header files to be correct for V9.0.0 release candidate 2.
diff --git a/FreeRTOS/Source/event_groups.c b/FreeRTOS/Source/event_groups.c
index 2f4cd79..4cd8991 100644
--- a/FreeRTOS/Source/event_groups.c
+++ b/FreeRTOS/Source/event_groups.c
@@ -132,15 +132,15 @@
#if( configSUPPORT_STATIC_ALLOCATION == 1 )
- EventGroupHandle_t xEventGroupCreateStatic( StaticEventGroup_t *pxStaticEventGroup )
+ EventGroupHandle_t xEventGroupCreateStatic( StaticEventGroup_t *pxEventGroupBuffer )
{
EventGroup_t *pxEventBits;
/* A StaticEventGroup_t object must be provided. */
- configASSERT( pxStaticEventGroup );
+ configASSERT( pxEventGroupBuffer );
/* The user has provided a statically allocated event group - use it. */
- pxEventBits = ( EventGroup_t * ) pxStaticEventGroup; /*lint !e740 EventGroup_t and StaticEventGroup_t are guaranteed to have the same size and alignment requirement - checked by configASSERT(). */
+ pxEventBits = ( EventGroup_t * ) pxEventGroupBuffer; /*lint !e740 EventGroup_t and StaticEventGroup_t are guaranteed to have the same size and alignment requirement - checked by configASSERT(). */
if( pxEventBits != NULL )
{
diff --git a/FreeRTOS/Source/include/FreeRTOS.h b/FreeRTOS/Source/include/FreeRTOS.h
index 7e6411d..8b8efca 100644
--- a/FreeRTOS/Source/include/FreeRTOS.h
+++ b/FreeRTOS/Source/include/FreeRTOS.h
@@ -944,7 +944,7 @@
uint32_t ulDummy18;
uint8_t ucDummy19;
#endif
- #if ( configSUPPORT_STATIC_ALLOCATION == 1 )
+ #if( ( configSUPPORT_STATIC_ALLOCATION == 1 ) && ( configSUPPORT_DYNAMIC_ALLOCATION == 1 ) )
uint8_t uxDummy20;
#endif
@@ -978,7 +978,7 @@
UBaseType_t uxDummy4[ 3 ];
uint8_t ucDummy5[ 2 ];
- #if( configSUPPORT_STATIC_ALLOCATION == 1 )
+ #if( ( configSUPPORT_STATIC_ALLOCATION == 1 ) && ( configSUPPORT_DYNAMIC_ALLOCATION == 1 ) )
uint8_t ucDummy6;
#endif
@@ -1017,8 +1017,8 @@
UBaseType_t uxDummy3;
#endif
- #if( configSUPPORT_STATIC_ALLOCATION == 1 )
- uint8_t ucStaticallyAllocated;
+ #if( ( configSUPPORT_STATIC_ALLOCATION == 1 ) && ( configSUPPORT_DYNAMIC_ALLOCATION == 1 ) )
+ uint8_t ucDummy4;
#endif
} StaticEventGroup_t;
@@ -1048,8 +1048,8 @@
UBaseType_t uxDummy6;
#endif
- #if( configSUPPORT_STATIC_ALLOCATION == 1 )
- uint8_t ucStaticallyAllocated;
+ #if( ( configSUPPORT_STATIC_ALLOCATION == 1 ) && ( configSUPPORT_DYNAMIC_ALLOCATION == 1 ) )
+ uint8_t ucDummy7;
#endif
} StaticTimer_t;
diff --git a/FreeRTOS/Source/include/event_groups.h b/FreeRTOS/Source/include/event_groups.h
index c7189a1..63a57b2 100644
--- a/FreeRTOS/Source/include/event_groups.h
+++ b/FreeRTOS/Source/include/event_groups.h
@@ -138,7 +138,17 @@
EventGroupHandle_t xEventGroupCreate( void );
</pre>
*
- * Create a new event group. This function cannot be called from an interrupt.
+ * Create a new event group.
+ *
+ * Internally, within the FreeRTOS implementation, event groups use a [small]
+ * block of memory, in which the event group's structure is stored. If an event
+ * groups is created using xEventGropuCreate() then the required memory is
+ * automatically dynamically allocated inside the xEventGroupCreate() function.
+ * (see http://www.freertos.org/a00111.html). If an event group is created
+ * using xEventGropuCreateStatic() then the application writer must instead
+ * provide the memory that will get used by the event group.
+ * xEventGroupCreateStatic() therefore allows an event group to be created
+ * without using any dynamic memory allocation.
*
* Although event groups are not related to ticks, for internal implementation
* reasons the number of bits available for use in an event group is dependent
@@ -178,8 +188,57 @@
EventGroupHandle_t xEventGroupCreate( void ) PRIVILEGED_FUNCTION;
#endif
+/**
+ * event_groups.h
+ *<pre>
+ EventGroupHandle_t xEventGroupCreateStatic( EventGroupHandle_t * pxEventGroupBuffer );
+ </pre>
+ *
+ * Create a new event group.
+ *
+ * Internally, within the FreeRTOS implementation, event groups use a [small]
+ * block of memory, in which the event group's structure is stored. If an event
+ * groups is created using xEventGropuCreate() then the required memory is
+ * automatically dynamically allocated inside the xEventGroupCreate() function.
+ * (see http://www.freertos.org/a00111.html). If an event group is created
+ * using xEventGropuCreateStatic() then the application writer must instead
+ * provide the memory that will get used by the event group.
+ * xEventGroupCreateStatic() therefore allows an event group to be created
+ * without using any dynamic memory allocation.
+ *
+ * Although event groups are not related to ticks, for internal implementation
+ * reasons the number of bits available for use in an event group is dependent
+ * on the configUSE_16_BIT_TICKS setting in FreeRTOSConfig.h. If
+ * configUSE_16_BIT_TICKS is 1 then each event group contains 8 usable bits (bit
+ * 0 to bit 7). If configUSE_16_BIT_TICKS is set to 0 then each event group has
+ * 24 usable bits (bit 0 to bit 23). The EventBits_t type is used to store
+ * event bits within an event group.
+ *
+ * @param pxEventGroupBuffer pxEventGroupBuffer must point to a variable of type
+ * StaticEventGroup_t, which will be then be used to hold the event group's data
+ * structures, removing the need for the memory to be allocated dynamically.
+ *
+ * @return If the event group was created then a handle to the event group is
+ * returned. If pxEventGroupBuffer was NULL then NULL is returned.
+ *
+ * Example usage:
+ <pre>
+ // StaticEventGroup_t is a publicly accessible structure that has the same
+ // size and alignment requirements as the real event group structure. It is
+ // provided as a mechanism for applications to know the size of the event
+ // group (which is dependent on the architecture and configuration file
+ // settings) without breaking the strict data hiding policy by exposing the
+ // real event group internals. This StaticEventGroup_t variable is passed
+ // into the xSemaphoreCreateEventGroupStatic() function and is used to store
+ // the event group's data structures
+ StaticEventGroup_t xEventGroupBuffer;
+
+ // Create the event group without dynamically allocating any memory.
+ xEventGroup = xEventGroupCreateStatic( &xEventGroupBuffer );
+ </pre>
+ */
#if( configSUPPORT_STATIC_ALLOCATION == 1 )
- EventGroupHandle_t xEventGroupCreateStatic( StaticEventGroup_t *pxStaticEventGroup ) PRIVILEGED_FUNCTION;
+ EventGroupHandle_t xEventGroupCreateStatic( StaticEventGroup_t *pxEventGroupBuffer ) PRIVILEGED_FUNCTION;
#endif
/**
diff --git a/FreeRTOS/Source/include/queue.h b/FreeRTOS/Source/include/queue.h
index e8f54a4..a3e5522 100644
--- a/FreeRTOS/Source/include/queue.h
+++ b/FreeRTOS/Source/include/queue.h
@@ -126,16 +126,17 @@
* Creates a new queue instance, and returns a handle by which the new queue
* can be referenced.
*
- * Internally, within the FreeRTOS implementation, queue's use two blocks of
+ * Internally, within the FreeRTOS implementation, queues use two blocks of
* memory. The first block is used to hold the queue's data structures. The
* second block is used to hold items placed into the queue. If a queue is
* created using xQueueCreate() then both blocks of memory are automatically
* dynamically allocated inside the xQueueCreate() function. (see
* http://www.freertos.org/a00111.html). If a queue is created using
- * xQueueCreateStatic() then the application writer can instead optionally
- * provide the memory that will get used by the queue. xQueueCreateStatic()
- * therefore allows a queue to be created without using any dynamic memory
- * allocation.
+ * xQueueCreateStatic() then the application writer must provide the memory that
+ * will get used by the queue. xQueueCreateStatic() therefore allows a queue to
+ * be created without using any dynamic memory allocation.
+ *
+ * http://www.FreeRTOS.org/Embedded-RTOS-Queues.html
*
* @param uxQueueLength The maximum number of items that the queue can contain.
*
@@ -199,16 +200,17 @@
* Creates a new queue instance, and returns a handle by which the new queue
* can be referenced.
*
- * Internally, within the FreeRTOS implementation, queue's use two blocks of
+ * Internally, within the FreeRTOS implementation, queues use two blocks of
* memory. The first block is used to hold the queue's data structures. The
* second block is used to hold items placed into the queue. If a queue is
* created using xQueueCreate() then both blocks of memory are automatically
* dynamically allocated inside the xQueueCreate() function. (see
* http://www.freertos.org/a00111.html). If a queue is created using
- * xQueueCreateStatic() then the application writer can instead optionally
- * provide the memory that will get used by the queue. xQueueCreateStatic()
- * therefore allows a queue to be created without using any dynamic memory
- * allocation.
+ * xQueueCreateStatic() then the application writer must provide the memory that
+ * will get used by the queue. xQueueCreateStatic() therefore allows a queue to
+ * be created without using any dynamic memory allocation.
+ *
+ * http://www.FreeRTOS.org/Embedded-RTOS-Queues.html
*
* @param uxQueueLength The maximum number of items that the queue can contain.
*
@@ -217,27 +219,17 @@
* that will be copied for each posted item. Each item on the queue must be
* the same size.
*
- * @param pucQueueStorageBuffer If pucQueueStorageBuffer is NULL then the memory
- * used to hold items stored in the queue will be allocated dynamically, just as
- * when a queue is created using xQueueCreate(). If pxQueueStorageBuffer is not
- * NULL then it must point to a uint8_t array that is at least large enough to
- * hold the maximum number of items that can be in the queue at any one time -
- * which is ( uxQueueLength * uxItemsSize ) bytes.
+ * @param pucQueueStorageBuffer If uxItemSize is not zero then
+ * pucQueueStorageBuffer must point to a uint8_t array that is at least large
+ * enough to hold the maximum number of items that can be in the queue at any
+ * one time - which is ( uxQueueLength * uxItemsSize ) bytes. If uxItemSize is
+ * zero then pucQueueStorageBuffer can be NULL.
*
- * @param pxQueueBuffer If pxQueueBuffer is NULL then the memory required to
- * hold the queue's data structures will be allocated dynamically, just as when
- * a queue is created using xQueueCreate(). If pxQueueBuffer is not NULL then
- * it must point to a variable of type StaticQueue_t, which will then be used to
- * hold the queue's data structure, removing the need for the memory to be
- * allocated dynamically.
+ * @param pxQueueBuffer Must point to a variable of type StaticQueue_t, which
+ * will be used to hold the queue's data structure.
*
- * @return If neither pucQueueStorageBuffer or pxQueueBuffer are NULL, then the
- * function will not attempt any dynamic memory allocation, and a handle to the
- * created queue will always be returned. If pucQueueStorageBuffer or
- * pxQueueBuffer is NULL then the function will attempt to dynamically allocate
- * one of both buffers. In this case, if the allocation succeeds then a handle
- * to the created queue will be returned, and if one of the the allocation fails
- * NULL will be returned.
+ * @return If the queue is created then a handle to the created queue is
+ * returned. If pxQueueBuffer is NULL then NULL is returned.
*
* Example usage:
<pre>
@@ -268,7 +260,7 @@
&xQueueBuffer ); // The buffer that will hold the queue structure.
// The queue is guaranteed to be created successfully as no dynamic memory
- // allocation was used. Therefore xQueue1 is now a handle to a valid queue.
+ // allocation is used. Therefore xQueue1 is now a handle to a valid queue.
// ... Rest of task code.
}
diff --git a/FreeRTOS/Source/include/semphr.h b/FreeRTOS/Source/include/semphr.h
index 4dbd6f5..29a0f98 100644
--- a/FreeRTOS/Source/include/semphr.h
+++ b/FreeRTOS/Source/include/semphr.h
@@ -160,9 +160,8 @@
* automatically dynamically allocated inside the xSemaphoreCreateBinary()
* function. (see http://www.freertos.org/a00111.html). If a binary semaphore
* is created using xSemaphoreCreateBinaryStatic() then the application writer
- * can instead optionally provide the memory that will get used by the binary
- * semaphore. xSemaphoreCreateBinaryStatic() therefore allows a binary
- * semaphore to be created without using any dynamic memory allocation.
+ * must provide the memory. xSemaphoreCreateBinaryStatic() therefore allows a
+ * binary semaphore to be created without using any dynamic memory allocation.
*
* The old vSemaphoreCreateBinary() macro is now deprecated in favour of this
* xSemaphoreCreateBinary() function. Note that binary semaphores created using
@@ -222,9 +221,8 @@
* automatically dynamically allocated inside the xSemaphoreCreateBinary()
* function. (see http://www.freertos.org/a00111.html). If a binary semaphore
* is created using xSemaphoreCreateBinaryStatic() then the application writer
- * can instead optionally provide the memory that will get used by the binary
- * semaphore. xSemaphoreCreateBinaryStatic() therefore allows a binary
- * semaphore to be created without using any dynamic memory allocation.
+ * must provide the memory. xSemaphoreCreateBinaryStatic() therefore allows a
+ * binary semaphore to be created without using any dynamic memory allocation.
*
* This type of semaphore can be used for pure synchronisation between tasks or
* between an interrupt and a task. The semaphore need not be given back once
@@ -233,21 +231,12 @@
* semaphore does not use a priority inheritance mechanism. For an alternative
* that does use priority inheritance see xSemaphoreCreateMutex().
*
- * @param pxSemaphoreBuffer If pxSemaphoreBuffer is NULL then the memory
- * required to hold the semaphore's data structures will be allocated
- * dynamically, just as when a semaphore is created using
- * xSemaphoreCreateBinary(). If pxSemaphoreBuffer is not NULL then it must
- * point to a variable of type StaticSemaphore_t, which will then be used to
- * hold the semaphore's data structure, removing the need for the memory to be
- * allocated dynamically.
+ * @param pxSemaphoreBuffer Must point to a variable of type StaticSemaphore_t,
+ * which will then be used to hold the semaphore's data structure, removing the
+ * need for the memory to be allocated dynamically.
*
- * @return If pxSemaphoreBuffer is not NULL then the function will not attempt
- * any dynamic memory allocation, and a handle to the created semaphore will
- * always be returned. If pxSemaphoreBuffer is NULL then the function will
- * attempt to dynamically allocate the memory required to hold the semaphore's
- * data structures. In this case, if the allocation succeeds then a handle to
- * the created semaphore will be returned, and if the allocation fails NULL will
- * be returned.
+ * @return If the semaphore is created then a handle to the created semaphore is
+ * returned. If pxSemaphoreBuffer is NULL then NULL is returned.
*
* Example usage:
<pre>
@@ -718,10 +707,9 @@
* using xSemaphoreCreateMutex() then the required memory is automatically
* dynamically allocated inside the xSemaphoreCreateMutex() function. (see
* http://www.freertos.org/a00111.html). If a mutex is created using
- * xSemaphoreCreateMutexStatic() then the application writer can instead
- * optionally provide the memory that will get used by the mutex.
- * xSemaphoreCreateMutexStatic() therefore allows a mutex to be created without
- * using any dynamic memory allocation.
+ * xSemaphoreCreateMutexStatic() then the application writer must provided the
+ * memory. xSemaphoreCreateMutexStatic() therefore allows a mutex to be created
+ * without using any dynamic memory allocation.
*
* Mutexes created using this function can be accessed using the xSemaphoreTake()
* and xSemaphoreGive() macros. The xSemaphoreTakeRecursive() and
@@ -778,10 +766,9 @@
* using xSemaphoreCreateMutex() then the required memory is automatically
* dynamically allocated inside the xSemaphoreCreateMutex() function. (see
* http://www.freertos.org/a00111.html). If a mutex is created using
- * xSemaphoreCreateMutexStatic() then the application writer can instead
- * optionally provide the memory that will get used by the mutex.
- * xSemaphoreCreateMutexStatic() therefore allows a mutex to be created without
- * using any dynamic memory allocation.
+ * xSemaphoreCreateMutexStatic() then the application writer must provided the
+ * memory. xSemaphoreCreateMutexStatic() therefore allows a mutex to be created
+ * without using any dynamic memory allocation.
*
* Mutexes created using this function can be accessed using the xSemaphoreTake()
* and xSemaphoreGive() macros. The xSemaphoreTakeRecursive() and
@@ -798,16 +785,12 @@
* semaphore and another always 'takes' the semaphore) and from within interrupt
* service routines.
*
- * @param pxMutexBuffer If pxMutexBuffer is NULL then the memory required to
- * hold the mutex's data structures will be allocated dynamically, just as when
- * a mutex is created using xSemaphoreCreateMutex(). If pxMutexBuffer is not
- * NULL then it must point to a variable of type StaticSemaphore_t, which will
- * then be used to hold the mutex's data structure, removing the need for
+ * @param pxMutexBuffer Must point to a variable of type StaticSemaphore_t,
+ * which will be used to hold the mutex's data structure, removing the need for
* the memory to be allocated dynamically.
*
* @return If the mutex was successfully created then a handle to the created
- * mutex is returned. If pxMutexBuffer was NULL, and there was not enough
- * heap to allocate the mutex data structures, then NULL is returned.
+ * mutex is returned. If pxMutexBuffer was NULL then NULL is returned.
*
* Example usage:
<pre>
@@ -846,8 +829,8 @@
* automatically dynamically allocated inside the
* xSemaphoreCreateRecursiveMutex() function. (see
* http://www.freertos.org/a00111.html). If a recursive mutex is created using
- * xSemaphoreCreateRecursiveMutexStatic() then the application writer can
- * instead optionally provide the memory that will get used by the mutex.
+ * xSemaphoreCreateRecursiveMutexStatic() then the application writer must
+ * provide the memory that will get used by the mutex.
* xSemaphoreCreateRecursiveMutexStatic() therefore allows a recursive mutex to
* be created without using any dynamic memory allocation.
*
@@ -913,8 +896,8 @@
* automatically dynamically allocated inside the
* xSemaphoreCreateRecursiveMutex() function. (see
* http://www.freertos.org/a00111.html). If a recursive mutex is created using
- * xSemaphoreCreateRecursiveMutexStatic() then the application writer can
- * instead optionally provide the memory that will get used by the mutex.
+ * xSemaphoreCreateRecursiveMutexStatic() then the application writer must
+ * provide the memory that will get used by the mutex.
* xSemaphoreCreateRecursiveMutexStatic() therefore allows a recursive mutex to
* be created without using any dynamic memory allocation.
*
@@ -940,17 +923,12 @@
* semaphore and another always 'takes' the semaphore) and from within interrupt
* service routines.
*
- * @param pxMutexBuffer If pxMutexBuffer is NULL then the memory required to
- * hold the recursive mutex's data structures will be allocated dynamically,
- * just as when a recursive mutex is created using
- * xSemaphoreCreateRecursiveMutex(). If pxMutexBuffer is not NULL then it must
- * point to a variable of type StaticSemaphore_t, which will then be used to
- * hold the recursive mutex's data structure, removing the need for the memory
- * to be allocated dynamically.
+ * @param pxMutexBuffer Must point to a variable of type StaticSemaphore_t,
+ * which will then be used to hold the recursive mutex's data structure,
+ * removing the need for the memory to be allocated dynamically.
*
* @return If the recursive mutex was successfully created then a handle to the
- * created recursive mutex is returned. If pxMutexBuffer was NULL, and there
- * was not enough heap to allocate the mutex data structures, then NULL is
+ * created recursive mutex is returned. If pxMutexBuffer was NULL then NULL is
* returned.
*
* Example usage:
@@ -985,6 +963,10 @@
* Creates a new counting semaphore instance, and returns a handle by which the
* new counting semaphore can be referenced.
*
+ * In many usage scenarios it is faster and more memory efficient to use a
+ * direct to task notification in place of a counting semaphore!
+ * http://www.freertos.org/RTOS-task-notifications.html
+ *
* Internally, within the FreeRTOS implementation, counting semaphores use a
* block of memory, in which the counting semaphore structure is stored. If a
* counting semaphore is created using xSemaphoreCreateCounting() then the
@@ -1061,16 +1043,19 @@
* Creates a new counting semaphore instance, and returns a handle by which the
* new counting semaphore can be referenced.
*
+ * In many usage scenarios it is faster and more memory efficient to use a
+ * direct to task notification in place of a counting semaphore!
+ * http://www.freertos.org/RTOS-task-notifications.html
+ *
* Internally, within the FreeRTOS implementation, counting semaphores use a
* block of memory, in which the counting semaphore structure is stored. If a
* counting semaphore is created using xSemaphoreCreateCounting() then the
* required memory is automatically dynamically allocated inside the
* xSemaphoreCreateCounting() function. (see
* http://www.freertos.org/a00111.html). If a counting semaphore is created
- * using xSemaphoreCreateCountingStatic() then the application writer can
- * instead optionally provide the memory that will get used by the counting
- * semaphore. xSemaphoreCreateCountingStatic() therefore allows a counting
- * semaphore to be created without using any dynamic memory allocation.
+ * using xSemaphoreCreateCountingStatic() then the application writer must
+ * provide the memory. xSemaphoreCreateCountingStatic() therefore allows a
+ * counting semaphore to be created without using any dynamic memory allocation.
*
* Counting semaphores are typically used for two things:
*
@@ -1100,18 +1085,13 @@
* @param uxInitialCount The count value assigned to the semaphore when it is
* created.
*
- * @param pxSemaphoreBuffer If pxSemaphoreBuffer is NULL then the memory
- * required to hold the semaphore's data structures will be allocated
- * dynamically, just as when a counting semaphore is created using
- * xSemaphoreCreateCounting(). If pxSemaphoreBuffer is not NULL then it must
- * point to a variable of type StaticSemaphore_t, which will then be used to
- * hold the semaphore's data structure, removing the need for the memory
- * to be allocated dynamically.
+ * @param pxSemaphoreBuffer Must point to a variable of type StaticSemaphore_t,
+ * which will then be used to hold the semaphore's data structure, removing the
+ * need for the memory to be allocated dynamically.
*
* @return If the counting semaphore was successfully created then a handle to
- * the created counting semaphore is returned. If pxSemaphoreBuffer was NULL,
- * and there was not enough heap to allocate the counting semaphore data
- * structures, then NULL is returned.
+ * the created counting semaphore is returned. If pxSemaphoreBuffer was NULL
+ * then NULL is returned.
*
* Example usage:
<pre>
diff --git a/FreeRTOS/Source/include/task.h b/FreeRTOS/Source/include/task.h
index 359bf71..7af7a2e 100644
--- a/FreeRTOS/Source/include/task.h
+++ b/FreeRTOS/Source/include/task.h
@@ -277,16 +277,15 @@
*
* Create a new task and add it to the list of tasks that are ready to run.
*
- * Internally, within the FreeRTOS implementation, tasks's use two blocks of
- * memory. The first block is used to hold the tasks's data structures. The
+ * Internally, within the FreeRTOS implementation, tasks use two blocks of
+ * memory. The first block is used to hold the task's data structures. The
* second block is used by the task as its stack. If a task is created using
* xTaskCreate() then both blocks of memory are automatically dynamically
* allocated inside the xTaskCreate() function. (see
* http://www.freertos.org/a00111.html). If a task is created using
- * xTaskCreateStatic() then the application writer can instead optionally
- * provide the memory that will get used by the task. xTaskCreateStatic()
- * therefore allows a task to be created without using any dynamic memory
- * allocation.
+ * xTaskCreateStatic() then the application writer must provide the required
+ * memory. xTaskCreateStatic() therefore allows a task to be created without
+ * using any dynamic memory allocation.
*
* See xTaskCreateStatic() for a version that does not use any dynamic memory
* allocation.
@@ -377,16 +376,15 @@
*
* Create a new task and add it to the list of tasks that are ready to run.
*
- * Internally, within the FreeRTOS implementation, tasks's use two blocks of
- * memory. The first block is used to hold the tasks's data structures. The
+ * Internally, within the FreeRTOS implementation, tasks use two blocks of
+ * memory. The first block is used to hold the task's data structures. The
* second block is used by the task as its stack. If a task is created using
* xTaskCreate() then both blocks of memory are automatically dynamically
* allocated inside the xTaskCreate() function. (see
* http://www.freertos.org/a00111.html). If a task is created using
- * xTaskCreateStatic() then the application writer can instead optionally
- * provide the memory that will get used by the task. xTaskCreateStatic()
- * therefore allows a task to be created without using any dynamic memory
- * allocation.
+ * xTaskCreateStatic() then the application writer must provide the required
+ * memory. xTaskCreateStatic() therefore allows a task to be created without
+ * using any dynamic memory allocation.
*
* @param pvTaskCode Pointer to the task entry function. Tasks
* must be implemented to never return (i.e. continuous loop).
@@ -408,26 +406,18 @@
* @param pvCreatedTask Used to pass back a handle by which the created task
* can be referenced. Pass as NULL if the handle is not required.
*
- * @param pxStackBuffer If pxStackBuffer is NULL then the stack used by the
- * task will be allocated dynamically, just as if the task was created using
- * xTaskCreate(). If pxStackBuffer is not NULL then it must point to a
- * StackType_t array that has at least usStackDepth indexes - the array will
- * then be used as the task's stack, removing the need for the stack to be
- * allocated dynamically.
+ * @param pxStackBuffer Must point to a StackType_t array that has at least
+ * usStackDepth indexes - the array will then be used as the task's stack,
+ * removing the need for the stack to be allocated dynamically.
*
- * @param pxTaskBuffer If pxTaskBuffer is NULL then the memory used to hold the
- * task's data structures will be allocated dynamically, just as when a task is
- * created using xTaskCreate(). If pxTaskBuffer is not NULL then it must point
- * to a variable of type StaticTask_t, which will then be used to hold the
- * task's data structures, removing the need for the memory to be allocated
- * dynamically.
+ * @param pxTaskBuffer Must point to a variable of type StaticTask_t, which will
+ * then be used to hold the task's data structures, removing the need for the
+ * memory to be allocated dynamically.
*
- * @return If neither pxStackBuffer or pxTaskBuffer are NULL, then the function
- * will not attempt any dynamic memory allocation, and pdPASS will always be
- * returned. If pxStackBuffer or pxTaskBuffer is NULL then the function will
- * attempt to dynamically allocate one of both buffers. In this case, if the
- * allocation succeeds then pdPASS will be returned, and if the allocation fails
- * then an error code defined in projdefs.h is returned.
+ * @return If neither pxStackBuffer or pxTaskBuffer are NULL, then the task will
+ * be created and pdPASS is returned. If either pxStackBuffer or pxTaskBuffer
+ * are NULL then the task will not be created and
+ * errCOULD_NOT_ALLOCATE_REQUIRED_MEMORY is returned.
*
* Example usage:
<pre>
diff --git a/FreeRTOS/Source/include/timers.h b/FreeRTOS/Source/include/timers.h
index 5a6003d..b314539 100644
--- a/FreeRTOS/Source/include/timers.h
+++ b/FreeRTOS/Source/include/timers.h
@@ -138,15 +138,14 @@
* Creates a new software timer instance, and returns a handle by which the
* created software timer can be referenced.
*
- * Internally, within the FreeRTOS implementation, software timer's use a block
+ * Internally, within the FreeRTOS implementation, software timers use a block
* of memory, in which the timer data structure is stored. If a software timer
* is created using xTimerCreate() then the required memory is automatically
* dynamically allocated inside the xTimerCreate() function. (see
* http://www.freertos.org/a00111.html). If a software timer is created using
- * xTimerCreateStatic() then the application writer can instead optionally
- * provide the memory that will get used by the software timer.
- * xTimerCreateStatic() therefore allows a software timer to be created without
- * using any dynamic memory allocation.
+ * xTimerCreateStatic() then the application writer must provide the memory that
+ * will get used by the software timer. xTimerCreateStatic() therefore allows a
+ * software timer to be created without using any dynamic memory allocation.
*
* Timers are created in the dormant state. The xTimerStart(), xTimerReset(),
* xTimerStartFromISR(), xTimerResetFromISR(), xTimerChangePeriod() and
@@ -281,15 +280,14 @@
* Creates a new software timer instance, and returns a handle by which the
* created software timer can be referenced.
*
- * Internally, within the FreeRTOS implementation, software timer's use a block
+ * Internally, within the FreeRTOS implementation, software timers use a block
* of memory, in which the timer data structure is stored. If a software timer
* is created using xTimerCreate() then the required memory is automatically
* dynamically allocated inside the xTimerCreate() function. (see
* http://www.freertos.org/a00111.html). If a software timer is created using
- * xTimerCreateStatic() then the application writer can instead optionally
- * provide the memory that will get used by the software timer.
- * xTimerCreateStatic() therefore allows a software to be created without using
- * any dynamic memory allocation.
+ * xTimerCreateStatic() then the application writer must provide the memory that
+ * will get used by the software timer. xTimerCreateStatic() therefore allows a
+ * software timer to be created without using any dynamic memory allocation.
*
* Timers are created in the dormant state. The xTimerStart(), xTimerReset(),
* xTimerStartFromISR(), xTimerResetFromISR(), xTimerChangePeriod() and
@@ -322,19 +320,12 @@
* Callback functions must have the prototype defined by TimerCallbackFunction_t,
* which is "void vCallbackFunction( TimerHandle_t xTimer );".
*
- * @param pxTimerBuffer If pxTimerBuffer is NULL then the memory required to
- * hold the software timer's data structure will be allocated dynamically, just
- * as when a software timer is created using xTimerCreate(). If pxTimerBuffer
- * is not NULL then it must point to a variable of type StaticTimer_t, which
+ * @param pxTimerBuffer Must point to a variable of type StaticTimer_t, which
* will be then be used to hold the software timer's data structures, removing
* the need for the memory to be allocated dynamically.
*
- * @return If pxTimerBuffer is not NULL then the function will not attempt
- * any dynamic memory allocation, and a handle to the created timer will always
- * be returned. If pxTimerBuffer is NULL then the function will attempt to
- * dynamically allocate the memory required to hold the timer's data structures.
- * In this case, if the allocation succeeds then a handle to the created timer
- * will be returned, and if the allocation fails NULL will be returned.
+ * @return If the timer is created then a handle to the created timer is
+ * returned. If pxTimerBuffer was NULL then NULL is returned.
*
* Example usage:
* @verbatim
diff --git a/FreeRTOS/Source/portable/MSVC-MingW/port.c b/FreeRTOS/Source/portable/MSVC-MingW/port.c
index db298be..ad023f1 100644
--- a/FreeRTOS/Source/portable/MSVC-MingW/port.c
+++ b/FreeRTOS/Source/portable/MSVC-MingW/port.c
@@ -261,6 +261,16 @@
xThreadState *pxThreadState = NULL;
int8_t *pcTopOfStack = ( int8_t * ) pxTopOfStack;
+ #ifdef portSOAK_TEST
+ {
+ /* Ensure highest priority class is inherited. */
+ if( !SetPriorityClass( GetCurrentProcess(), REALTIME_PRIORITY_CLASS ) )
+ {
+ printf( "SetPriorityClass() failed\r\n" );
+ }
+ }
+ #endif
+
/* In this simulated case a stack is not initialised, but instead a thread
is created that will execute the task being created. The thread handles
the context switching itself. The xThreadState object is placed onto
diff --git a/FreeRTOS/Source/portable/MSVC-MingW/portmacro.h b/FreeRTOS/Source/portable/MSVC-MingW/portmacro.h
index a3da226..be10e62 100644
--- a/FreeRTOS/Source/portable/MSVC-MingW/portmacro.h
+++ b/FreeRTOS/Source/portable/MSVC-MingW/portmacro.h
@@ -70,6 +70,7 @@
#ifndef PORTMACRO_H
#define PORTMACRO_H
+#include <Windows.h>
/******************************************************************************
Defines
