mirror of
https://github.com/FreeRTOS/FreeRTOS-Kernel.git
synced 2025-04-19 21:11:57 -04:00
Update the MSVC simulator demo to demonstrate heap_5 allocator and pdTICKS_TO_MS macro being used.
This commit is contained in:
parent
d96dc2adb0
commit
4fe2abc792
|
@ -83,7 +83,7 @@
|
|||
#define configUSE_TICK_HOOK 1
|
||||
#define configTICK_RATE_HZ ( 1000 ) /* In this non-real time simulated environment the tick frequency has to be at least a multiple of the Win32 tick frequency, and therefore very slow. */
|
||||
#define configMINIMAL_STACK_SIZE ( ( unsigned short ) 50 ) /* In this simulated case, the stack only has to hold one small structure as the real stack is part of the win32 thread. */
|
||||
#define configTOTAL_HEAP_SIZE ( ( size_t ) ( 20 * 1024 ) )
|
||||
#define configTOTAL_HEAP_SIZE ( ( size_t ) ( 21 * 1024 ) )
|
||||
#define configMAX_TASK_NAME_LEN ( 12 )
|
||||
#define configUSE_TRACE_FACILITY 1
|
||||
#define configUSE_16_BIT_TICKS 0
|
||||
|
|
|
@ -132,7 +132,7 @@
|
|||
<ClCompile Include="..\..\..\FreeRTOS-Plus\Source\FreeRTOS-Plus-Trace\trcUser.c" />
|
||||
<ClCompile Include="..\..\Source\croutine.c" />
|
||||
<ClCompile Include="..\..\Source\event_groups.c" />
|
||||
<ClCompile Include="..\..\Source\portable\MemMang\heap_4.c" />
|
||||
<ClCompile Include="..\..\Source\portable\MemMang\heap_5.c" />
|
||||
<ClCompile Include="..\..\Source\timers.c" />
|
||||
<ClCompile Include="..\Common\Minimal\BlockQ.c" />
|
||||
<ClCompile Include="..\Common\Minimal\blocktim.c" />
|
||||
|
|
|
@ -100,9 +100,6 @@
|
|||
<ClCompile Include="Run-time-stats-utils.c">
|
||||
<Filter>Demo App Source</Filter>
|
||||
</ClCompile>
|
||||
<ClCompile Include="..\..\Source\portable\MemMang\heap_4.c">
|
||||
<Filter>FreeRTOS Source\Source\Portable</Filter>
|
||||
</ClCompile>
|
||||
<ClCompile Include="..\..\Source\croutine.c">
|
||||
<Filter>FreeRTOS Source\Source</Filter>
|
||||
</ClCompile>
|
||||
|
@ -136,6 +133,9 @@
|
|||
<ClCompile Include="..\..\Source\event_groups.c">
|
||||
<Filter>FreeRTOS Source\Source</Filter>
|
||||
</ClCompile>
|
||||
<ClCompile Include="..\..\Source\portable\MemMang\heap_5.c">
|
||||
<Filter>FreeRTOS Source\Source\Portable</Filter>
|
||||
</ClCompile>
|
||||
</ItemGroup>
|
||||
<ItemGroup>
|
||||
<ClInclude Include="FreeRTOSConfig.h">
|
||||
|
@ -171,9 +171,6 @@
|
|||
<ClInclude Include="..\..\Source\include\timers.h">
|
||||
<Filter>FreeRTOS Source\Include</Filter>
|
||||
</ClInclude>
|
||||
<ClInclude Include="Trace_Recorder_Configuration\trcHardwarePort.h">
|
||||
<Filter>Configuration Files</Filter>
|
||||
</ClInclude>
|
||||
<ClInclude Include="Trace_Recorder_Configuration\trcConfig.h">
|
||||
<Filter>Configuration Files</Filter>
|
||||
</ClInclude>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
/*
|
||||
FreeRTOS V8.0.1 - Copyright (C) 2014 Real Time Engineers Ltd.
|
||||
FreeRTOS V8.0.1 - Copyright (C) 2014 Real Time Engineers Ltd.
|
||||
All rights reserved
|
||||
|
||||
VISIT http://www.FreeRTOS.org TO ENSURE YOU ARE USING THE LATEST VERSION.
|
||||
|
@ -66,9 +66,9 @@
|
|||
/******************************************************************************
|
||||
* This project provides two demo applications. A simple blinky style project,
|
||||
* and a more comprehensive test and demo application. The
|
||||
* mainCREATE_SIMPLE_BLINKY_DEMO_ONLY setting is used to select between the two.
|
||||
* The simply blinky demo is implemented and described in main_blinky.c. The
|
||||
* more comprehensive test and demo application is implemented and described in
|
||||
* mainCREATE_SIMPLE_BLINKY_DEMO_ONLY setting is used to select between the two.
|
||||
* The simply blinky demo is implemented and described in main_blinky.c. The
|
||||
* more comprehensive test and demo application is implemented and described in
|
||||
* main_full.c.
|
||||
*
|
||||
* This file implements the code that is not demo specific, including the
|
||||
|
@ -80,9 +80,9 @@
|
|||
* application. It is provided as a convenient development and demonstration
|
||||
* test bed only. This was tested using Windows XP on a dual core laptop.
|
||||
*
|
||||
* Windows will not be running the FreeRTOS simulator threads continuously, so
|
||||
* the timing information in the FreeRTOS+Trace logs have no meaningful units.
|
||||
* See the documentation page for the Windows simulator for an explanation of
|
||||
* Windows will not be running the FreeRTOS simulator threads continuously, so
|
||||
* the timing information in the FreeRTOS+Trace logs have no meaningful units.
|
||||
* See the documentation page for the Windows simulator for an explanation of
|
||||
* the slow timing:
|
||||
* http://www.freertos.org/FreeRTOS-Windows-Simulator-Emulator-for-Visual-Studio-and-Eclipse-MingW.html
|
||||
* - READ THE WEB DOCUMENTATION FOR THIS PORT FOR MORE INFORMATION ON USING IT -
|
||||
|
@ -101,12 +101,21 @@
|
|||
|
||||
/* This project provides two demo applications. A simple blinky style project,
|
||||
and a more comprehensive test and demo application. The
|
||||
mainCREATE_SIMPLE_BLINKY_DEMO_ONLY setting is used to select between the two.
|
||||
The simply blinky demo is implemented and described in main_blinky.c. The more
|
||||
comprehensive test and demo application is implemented and described in
|
||||
mainCREATE_SIMPLE_BLINKY_DEMO_ONLY setting is used to select between the two.
|
||||
The simply blinky demo is implemented and described in main_blinky.c. The more
|
||||
comprehensive test and demo application is implemented and described in
|
||||
main_full.c. */
|
||||
#define mainCREATE_SIMPLE_BLINKY_DEMO_ONLY 0
|
||||
|
||||
/* This demo uses heap_5.c, and these constants define the sizes of the regions
|
||||
that make up the total heap. This is only done to provide an example of heap_5
|
||||
being used as this demo could easily create one large heap region instead of
|
||||
multiple smaller heap regions - in which case heap_4.c would be the more
|
||||
appropriate choice. */
|
||||
#define mainREGION_1_SIZE 2001
|
||||
#define mainREGION_2_SIZE 18005
|
||||
#define mainREGION_3_SIZE 1007
|
||||
|
||||
/*
|
||||
* main_blinky() is used when mainCREATE_SIMPLE_BLINKY_DEMO_ONLY is set to 1.
|
||||
* main_full() is used when mainCREATE_SIMPLE_BLINKY_DEMO_ONLY is set to 0.
|
||||
|
@ -114,15 +123,28 @@ main_full.c. */
|
|||
extern void main_blinky( void );
|
||||
extern void main_full( void );
|
||||
|
||||
/* Some of the RTOS hook (callback) functions only need special processing when
|
||||
the full demo is being used. The simply blinky demo has no special requirements,
|
||||
so these functions are called from the hook functions defined in this file, but
|
||||
are defined in main_full.c. */
|
||||
/*
|
||||
* Some of the RTOS hook (callback) functions only need special processing when
|
||||
* the full demo is being used. The simply blinky demo has no special
|
||||
* requirements, so these functions are called from the hook functions defined
|
||||
* in this file, but are defined in main_full.c.
|
||||
*/
|
||||
void vFullDemoTickHookFunction( void );
|
||||
void vFullDemoIdleFunction( void );
|
||||
|
||||
/* Prototypes for the standard FreeRTOS callback/hook functions implemented
|
||||
within this file. */
|
||||
/*
|
||||
* This demo uses heap_5.c, so start by defining some heap regions. This is
|
||||
* only done to provide an example as this demo could easily create one large
|
||||
* heap region instead of multiple smaller heap regions - in which case heap_4.c
|
||||
* would be the more appropriate choice. No initialisation is required when
|
||||
* heap_4.c is used.
|
||||
*/
|
||||
static void prvInitialiseHeap( void );
|
||||
|
||||
/*
|
||||
* Prototypes for the standard FreeRTOS callback/hook functions implemented
|
||||
* within this file.
|
||||
*/
|
||||
void vApplicationMallocFailedHook( void );
|
||||
void vApplicationIdleHook( void );
|
||||
void vApplicationStackOverflowHook( TaskHandle_t pxTask, char *pcTaskName );
|
||||
|
@ -145,6 +167,13 @@ static portBASE_TYPE xTraceRunning = pdTRUE;
|
|||
|
||||
int main( void )
|
||||
{
|
||||
/* This demo uses heap_5.c, so start by defining some heap regions. This
|
||||
is only done to provide an example as this demo could easily create one
|
||||
large heap region instead of multiple smaller heap regions - in which case
|
||||
heap_4.c would be the more appropriate choice. No initialisation is
|
||||
required when heap_4.c is used. */
|
||||
prvInitialiseHeap();
|
||||
|
||||
/* Initialise the trace recorder and create the label used to post user
|
||||
events to the trace recording on each tick interrupt. */
|
||||
vTraceInitTraceData();
|
||||
|
@ -199,10 +228,10 @@ void vApplicationIdleHook( void )
|
|||
function, because it is the responsibility of the idle task to clean up
|
||||
memory allocated by the kernel to any task that has since been deleted. */
|
||||
|
||||
/* Uncomment the following code to allow the trace to be stopped with any
|
||||
/* Uncomment the following code to allow the trace to be stopped with any
|
||||
key press. The code is commented out by default as the kbhit() function
|
||||
interferes with the run time behaviour. */
|
||||
/*
|
||||
/*
|
||||
if( _kbhit() != pdFALSE )
|
||||
{
|
||||
if( xTraceRunning == pdTRUE )
|
||||
|
@ -250,10 +279,10 @@ void vApplicationTickHook( void )
|
|||
}
|
||||
#endif /* mainCREATE_SIMPLE_BLINKY_DEMO_ONLY */
|
||||
|
||||
/* Write a user event to the trace log.
|
||||
/* Write a user event to the trace log.
|
||||
Note tick events will not appear in the trace recording with regular period
|
||||
because this project runs in a Windows simulator, and does not therefore
|
||||
exhibit deterministic behaviour. Windows will run the simulator in
|
||||
exhibit deterministic behaviour. Windows will run the simulator in
|
||||
bursts. */
|
||||
vTraceUserEvent( xTickTraceUserEvent );
|
||||
}
|
||||
|
@ -311,3 +340,33 @@ FILE* pxOutputFile;
|
|||
printf( "\r\nFailed to create trace dump file\r\n" );
|
||||
}
|
||||
}
|
||||
/*-----------------------------------------------------------*/
|
||||
|
||||
static void prvInitialiseHeap( void )
|
||||
{
|
||||
/* This demo uses heap_5.c, so start by defining some heap regions. This is
|
||||
only done to provide an example as this demo could easily create one large heap
|
||||
region instead of multiple smaller heap regions - in which case heap_4.c would
|
||||
be the more appropriate choice. No initialisation is required when heap_4.c is
|
||||
used. The xHeapRegions structure requires the regions to be defined in order,
|
||||
so this just creates one big array, then populates the structure with offsets
|
||||
into the array - with gaps in between and messy alignment just for test
|
||||
purposes. */
|
||||
static uint8_t ucHeap[ configTOTAL_HEAP_SIZE ];
|
||||
volatile uint32_t ulAdditionalOffset = 19; /* Just to prevent 'condition is always true' warnings in configASSERT(). */
|
||||
const HeapRegion_t xHeapRegions[] =
|
||||
{
|
||||
/* Start address with dummy offsets Size */
|
||||
{ ucHeap + 1, mainREGION_1_SIZE },
|
||||
{ ucHeap + 15 + mainREGION_1_SIZE, mainREGION_2_SIZE },
|
||||
{ ucHeap + 19 + mainREGION_1_SIZE + mainREGION_2_SIZE, mainREGION_3_SIZE },
|
||||
{ NULL, 0 }
|
||||
};
|
||||
|
||||
/* Sanity check that the sizes and offsets defined actually fit into the
|
||||
array. */
|
||||
configASSERT( ( ulAdditionalOffset + mainREGION_1_SIZE + mainREGION_2_SIZE + mainREGION_3_SIZE ) < configTOTAL_HEAP_SIZE );
|
||||
|
||||
vPortDefineHeapRegions( xHeapRegions );
|
||||
}
|
||||
|
||||
|
|
|
@ -128,7 +128,7 @@
|
|||
|
||||
/* The rate at which data is sent to the queue. The 200ms value is converted
|
||||
to ticks using the portTICK_PERIOD_MS constant. */
|
||||
#define mainQUEUE_SEND_FREQUENCY_MS ( 200 / portTICK_PERIOD_MS )
|
||||
#define mainQUEUE_SEND_FREQUENCY_MS ( 200 )
|
||||
|
||||
/* The number of items the queue can hold. This is 1 as the receive task
|
||||
will remove items as they are added, meaning the send task should always find
|
||||
|
@ -190,6 +190,7 @@ static void prvQueueSendTask( void *pvParameters )
|
|||
{
|
||||
TickType_t xNextWakeTime;
|
||||
const unsigned long ulValueToSend = 100UL;
|
||||
const TickType_t xBlockTime = pdMS_TO_TICKS( mainQUEUE_SEND_FREQUENCY_MS );
|
||||
|
||||
/* Remove compiler warning in the case that configASSERT() is not
|
||||
defined. */
|
||||
|
@ -207,7 +208,7 @@ const unsigned long ulValueToSend = 100UL;
|
|||
The block time is specified in ticks, the constant used converts ticks
|
||||
to ms. While in the Blocked state this task will not consume any CPU
|
||||
time. */
|
||||
vTaskDelayUntil( &xNextWakeTime, mainQUEUE_SEND_FREQUENCY_MS );
|
||||
vTaskDelayUntil( &xNextWakeTime, xBlockTime );
|
||||
|
||||
/* Send to the queue - causing the queue receive task to unblock and
|
||||
toggle the LED. 0 is used as the block time so the sending operation
|
||||
|
|
Loading…
Reference in a new issue