vTaskDelete() A task can use the vTaskDelete() API function to delete itself, or any other task. Note that the vTaskDelete() API function is available only when INCLUDE_vTaskDelete is set to 1 in FreeRTOSConfig.h. Deleted tasks no longer exist and cannot enter the Running state again. It is the responsibility of the idle task to free memory allocated to tasks that have since been deleted. Therefore, it is important that applications using the vTaskDelete() API function do not completely starve the idle task of all processing time . Note: Only memory allocated to a task by the kernel itself will be freed automatically when the task is deleted. Any memory or other resource that the implementation of the task allocated must be freed explicitly. void vTaskDelete( TaskHandle_t pxTaskToDelete ); pxTaskToDelete The handle of the task that is to be deleted (the subject task)—see the pxCreatedTask parameter of the xTaskCreate() API function for information on obtaining handles t...
Software timers are used to schedule the execution of a function at a set time in the future , or periodically with a fixed frequency . The function executed by the software timer is called the software timer’s callback function. Software timers are implemented by, and are under the control of, the FreeRTOS kernel. They do not require hardware support, and are not related to hardware timers or hardware counters. Note that, in line with the FreeRTOS philosophy of using innovative design to ensure maximum efficiency, software timers do not use any processing time unless a software timer callback function is actually executing . To include software timer functionality: Build the FreeRTOS source file FreeRTOS/Source/timers.c as part of your project. Set configUSE_TIMERS to 1 in FreeRTOSConfig.h. Software Timer Callback Functions void ATimerCallback( TimerHandle_t xTimer ); Software timer callback functions execute from start to finish, and exit in the normal way. They should be kept ...
Embedded real-time systems have to take actions in response to events that originate from the environment. For example, a packet arriving on an Ethernet peripheral (the event) might require passing to a TCP/IP stack for processing (the action). Non-trivial systems will have to service events that originate from multiple sources, all of which will have different processing overhead and response time requirements. In each case, a judgment has to be made as to the best event processing implementation strategy: How should the event be detected? Interrupts are normally used, but inputs can also be polled. When interrupts are used, how much processing should be performed inside the interrupt service routine (ISR), and how much outside? It is normally desirable to keep each ISR as short as possible. How events are communicated to the main (non-ISR) code, and how can this code be structured to best accommodate processing of potentially asynchronous occurrences? It is important to draw a distin...
留言
張貼留言