|
|
Component
FreeRTOS
FreeRTOS
Properties:
-
Component name - Name of the component.
-
Use Trace Facility - Set to 1 if you wish the trace visualisation functionality to be available, or 0 if the trace functionality is not going to be used. If you use the trace functionality a trace buffer must also be provided.
-
Scheduler - This group controls how the scheduler works
-
ColdFire - This group is used to configure the RTOS for the ColdFire cores
The following items are available only if the group is enabled (the value is "Enabled"):
-
CPU - Specify which ColdFire CPU is used (ColdFire only).
There are 3 options:
- MCF51CN: ColdFire V1 MCF51CN family
- MCF51JM: ColdFire V1 MCF51JM family
- MCF51QE: ColdFire V1 MCF51QE family
-
SWI - Specify which software interrupt shall be used for task switching (ColdFire only)
There are 7 options:
- VL1swi: using VL1swi
- VL2swi: using VL2swi
- VL3swi: using VL3swi
- VL4swi: using VL4swi
- VL5swi: using VL5swi
- VL6swi: using VL6swi
- VL7swi: using VL7swi
-
SWI - In order to make a context switch, the RTOS needs a SWI (software interrupt).
-
Preemptive - Set to 1 to use the preemptive kernel, or 0 to use the cooperative kernel. (configUSE_PREEMPTION flag)
-
Use Co-Routines - Set to 1 to include co-routine functionality in the build, or 0 to omit co-routine functionality from the build. To include co-routines croutine.c must be included in the project.
-
Idle should yield - This parameter controls the behaviour of tasks at the idle priority. It only has an effect if:
1. The preemptive scheduler is being used.
2. The users application creates tasks that run at the idle priority.
Tasks that share the same priority will time slice. Assuming none of the tasks get preempted, it might be assumed that each task of at a given priority will be allocated an equal amount of processing time - and if the shared priority is above the idle priority then this is indeed the case.
-
Task Name Length - The maximum permissible length of the descriptive name given to a task when the task is created. The length is specified in the number of characters including the NULL termination byte. (configMAX_TASK_NAME_LEN)
-
Minimal Stack Size - The size of the stack used by the idle task. Generally this should not be reduced from the value set in the FreeRTOSConfig.h file provided with the demo application for the port you are using. (configMINIMAL_STACK_SIZE flag)
-
Maximum Priorities - Each task is assigned a priority from 0 to ( configMAX_PRIORITIES - 1 ). configMAX_PRIORITIES is defined within FreeRTOSConfig.h and can be set on an application by application basis. The higher the value given to configMAX_PRIORITIES the more RAM the FreeRTOS kernel will consume.
-
Maximum Coroutine Priorities - Each co-routine is assigned a priority from 0 to ( configMAX_CO_ROUTINE_PRIORITIES - 1 ). configMAX_CO_ROUTINE_PRIORITIES is defined within FreeRTOSConfig.h and can be set on an application by application basis. The higher the value given to configMAX_CO_ROUTINE_PRIORITIES the more RAM the FreeRTOS kernel will consume.
-
Stackoverflow checking method - Stack Overflow Detection - Method 1
It is likely that the stack will reach its greatest (deepest) value after the kernel has swapped the task out of the Running state because this is when the stack will contain the task context. At this point the kernel can check that the processor stack pointer remains within the valid stack space. The stack overflow hook function is called if the stack pointer contain a value that is outside of the valid stack range. This method is quick but not guaranteed to catch all stack overflows. Set configCHECK_FOR_STACK_OVERFLOW to 1 to use this method only.
Stack Overflow Detection - Method 2 When a task is first created its stack is filled with a known value. When swapping a task out of the Running state the kernel can check the last 16 bytes within the valid stack range to ensure that these known values have not been overwritten by the task or interrupt activity. The stack overflow hook function is called should any of these 16 bytes not remain at their initial value. This method is less efficient than method one, but still fairly fast. It is very likely to catch stack overflows but is still not guaranteed to catch all overflows. To use this method in combination with method 1 set configCHECK_FOR_STACK_OVERFLOW to 2. It is not possible to use only this method.
There are 2 options:
- Method 1: t is likely that the stack will reach its greatest (deepest) value after the kernel has swapped the task out of the Running state because this is when the stack will contain the task context. At this point the kernel can check that the processor stack pointer remains within the valid stack space. The stack overflow hook function is called if the stack pointer contain a value that is outside of the valid stack range. This method is quick but not guaranteed to catch all stack overflows.
- Method 2: When a task is first created its stack is filled with a known value. When swapping a task out of the Running state the kernel can check the last 16 bytes within the valid stack range to ensure that these known values have not been overwritten by the task or interrupt activity. The stack overflow hook function is called should any of these 16 bytes not remain at their initial value. This method is less efficient than method one, but still fairly fast. It is very likely to catch stack overflows but is still not guaranteed to catch all overflows.
-
Cleanup Resources - This setting controlls the INCLUDE_vTaskCleanUpResources define.
-
Ticks - Group controlling how ticks are handled
-
Tick Rate (Hz) - The frequency of the RTOS tick interrupt.
The tick interrupt is used to measure time. Therefore a higher tick frequency means time can be measured to a higher resolution. However, a high tick frequency also means that the kernel will use more CPU time so be less efficient. The RTOS demo applications all use a tick rate of 1000Hz. This is used to test the kernel and is higher than would normally be required.
More than one task can share the same priority. The kernel will share processor time between tasks of the same priority by switching between the tasks during each RTOS tick. A high tick rate frequency will therefore also have the effect of reducing the 'time slice' given to each task.
-
Use 16bit ticks - Time is measured in 'ticks' - which is the number of times the tick interrupt has executed since the kernel was started. The tick count is held in a variable of type portTickType.
Defining configUSE_16_BIT_TICKS as 1 causes portTickType to be defined (typedef'ed) as an unsigned 16bit type. Defining configUSE_16_BIT_TICKS as 0 causes portTickType to be defined (typedef'ed) as an unsigned 32bit type.
Using a 16 bit type will greatly improve performance on 8 and 16 bit architectures, but limits the maximum specifiable time period to 65535 'ticks'. Therefore, assuming a tick frequency of 250Hz, the maximum time a task can delay or block when a 16bit counter is used is 262 seconds, compared to 17179869 seconds when using a 32bit counter.
-
Tick Timer - Timer generating the ticks for the RTOS
-
Semaphores - This group defines how Semaphores are handled
-
Queues - This group defines how queues are handled
-
Queue Registry Size - The queue registry has two purposes, both of which are associated with kernel aware debugging:
1. It allows a textual name to be associated with a queue for easy queue identification within a debugging GUI.
2. It contains the information required by a debugger to locate each registered queue and semaphore.
The queue registry has no purpose unless you are using a kernel aware debugger.
configQUEUE_REGISTRY_SIZE defines the maximum number of queues and semaphores that can be registered. Only those queues and semaphores that you want to view using a kernel aware debugger need be registered. See the API reference documentation for vQueueAddToRegistry() and vQueueUnregisterQueue() for more information.
-
Mutexes - This group defines how mutexes are handled
-
Use Mutexes - Set to 1 to include mutex functionality in the build, or 0 to omit mutex functionality from the build. Readers should familiarise themselves with the differences between mutexes and binary semaphores in relation to the FreeRTOS.org functionality.
-
Use Recursive Mutexes - Set to 1 to include recursive mutex functionality in the build, or 0 to omit recursive mutex functionality from the build.
-
Memory - This group controls the heap and memory settings
-
Memory Allocation Scheme - The RTOS kernel has to allocate RAM each time a task, queue or semaphore is created. The malloc() and free() functions can sometimes be used for this purpose, but ...
1. they are not always available on embedded systems, 2. take up valuable code space, 3. are not thread safe, and 4. are not deterministic (the amount of time taken to execute the function will differ from call to call) ... so more often than not an alternative scheme is required. One embedded / real time system can have very different RAM and timing requirements to another - so a single RAM allocation algorithm will only ever be appropriate for a subset of applications.
To get around this problem the memory allocation API is included in the RTOS portable layer - where an application specific implementation appropriate for the real time system being developed can be provided. When the real time kernel requires RAM, instead of calling malloc() it makes a call to pvPortMalloc(). When RAM is being freed, instead of calling free() the real time kernel makes a call to vPortFree(). Schemes included in the source code download Three sample RAM allocation schemes are included in the FreeRTOS source code download (V2.5.0 onwards). These are used by the various demo applications as appropriate. The following subsections describe the available schemes, when they should be used, and highlight the demo applications that demonstrate their use.
Each scheme is contained in a separate source file (heap_1.c, heap_2.c and heap_3.c respectively) which can be located in the Source/Portable/MemMang directory. Other schemes can be added if required.
Scheme 1 - heap_1.c This is the simplest scheme of all. It does not permit memory to be freed once it has been allocated, but despite this is suitable for a surprisingly large number of applications. The algorithm simply subdivides a single array into smaller blocks as requests for RAM are made. The total size of the array is set by the definition configTOTAL_HEAP_SIZE - which is defined in FreeRTOSConfig.h. This scheme: * Can be used if your application never deletes a task or queue (no calls to vTaskDelete() or vQueueDelete() are ever made). * Is always deterministic (always takes the same amount of time to return a block). * Is used by the PIC, AVR and 8051 demo applications - as these do not dynamically create or delete tasks after vTaskStartScheduler() has been called. heap_1.c is suitable for a lot of small real time systems provided that all tasks and queues are created before the kernel is started.
Scheme 2 - heap_2.c This scheme uses a best fit algorithm and, unlike scheme 1, allows previously allocated blocks to be freed. It does not however combine adjacent free blocks into a single large block. Again the total amount of available RAM is set by the definition configTOTAL_HEAP_SIZE - which is defined in FreeRTOSConfig.h. This scheme: * Can be used even when the application repeatedly calls vTaskCreate()/vTaskDelete() or vQueueCreate()/vQueueDelete() (causing multiple calls to pvPortMalloc() and vPortFree()). * Should not be used if the memory being allocated and freed is of a random size - this would only be the case if tasks being deleted each had a different stack depth, or queues being deleted were of different lengths. * Could possible result in memory fragmentation problems should your application create blocks of queues and tasks in an unpredictable order. This would be unlikely for nearly all applications but should be kept in mind. * Is not deterministic - but is also not particularly inefficient. * Is used by the ARM7, and Flashlite demo applications - as these dynamically create and delete tasks. heap_2.c is suitable for most small real time systems that have to dynamically create tasks.
Scheme 3 - heap_3.c This is just a wrapper for the standard malloc() and free() functions. It makes them thread safe. This scheme: * Requires the linker to setup a heap, and the compiler library to provide malloc() and free() implementations. * Is not deterministic. * Will probably considerably increase the kernel code size. * Is used by the PC (x86 single board computer) demo application.
There are 3 options:
- Scheme 1: This is the simplest scheme of all. It does not permit memory to be freed once it has been allocated, but despite this is suitable for a surprisingly large number of applications.
- Scheme 2: This scheme uses a best fit algorithm and, unlike scheme 1, allows previously allocated blocks to be freed. It does not however combine adjacent free blocks into a single large block. This scheme uses a best fit algorithm and, unlike scheme 1, allows previously allocated blocks to be freed. It does not however combine adjacent free blocks into a single large block. This scheme uses a best fit algorithm and, unlike scheme 1, allows previously allocated blocks to be freed. It does not however combine adjacent free blocks into a single large block.
- Scheme 3: This is just a wrapper for the standard malloc() and free() functions. It makes them thread safe. This is just a wrapper for the standard malloc() and free() functions. It makes them thread safe. This is just a wrapper for the standard malloc() and free() functions. It makes them thread safe.
-
Total Heap Size - The total amount of RAM available to the kernel. This value is used by the memory allocation schemes.
|