/*\r
- FreeRTOS V7.5.3 - Copyright (C) 2013 Real Time Engineers Ltd. \r
+ FreeRTOS V8.1.0 - Copyright (C) 2014 Real Time Engineers Ltd.\r
All rights reserved\r
\r
VISIT http://www.FreeRTOS.org TO ENSURE YOU ARE USING THE LATEST VERSION.\r
the terms of the GNU General Public License (version 2) as published by the\r
Free Software Foundation >>!AND MODIFIED BY!<< the FreeRTOS exception.\r
\r
- >>! NOTE: The modification to the GPL is included to allow you to distribute\r
- >>! a combined work that includes FreeRTOS without being obliged to provide\r
- >>! the source code for proprietary components outside of the FreeRTOS\r
- >>! kernel.\r
+ >>! NOTE: The modification to the GPL is included to allow you to !<<\r
+ >>! distribute a combined work that includes FreeRTOS without being !<<\r
+ >>! obliged to provide the source code for proprietary components !<<\r
+ >>! outside of the FreeRTOS kernel. !<<\r
\r
FreeRTOS is distributed in the hope that it will be useful, but WITHOUT ANY\r
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS\r
* application. It is provided as a convenient development and demonstration\r
* test bed only. This was tested using Windows XP on a dual core laptop.\r
*\r
- * In this example, one simulated millisecond will take approximately 40ms to\r
- * execute, and Windows will not be running the FreeRTOS simulator threads\r
- * continuously, so the timing information in the FreeRTOS+Trace logs have no\r
- * meaningful units. See the documentation page for the Windows simulator for\r
- * an explanation of the slow timing:\r
+ * Windows will not be running the FreeRTOS simulator threads continuously, so\r
+ * the timing information in the FreeRTOS+Trace logs have no meaningful units.\r
+ * See the documentation page for the Windows simulator for an explanation of\r
+ * the slow timing:\r
* http://www.freertos.org/FreeRTOS-Windows-Simulator-Emulator-for-Visual-Studio-and-Eclipse-MingW.html\r
* - READ THE WEB DOCUMENTATION FOR THIS PORT FOR MORE INFORMATION ON USING IT -\r
*\r
* NOTE 2: This project provides two demo applications. A simple blinky style\r
* project, and a more comprehensive test and demo application. The\r
- * mainCREATE_SIMPLE_BLINKY_DEMO_ONLY setting in main.c is used to select \r
- * between the two. See the notes on using mainCREATE_SIMPLE_BLINKY_DEMO_ONLY \r
+ * mainCREATE_SIMPLE_BLINKY_DEMO_ONLY setting in main.c is used to select\r
+ * between the two. See the notes on using mainCREATE_SIMPLE_BLINKY_DEMO_ONLY\r
* in main.c. This file implements the simply blinky style version.\r
*\r
* NOTE 3: This file only contains the source code that is specific to the\r
- * basic demo. Generic functions, such FreeRTOS hook functions, are defined \r
+ * basic demo. Generic functions, such FreeRTOS hook functions, are defined\r
* in main.c.\r
******************************************************************************\r
*\r
* The queue send task is implemented by the prvQueueSendTask() function in\r
* this file. prvQueueSendTask() sits in a loop that causes it to repeatedly\r
* block for 200 (simulated as far as the scheduler is concerned, but in\r
- * reality much longer - see notes above) milliseconds, before sending the \r
- * value 100 to the queue that was created within main_blinky(). Once the \r
- * value is sent, the task loops back around to block for another 200 \r
+ * reality much longer - see notes above) milliseconds, before sending the\r
+ * value 100 to the queue that was created within main_blinky(). Once the\r
+ * value is sent, the task loops back around to block for another 200\r
* (simulated) milliseconds.\r
*\r
* The Queue Receive Task:\r
* in this file. prvQueueReceiveTask() sits in a loop where it repeatedly\r
* blocks on attempts to read data from the queue that was created within\r
* main_blinky(). When data is received, the task checks the value of the\r
- * data, and if the value equals the expected 100, outputs a message. The \r
- * 'block time' parameter passed to the queue receive function specifies that \r
- * the task should be held in the Blocked state indefinitely to wait for data \r
+ * data, and if the value equals the expected 100, outputs a message. The\r
+ * 'block time' parameter passed to the queue receive function specifies that\r
+ * the task should be held in the Blocked state indefinitely to wait for data\r
* to be available on the queue. The queue receive task will only leave the\r
* Blocked state when the queue send task writes to the queue. As the queue\r
- * send task writes to the queue every 200 (simulated - see notes above) \r
- * milliseconds, the queue receive task leaves the Blocked state every 200 \r
+ * send task writes to the queue every 200 (simulated - see notes above)\r
+ * milliseconds, the queue receive task leaves the Blocked state every 200\r
* milliseconds, and therefore outputs a message every 200 milliseconds.\r
*/\r
\r
#define mainQUEUE_SEND_TASK_PRIORITY ( tskIDLE_PRIORITY + 1 )\r
\r
/* The rate at which data is sent to the queue. The 200ms value is converted\r
-to ticks using the portTICK_RATE_MS constant. */\r
-#define mainQUEUE_SEND_FREQUENCY_MS ( 200 / portTICK_RATE_MS )\r
+to ticks using the portTICK_PERIOD_MS constant. */\r
+#define mainQUEUE_SEND_FREQUENCY_MS ( 200 )\r
\r
/* The number of items the queue can hold. This is 1 as the receive task\r
will remove items as they are added, meaning the send task should always find\r
/*-----------------------------------------------------------*/\r
\r
/* The queue used by both tasks. */\r
-static xQueueHandle xQueue = NULL;\r
+static QueueHandle_t xQueue = NULL;\r
\r
/*-----------------------------------------------------------*/\r
\r
/* Start the two tasks as described in the comments at the top of this\r
file. */\r
xTaskCreate( prvQueueReceiveTask, /* The function that implements the task. */\r
- ( signed char * ) "Rx", /* The text name assigned to the task - for debug only as it is not used by the kernel. */\r
+ "Rx", /* The text name assigned to the task - for debug only as it is not used by the kernel. */\r
configMINIMAL_STACK_SIZE, /* The size of the stack to allocate to the task. */\r
( void * ) mainQUEUE_RECEIVE_PARAMETER, /* The parameter passed to the task - just to check the functionality. */\r
mainQUEUE_RECEIVE_TASK_PRIORITY, /* The priority assigned to the task. */\r
NULL ); /* The task handle is not required, so NULL is passed. */\r
\r
- xTaskCreate( prvQueueSendTask, ( signed char * ) "TX", configMINIMAL_STACK_SIZE, ( void * ) mainQUEUE_SEND_PARAMETER, mainQUEUE_SEND_TASK_PRIORITY, NULL );\r
+ xTaskCreate( prvQueueSendTask, "TX", configMINIMAL_STACK_SIZE, ( void * ) mainQUEUE_SEND_PARAMETER, mainQUEUE_SEND_TASK_PRIORITY, NULL );\r
\r
/* Start the tasks and timer running. */\r
vTaskStartScheduler();\r
\r
static void prvQueueSendTask( void *pvParameters )\r
{\r
-portTickType xNextWakeTime;\r
+TickType_t xNextWakeTime;\r
const unsigned long ulValueToSend = 100UL;\r
+const TickType_t xBlockTime = pdMS_TO_TICKS( mainQUEUE_SEND_FREQUENCY_MS );\r
+\r
+ /* Remove compiler warning in the case that configASSERT() is not\r
+ defined. */\r
+ ( void ) pvParameters;\r
\r
/* Check the task parameter is as expected. */\r
configASSERT( ( ( unsigned long ) pvParameters ) == mainQUEUE_SEND_PARAMETER );\r
The block time is specified in ticks, the constant used converts ticks\r
to ms. While in the Blocked state this task will not consume any CPU\r
time. */\r
- vTaskDelayUntil( &xNextWakeTime, mainQUEUE_SEND_FREQUENCY_MS );\r
+ vTaskDelayUntil( &xNextWakeTime, xBlockTime );\r
\r
/* Send to the queue - causing the queue receive task to unblock and\r
toggle the LED. 0 is used as the block time so the sending operation\r
{\r
unsigned long ulReceivedValue;\r
\r
+ /* Remove compiler warning in the case that configASSERT() is not\r
+ defined. */\r
+ ( void ) pvParameters;\r
+\r
/* Check the task parameter is as expected. */\r
configASSERT( ( ( unsigned long ) pvParameters ) == mainQUEUE_RECEIVE_PARAMETER );\r
\r
projects / freertos / blobdiff