Đề cương hệ điều hành nhúng

29-03-2017 INTRODUCE TO BASIC REAL-TIME APPLICATIONS AND RTOS Learning Goals • Introduce about the real-time and its application • Introduce about most important parts in the real-time operating system including kernel, tasks, processes, scheduler, non-preemptive/preemptive kernel • Introduce basic concepts on how to synchronize among tasks in RTOS 29-03-2017 Table of contents ❖ What is Real-Time ❖ Introduce on Real-Time Operating System – RTOS o RTOS Kernel o RTOS Tasks and Processes o RTOS Scheduler o RTOS Non-Preemptive Kernel and Preemptive Kernel ❖ Synchronization in RTOS o Semaphore o Event o Message Mailboxes o Message Queue ❖ Summary Table of contents ❖ What is Real-Time ❖ Introduce on Real-Time Operating System – RTOS o RTOS Kernel o RTOS Tasks and Processes o RTOS Scheduler o RTOS Non-Preemptive Kernel and Preemptive Kernel ❖ Synchronization in RTOS o Semaphore o Event o Message Mailboxes o Message Queue ❖ Summary 29-03-2017 Real-Time Applications ➢ Process control: – Food processing – Chemical plants ➢ Automotive: – Engine controls – Anti-lock braking systems ➢ Office automation: – FAX machines – Copiers ➢ Computer peripherals: – – – – ➢ Robots ➢ Aerospace: – Flight management systems – Weapons systems – Jet engine controls ➢ Domestic: – – – – Microwave ovens Dishwashers Washing machines Thermostats Printers Terminals Scanners Modems What is Real-Time • If a task must be completed within a given time, it is said to be a real-time task • The correct result of a real time system depends on: – a correct answer/reaction to a stimuli – a point of time, when the result will be delivered cost • Type of real time systems • hard real time • soft real time deadline time 29-03-2017 Features of real-time systems   Most real-time systems not provide the features found in a standard desktop system Reasons include ✓ Real-time systems are typically single-purpose ✓ Real-time systems often not require interfacing with a user ✓ Features found in a desktop PC require more substantial hardware than what is typically available in a real-time system Hard Real-Time System  Timing is critical and deadline cannot be missed ✓ If the failure to meet the deadline is considered to be a fatal fault  Examples: ✓ Nuclear reactors ✓ Flight controller ✓ Air bag deployment ✓ Anti-lock brakes 29-03-2017 Soft Real-Time System   A miss of timing constraints is undesirable However, a few misses not serious harm ✓ The timing requirements are often specified in probability terms ✓ The time constraints are guaranteed on a statistical basis Examples: ✓ Multimedia Streaming ✓ Electronic games ✓ Quality-of-Service (QoS) guarantees ✓ Automatic teller machine (ATM) ▪ If the ATM takes 30 seconds longer than the ideal, the user still won’t walk away Real Time Operating Systems • A real-time operating system manages the time of a microprocessor or microcontroller – Features of an RTOS:  Allows multi-tasking  Scheduling of the tasks with priorities  Synchronization of the resource access  Inter-task communication  Time predictable  Interrupt handling 10 29-03-2017 Why we need the real-time operating system (RTOS) ? Table of contents ❖ What is Real-Time ❖ Introduce on Real-Time Operating System – RTOS o RTOS Kernel o RTOS Tasks and Processes o RTOS Scheduler o RTOS Non-Preemptive Kernel and Preemptive Kernel ❖ Synchronization in RTOS o Semaphore o Event o Message Mailboxes o Message Queue ❖ Summary 29-03-2017 Real-Time application by Using State Machines   Normally, we can design and implement a embedded application/ by using a simple state machines State machines are simple constructs used to perform several activities, usually in a sequence State machine implementation Real-Time application by Using State Machines State machine implementation in C 29-03-2017 Real-Time application by Using State Machines Selecting the next state from the current state Real-Time application by Using State Machines   State machines, although easy to implement, are primitive and have limited application They can only be used in systems which are not truly responsive, where the task activities are well-defined and the tasks are not prioritized Moreover, some tasks may be more important than others We may want some tasks to run whenever they become eligible This kind of implementation of tasks requires a sophisticated system like Embedded OS – RTOS 29-03-2017 Embedded Operating Systems ► Fusion of the application and the OS to one unit ► Characteristics • Resource management ▪ User Primary internal resources • Less overhead • Code of the OS and the application mostly reside in ROM Operating System + Application HARDWARE Real-Time Operating System – RTOS • An RTOS will typically use specialized scheduling algorithms in order to provide the real-time developer with the tools necessary to produce deterministic behavior in the final system • An RTOS is valued more for how quickly and/or predictably it can respond to a particular event than for the amount of work it can perform over a given period of time • Key factors in an RTOS are therefore a minimal interrupt latency and a minimal thread switching latency 29-03-2017 Why use an RTOS? • Plan to use drivers that are available with an RTOS • Would like to spend your time developing application code and not creating or maintaining a scheduling system • Multi-thread support with synchronization • Portability of application code to other CPUs • • Resource handling Add new features without affecting higher priority functions • Support for upper layer protocols such as:  TCP/IP, USB, Flash Systems, Web Servers,  CAN protocols, Embedded GUI, SSL, SNMP 19 RTOS Design Philosophies • • Two basic designs exist: • Event-driven (priority scheduling) designs switch tasks only when an event of higher priority needs service, called pre-emptive priority • Time-sharing designs switch tasks on a clock interrupt, and on events, called round robin (Cooperative scheduling) Time-sharing designs switch tasks more often than is strictly needed, but give smoother, more deterministic multitasking, giving the illusion that a process or user has sole use of a machine Newer RTOSes almost invariably implement time-sharing scheduling with priority driven pre-emptive scheduling 10 www.FreeRTOS.org This document was supplied to jmclurkin@rice.edu A file called main.c is included in each project This contains the main() function, from where all the demo application tasks are created See the comments within the individual main.c files for more information on what a specific demo application does Removing Unused Demo Files When using a provided demo application: • All the sub-directories under FreeRTOS\Demo can be deleted, except the directory containing the demo being used and FreeRTOS\Demo\Common • FreeRTOS\Demo\Common contains many more files than are referenced from any one demo application, so this directory can be trimmed down, if desired Inspect the demo application makefile or project file to identify files that can be deleted In general, FreeRTOS\Demo\Common\Minimal should not be deleted The FreeRTOS\Demo directories that must remain are shown in Figure 46 FreeRTOS | +-Demo | +-[Demo] | +-Common Contains all the demo application source and projects Contains the makefile or project for the demo being built Contains files common to all demo applications Figure 46 The demo directories required to build a demo application 182 www.FreeRTOS.org 8.4 This document was supplied to jmclurkin@rice.edu Creating a FreeRTOS Project Adapting One of the Supplied Demo Projects Every official FreeRTOS port comes with at least one pre-configured demo application that should build with no errors or warnings It is recommended that new projects are created by adapting one of these existing projects; this will allow the project to have the correct files included and the correct compiler options set To start a new application from an existing demo project: Open the supplied demo project and ensure that it builds and executes as expected Remove the source files that define the demo tasks Any file that is located within the Demo\Common directory tree can be removed Delete all the functions within main.c, except prvSetupHardware() Ensure that the following constants are all set to within FreeRTOSConfig.h This will prevent the linker from looking for any hook functions Hook functions can be added later, if required • configUSE_IDLE_HOOK • configUSE_TICK_HOOK • configUSE_MALLOC_FAILED_HOOK • configCHECK_FOR_STACK_OVERFLOW Create a new main() function from the template shown in Listing 92 Check that the project still builds Following these steps will create a project that includes the correct FreeRTOS source files but does not define any functionality 183 www.FreeRTOS.org This document was supplied to jmclurkin@rice.edu int main( void ) { /* Perform any hardware setup necessary */ prvSetupHardware(); /* - APPLICATION TASKS CAN BE CREATED HERE - */ /* Start the created tasks running */ vTaskStartScheduler(); /* Execution will only reach here if there was insufficient heap to start the scheduler */ for( ;; ); return 0; } Listing 92 The template for a new main() function Creating a New Project from Scratch As already mentioned, it is recommended that new projects are created from an existing demo project If this is not desirable, then a new project can be created using the following procedure: Create a new empty project file or makefile using your chosen tool chain Add the files detailed in Table 29 to the newly created project or makefile Copy an existing FreeRTOSConfig.h file into the project directory Add the following directories to the path the project will search to locate header files: • FreeRTOS\Source\include • FreeRTOS\Source\portable\[compiler]\ARM_CM3 (where [compiler] is RVDS, IAR, or GCC) Copy the compiler settings from the relevant demo project or makefile 184 www.FreeRTOS.org This document was supplied to jmclurkin@rice.edu Table 29 FreeRTOS source files to include in the project File Location tasks.c FreeRTOS\Source queue.c FreeRTOS\Source list.c FreeRTOS\Source port.c FreeRTOS\Source\portable\[compiler]\ARM_CM3 port_asm.s FreeRTOS\Source\portable\[compiler]\ARM_CM3 An assembly file is not required when using GCC heap_n.c FreeRTOS\Source\portable\MemMang, where n is either 1, or Header Files A source file that uses the FreeRTOS API must include ‘FreeRTOS.h’, followed by the header file that contains the prototype for the API function being used—either ‘task.h’, ‘queue.h’, or ‘semphr.h’ 185 www.FreeRTOS.org 8.5 This document was supplied to jmclurkin@rice.edu Data Types and Coding Style Guide Data Types Each port of FreeRTOS has a unique portmacro.h header file that contains (amongst other things) definitions for two special data types, portTickType and portBASE_TYPE These data types are described in Table 30 Table 30 Special data types used by FreeRTOS Macro or typedef used portTickType Actual type This is used to store the tick count value and to specify block times portTickType can be either an unsigned 16-bit type or an unsigned 32-bit type, depending on the setting of configUSE_16_BIT_TICKS within FreeRTOSConfig.h Using a 16-bit type can greatly improve efficiency on 8-bit and 16-bit architectures, but severely limits the maximum block period that can be specified There is no reason to use a 16-bit type on a 32-bit architecture, so configUSE_16_BIT_TICKS should be set to portBASE_TYPE This is always defined as the most efficient data type for the architecture Typically, this is a 32-bit type on a 32-bit architecture, a 16-bit type on a 16-bit architecture, and an 8-bit type on an 8-bit architecture portBASE_TYPE is generally used for return types that can take only a very limited range of values, and for Booleans Cortex-M3 ports define portBASE_TYPE as type ‘long’ Some compilers make all unqualified char variables unsigned, while others make them signed For this reason, the FreeRTOS source code explicitly qualifies every use of char with either ‘signed’ or ‘unsigned’ Plain int types are never used—only long and short 186 www.FreeRTOS.org This document was supplied to jmclurkin@rice.edu Variable Names Variables are prefixed with their type: ‘c’ for char, ‘s’ for short, ‘l’ for long, and ‘x’ for portBASE_TYPE and any other type (structures, task handles, queue handles, etc.) If a variable is unsigned, it is also prefixed with a ‘u’ If a variable is a pointer, it is also prefixed with a ‘p’ Therefore, a variable of type unsigned char will be prefixed with ‘uc’, and a variable of type pointer to char will be prefixed with ‘pc’ Function Names Functions are prefixed with both the type they return and the file they are defined within For example: • vTaskPrioritySet() returns a void and is defined within task.c • xQueueReceive() returns a variable of type portBASE_TYPE and is defined within queue.c • vSemaphoreCreateBinary() returns a void and is defined within semphr.h File scope (private) functions are prefixed with ‘prv’ Formatting One tab is always set to equal four spaces Macro Names Most macros are written in upper case and prefixed with lower case letters that indicate where the macro is defined Table 31 provides a list of prefixes 187 www.FreeRTOS.org This document was supplied to jmclurkin@rice.edu Table 31 Macro prefixes Prefix Location of macro definition port (for example, portMAX_DELAY) portable.h task (for example, taskENTER_CRITICAL()) task.h pd (for example, pdTRUE) projdefs.h config (for example, configUSE_PREEMPTION) FreeRTOSConfig.h err (for example, errQUEUE_FULL) projdefs.h Note that the semaphore API is written almost entirely as a set of macros, but follows the function naming convention, rather than the macro naming convention The macros defined in Table 32 are used throughout the FreeRTOS source code Table 32 Common macro definitions Macro Value pdTRUE pdFALSE pdPASS pdFAIL Rationale for Excessive Type Casting The FreeRTOS source code can be compiled with many different compilers, all of which differ in how and when they generate warnings In particular, different compilers want casting to be used in different ways As a result, the FreeRTOS source code contains more type casting than would normally be warranted 188 www.FreeRTOS.org This document was supplied to jmclurkin@rice.edu Appendix 1: Licensing Information FreeRTOS is licensed under a modified version of the GNU General Public License (GPL) and can be used in commercial applications under that license An alternative and optional commercial license is also available if: • You cannot fulfill the requirements stated in the ’Open source modified GPL license’ column of Table 33 • You wish to receive direct technical support • You wish to have assistance with your development • You require guarantees and indemnification 189 www.FreeRTOS.org This document was supplied to jmclurkin@rice.edu Table 33 Comparing the open source license with the commercial license Open source modified GPL license Commercial license Is it free? Yes No Can I use it in a commercial application? Yes Yes Is it royalty free? Yes Yes Do I have to open source my application code? No No Do I have to open source my changes to the Yes No Yes No Yes (a WEB link to the No FreeRTOS kernel? Do I have to document that my product uses FreeRTOS Do I have to offer to provide the FreeRTOS source code to users of my application? FreeRTOS.org site is normally sufficient) Can I receive support on a commercial basis? No Yes Are any legal guarantees provided? No Yes Open Source License Details The FreeRTOS source code is licensed under version of the GNU General Public License (GPL) with an exception The full text of the GPL is available at http://www.freertos.org/license.txt The text of the exception is provided below The exception permits the source code of applications that use FreeRTOS solely through the API published on the FreeRTOS.org website to remain closed source, thus permitting the use of FreeRTOS in commercial applications without necessitating that the entire application be open sourced The exception can be used only if you wish to combine FreeRTOS with a proprietary product and you comply with the terms stated in the exception itself 190 www.FreeRTOS.org This document was supplied to jmclurkin@rice.edu GPL Exception Text Note that the exception text is subject to change Consult the FreeRTOS.org website for the most recent version Clause Linking FreeRTOS statically or dynamically with other modules is making a combined work based on FreeRTOS Thus, the terms and conditions of the GNU General Public License cover the whole combination As a special exception, the copyright holder of FreeRTOS gives you permission to link FreeRTOS with independent modules that communicate with FreeRTOS solely through the FreeRTOS API interface, regardless of the license terms of these independent modules, and to copy and distribute the resulting combined work under terms of your choice, provided that: Every copy of the combined work is accompanied by a written statement that details to the recipient the version of FreeRTOS used and an offer by yourself to provide the FreeRTOS source code (including any modifications you may have made) should the recipient request it The combined work is not itself an RTOS, scheduler, kernel or related product The independent modules add significant and primary functionality to FreeRTOS and not merely extend the existing functionality already present in FreeRTOS An independent module is a module which is not derived from or based on FreeRTOS Clause FreeRTOS may not be used for any competitive or comparative purpose, including the publication of any form of run time or compile time metric, without the express permission of Real Time Engineers ltd (this is the norm within the industry and is intended to ensure information accuracy) 191 www.FreeRTOS.org 192 This document was supplied to jmclurkin@rice.edu www.FreeRTOS.org This document was supplied to jmclurkin@rice.edu INDEX A Access Permissions, 157 atomic, 117 B background background processing, 37 best fit, 143 Binary Semaphore, 84 Blocked State, 26 Blocking on Queue Reads, 57 Blocking on Queue Writes, 58 C C library functions, 148 CMSIS, 110 configCHECK_FOR_STACK_OVERFLOW, 150 configKERNEL_INTERRUPT_PRIORITY, 111 configMAX_PRIORITIES, 15, 22 configMAX_SYSCALL_INTERRUPT_PRIORITY, 111 configMINIMAL_STACK_DEPTH, 14 configTICK_RATE_HZ, 22 configTOTAL_HEAP_SIZE, 142 configUSE_IDLE_HOOK, 39 continuous processing, 34 continuous processing task, 26 co-operative scheduling, 52 Counting Semaphores, 96 Creating Tasks, 13 critical regions, 120 critical section, 112 Critical sections, 120 D Data Types, 186 Deadlock, 131 Deadly Embrace, 131 deferred interrupts, 84 Deleting a Task, 46 E errQUEUE_FULL, 63 event driven, 26 events, 82 Events, 82 F FDA 510(K), fixed execution period, 32 Fixed Priority Pre-emptive Scheduling, 50 Formatting, 187 free(), 140 FreeRTOS-MPU, 156 FromISR, 82 Function Names, 187 Function Reentrancy, 117 G Gatekeeper tasks, 133 H handler tasks, 84 Hard real time, Heap_1, 142 Heap_2, 143 Heap_3, 145 high water mark, 149 highest priority, 15 I Idle Task, 37 Idle Task Hook, 37 IEC 61508, IEC 62304, Interrupt Nesting, 110 interrupt priority, 110 L locking the scheduler, 121 low power mode, 37 lowest priority, 15, 22 M Macro Names, 187 malloc(), 140 Measuring the amount of spare processing capacity, 37 Memory Protection Unit, 156 MPU, 156 Mutex, 124 mutual exclusion, 118 N non-atomic, 117 Not Running state, 12 O OpenRTOS, Overlapping Regions, 159 193 www.FreeRTOS.org P periodic periodic tasks, 28 periodic interrupt, 22 portable layer, 180 portBASE_TYPE, 186 portEND_SWITCHING_ISR(), 92 portMAX_DELAY, 62, 65 portSWITCH_TO_USER_MODE(), 170 portTICK_RATE_MS, 22, 29 portTickType, 186 pre-empted pre-emption, 37 Pre-emptive Pre-emptive scheduling, 50 Prioritized Pre-emptive Scheduling, 50 priority, 15, 22 priority inheritance, 130 priority inversion, 129 Privileged Mode, 157 pvParameters, 14 pvPortMalloc(), 140 Q queue access by Multiple Tasks, 57 queue block time, 57 queue item size, 57 queue length, 57 Queues, 55 R RAM allocation, 140 Read, Modify, Write Operations, 116 Ready state, 27 reentrant, 117 Removing Unused Files, 180, 182 Run Time Stack Checking, 150 Running state, 12, 26 S SafeRTOS, Soft real time, spare processing capacity measuring spare processing capacity, 31 sprintf(), 148 Stack Overflow, 149 stack overflow hook, 150 starvation, 24 starving starvation, 26 state diagram, 27 Suspended State, 27 suspending the scheduler, 121 swapped in, 12 swapped out, 12 switched in, 12 switched out, 12 Synchronization, 84 Synchronization events, 26 194 This document was supplied to jmclurkin@rice.edu T tabs, 187 task, Task Functions, 11 task handle, 15, 43 Task Parameter, 19 Task Priorities, 22 taskYIELD(), 52, 70 Temporal temporal events, 26 the xSemaphoreCreateMutex(), 126 thread, tick count, 23 tick hook function, 133 tick interrupt, 22 ticks, 22 time slice, 22 Type Casting, 188 U User Mode, 157 uxQueueMessagesWaiting(), 66 uxTaskGetStackHighWaterMark(), 149 uxTaskPriorityGet(), 40 V vApplicationStackOverflowHook, 150 Variable Names, 187 vPortFree(), 140 vSemaphoreCreateBinary(), 85, 99 vTaskAllocateMPURegions(), 168 vTaskDelay(), 28 vTaskDelayUntil(), 31 vTaskDelete(), 46 vTaskPrioritySet(), 40 vTaskResume(), 27 vTaskSuspend(), 27 vTaskSuspendAll(), 122 X xMemoryRegion, 162 xPortGetFreeHeapSize(), 145 xQueueCreate(), 60 xQueueHandle, 60 xQueuePeek(), 63 xQueueReceive(), 63 xQueueReceiveFromISR(), 103 xQueueSend(), 61 xQueueSendFromISR(), 103 xQueueSendToBack(), 61 xQueueSendToBackFromISR(), 103 xQueueSendToFront(), 61 xQueueSendToFrontFromISR(), 103 xSemaphoreCreateCounting(), 99 xSemaphoreGiveFromISR(), 89 xSemaphoreHandle, 85, 99, 126 xSemaphoreTake(), 88 xTaskCreate(), 13 xTaskCreateRestricted(), 162 xTaskGetTickCount(), 33 xTaskParameters, 162 www.FreeRTOS.org xTaskResumeAll(), 122 xTaskResumeFromISR(), 27 This document was supplied to jmclurkin@rice.edu Z zip file, 178 195 www.FreeRTOS.org 196 This document was supplied to jmclurkin@rice.edu