Update the MSVC simulator demo to demonstrate heap_5 allocator and pdTICKS_TO_MS macro being used.

pull/4/head
Richard Barry 11 years ago
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…
Cancel
Save