Update documentation.

git-svn-id: https://svn.code.sf.net/p/freertos/code/trunk@127 1d2547de-c912-0410-9cb9-b8ca96c0e9e2

diff --git a/Source/include/queue.h b/Source/include/queue.h
index b093e7c1ac4800258929b899154c2cec0beb6e95..bafb5661961a88576aa43d8cf25ad361d157f2b0 100644 (file)
--- a/Source/include/queue.h
+++ b/Source/include/queue.h
@@ -1160,25 +1160,21 @@ signed portBASE_TYPE xQueueGenericSendFromISR( xQueueHandle pxQueue, const void
 signed portBASE_TYPE xQueueReceiveFromISR( xQueueHandle pxQueue, const void * const pvBuffer, signed portBASE_TYPE *pxTaskWoken );\r
 \r
 /* \r
- * xQueueAltGenericSend() is a light weight version of xQueueGenericSend().\r
- * Likewise xQueueAltGenericReceive() is a light weight version of\r
+ * xQueueAltGenericSend() is an alternative version of xQueueGenericSend().\r
+ * Likewise xQueueAltGenericReceive() is an alternative version of\r
  * xQueueGenericReceive().\r
  *\r
- * The source code that implements the light weight (fast) API is much \r
+ * The source code that implements the alternative (Alt) API is much \r
  * simpler     because it executes everything from within a critical section.  \r
  * This is     the approach taken by many other RTOSes, but FreeRTOS.org has the \r
- * fully featured API as an alternative.  The fully featured API has more \r
+ * preferred fully featured API too.  The fully featured API has more \r
  * complex     code that takes longer to execute, but makes much less use of \r
- * critical sections.  Therefore the light weight API sacrifices interrupt \r
+ * critical sections.  Therefore the alternative API sacrifices interrupt \r
  * responsiveness to gain execution speed, whereas the fully featured API\r
  * sacrifices execution speed to ensure better interrupt responsiveness.\r
  */\r
 signed portBASE_TYPE xQueueAltGenericSend( xQueueHandle pxQueue, const void * const pvItemToQueue, portTickType xTicksToWait, portBASE_TYPE xCopyPosition );\r
 signed portBASE_TYPE xQueueAltGenericReceive( xQueueHandle pxQueue, const void * const pvBuffer, portTickType xTicksToWait, portBASE_TYPE xJustPeeking );\r
-\r
-/*\r
- * The light weight versions of the fully featured macros.\r
- */\r
 #define xQueueAltSendToFront( xQueue, pvItemToQueue, xTicksToWait ) xQueueAltGenericSend( xQueue, pvItemToQueue, xTicksToWait, queueSEND_TO_FRONT )\r
 #define xQueueAltSendToBack( xQueue, pvItemToQueue, xTicksToWait ) xQueueAltGenericSend( xQueue, pvItemToQueue, xTicksToWait, queueSEND_TO_BACK )\r
 #define xQueueAltReceive( xQueue, pvBuffer, xTicksToWait ) xQueueAltGenericReceive( xQueue, pvBuffer, xTicksToWait, pdFALSE )\r

diff --git a/Source/include/semphr.h b/Source/include/semphr.h
index 75d6e8a33651cb3df4bb1920ac7a202c454897c1..c14af05b5b0f4e874886d918dfada73b72e79af1 100644 (file)
--- a/Source/include/semphr.h
+++ b/Source/include/semphr.h
@@ -155,6 +155,19 @@ typedef xQueueHandle xSemaphoreHandle;
  * \ingroup Semaphores\r
  */\r
 #define xSemaphoreTake( xSemaphore, xBlockTime )               xQueueGenericReceive( ( xQueueHandle ) xSemaphore, NULL, xBlockTime, pdFALSE )\r
+\r
+/* \r
+ * xSemaphoreAltTake() is an alternative version of xSemaphoreTake().\r
+ *\r
+ * The source code that implements the alternative (Alt) API is much \r
+ * simpler     because it executes everything from within a critical section.  \r
+ * This is     the approach taken by many other RTOSes, but FreeRTOS.org has the \r
+ * preferred fully featured API too.  The fully featured API has more \r
+ * complex     code that takes longer to execute, but makes much less use of \r
+ * critical sections.  Therefore the alternative API sacrifices interrupt \r
+ * responsiveness to gain execution speed, whereas the fully featured API\r
+ * sacrifices execution speed to ensure better interrupt responsiveness.\r
+ */\r
 #define xSemaphoreAltTake( xSemaphore, xBlockTime )            xQueueAltGenericReceive( ( xQueueHandle ) xSemaphore, NULL, xBlockTime, pdFALSE )\r
 \r
 /**\r
@@ -215,6 +228,19 @@ typedef xQueueHandle xSemaphoreHandle;
  * \ingroup Semaphores\r
  */\r
 #define xSemaphoreGive( xSemaphore )           xQueueGenericSend( ( xQueueHandle ) xSemaphore, NULL, semGIVE_BLOCK_TIME, queueSEND_TO_BACK )\r
+\r
+/* \r
+ * xSemaphoreAltGive() is an alternative version of xSemaphoreGive().\r
+ *\r
+ * The source code that implements the alternative (Alt) API is much \r
+ * simpler     because it executes everything from within a critical section.  \r
+ * This is     the approach taken by many other RTOSes, but FreeRTOS.org has the \r
+ * preferred fully featured API too.  The fully featured API has more \r
+ * complex     code that takes longer to execute, but makes much less use of \r
+ * critical sections.  Therefore the alternative API sacrifices interrupt \r
+ * responsiveness to gain execution speed, whereas the fully featured API\r
+ * sacrifices execution speed to ensure better interrupt responsiveness.\r
+ */\r
 #define xSemaphoreAltGive( xSemaphore )                xQueueAltGenericSend( ( xQueueHandle ) xSemaphore, NULL, semGIVE_BLOCK_TIME, queueSEND_TO_BACK )\r
 \r
 /**\r
@@ -313,7 +339,7 @@ typedef xQueueHandle xSemaphoreHandle;
  *\r
  * Mutex type semaphores cannot be used from within interrupt service routines.  \r
  *\r
- * See xSemaphoreCreateBinary() for an alternative implemnetation that can be \r
+ * See xSemaphoreCreateBinary() for an alternative implementation that can be \r
  * used for pure synchronisation (where one task or interrupt always 'gives' the \r
  * semaphore and another always 'takes' the semaphore) and from within interrupt \r
  * service routines.\r

diff --git a/Source/queue.c b/Source/queue.c
index 80b014966ff70ccbd6e068427ac3097bded876f1..67e24e9c31d3ad25044240a91ca5eb9531017172 100644 (file)
--- a/Source/queue.c
+++ b/Source/queue.c
@@ -464,12 +464,12 @@ xTimeOutType xTimeOut;
        signed portBASE_TYPE xReturn;\r
        xTimeOutType xTimeOut;\r
 \r
-               /* The source code that implements the light weight (fast) API is much \r
+               /* The source code that implements the alternative (Alt) API is much \r
                simpler because it executes everything from within a critical section.  \r
                This is the approach taken by many other RTOSes, but FreeRTOS.org has the \r
-               fully featured API as an alternative.  The fully featured API has more \r
+               preferred fully featured API too.  The fully featured API has more \r
                complex code that takes longer to execute, but makes much less use of \r
-               critical sections.  Therefore the light weight API sacrifices interrupt \r
+               critical sections.  Therefore the alternative API sacrifices interrupt \r
                responsiveness to gain execution speed, whereas the fully featured API\r
                sacrifices execution speed to ensure better interrupt responsiveness.  */\r
 \r
@@ -528,10 +528,6 @@ xTimeOutType xTimeOut;
                                                        xReturn = queueERRONEOUS_UNBLOCK;\r
                                                }\r
                                        }\r
-                                       else\r
-                                       {\r
-                                               \r
-                                       }\r
                                }\r
                        }\r
                        while( xReturn == queueERRONEOUS_UNBLOCK );\r
@@ -552,12 +548,12 @@ xTimeOutType xTimeOut;
        xTimeOutType xTimeOut;\r
        signed portCHAR *pcOriginalReadPosition;\r
 \r
-               /* The source code that implements the light weight (fast) API is much \r
+               /* The source code that implements the alternative (Alt) API is much \r
                simpler because it executes everything from within a critical section.  \r
                This is the approach taken by many other RTOSes, but FreeRTOS.org has the \r
-               fully featured API as an alternative.  The fully featured API has more \r
+               preferred fully featured API too.  The fully featured API has more \r
                complex code that takes longer to execute, but makes much less use of \r
-               critical sections.  Therefore the light weight API sacrifices interrupt \r
+               critical sections.  Therefore the alternative API sacrifices interrupt \r
                responsiveness to gain execution speed, whereas the fully featured API\r
                sacrifices execution speed to ensure better interrupt responsiveness.  */\r
 \r