1 / 36

Micrium’s μ C/OS for Makers A Hands-on Course

Micrium’s μ C/OS for Makers A Hands-on Course. Class 5: Mutexes, Messages, and Semaphores, Oh My!. February 3, 2017 Charles J. Lord, PE President, Consultant, Trainer Blue Ridge Advanced Design and Automation. This Week’s Agenda.

nealk
Download Presentation

Micrium’s μ C/OS for Makers A Hands-on Course

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Micrium’s μC/OS for Makers A Hands-on Course Class 5: Mutexes, Messages, and Semaphores, Oh My! February 3, 2017 Charles J. Lord, PEPresident, Consultant, TrainerBlue Ridge Advanced Design and Automation

  2. This Week’s Agenda 1/30 Introduction to μC/OS II/III1/31 The Micrium Maker Program 2/1 Setting up our Development System 2/2 Writing Our Tasks and Establishing Scheduling 2/3Mutexes, Messages, and Semaphores, Oh My!

  3. This Week’s Agenda 1/30 Introduction to μC/OS II/III1/31 The Micrium Maker Program 2/1 Setting up our Development System 2/2 Writing Our Tasks and Establishing Scheduling 2/3Mutexes, Messages, and Semaphores, Oh My!

  4. Where’s the Code? • I will be posting the code for this class at my GitHub location • https://github.com/cjlord/CECmicrium/

  5. Task Interaction • The tasks in a µC/OS-III-based application are not necessarily self-contained • Tasks may need to interact with each other (and possibly with ISRs). • A typical kernel provides services that facilitate such interaction

  6. Synchronizing a Task to an ISR • Most applications must manage a collection of peripheral devices • The interrupt service routines (ISRs) associated with a system’s peripheral devices should be kept brief • In applications that incorporate a real-time kernel, ISRs can use synchronization primitives to signal tasks Question 1 – why would an ISR need to be short?

  7. Problems with Lengthy ISRs • On many architectures, a long ISR can significantly increase interrupt latency • Excessively large stacks may be needed in order to support lengthy ISRs • Debugging interrupt handlers can be difficult • Many kernel functions cannot be invoked by ISRs

  8. Semaphores • Using a semaphore, a task can synchronize to another task or to an ISR • Semaphores are based on counters • A semaphore can be classified as either binary or counting

  9. Semaphore Operations • Pend • While the semaphore’s counter has a value of zero, allow other tasks to run • One of the parameters accepted by µC/OS-III’s pend functions is a timeout value that indicates how long the calling task is willing to wait • Post • Increment the semaphore’s counter • If a task is waiting on the semaphore, that task will be placed in the Ready state when the post operation occurs

  10. Semaphore API void OSSemCreate (OS_SEM *p_sem, CPU_CHAR *p_name, OS_SEM_CTR cnt, RTOS_ERR *p_err); OS_SEM_CTR OSSemPend (OS_SEM *p_sem, OS_TICK timeout, OS_OPT opt, CPU_TS *p_ts, RTOS_ERR *p_err); OS_SEM_CTR OSSemPost (OS_SEM *p_sem, OS_OPT opt, RTOS_ERR *p_err);

  11. ADC Semaphore Example OS_SEM App_SemADC; /* Initialization Code */ OSSemCreate((OS_SEM *)&App_SemADC, (CPU_CHAR *)”ADC Sem”, (OS_SEM_CTR)0, (OS_ERR *)&err); void App_ISRADC (void) { Clear interrupt; OSSemPost((OS_SEM *)&App_SemADC, (OS_OPT )OS_OPT_POST_1, (OS_ERR *)&err); } MUX ADC Task Analog Inputs void App_TaskADC (void *p_arg) { Perform initializations; while (1) { Start conversion; OSSemPend((OS_SEM *)&App_SemADC, (OS_TICK )0, (OS_OPT )OS_OPT_PEND_BLOCKING, (CPU_TS *)&ts, (OS_ERR *)&err); Process converted value; } } ISR

  12. Counting Semaphores • µC/OS-III’s semaphores are of the counting variety • The kernel does not limit the semaphore state to 1 or 0 • In the previous example the potential for the semaphore’s value to rise above 1 could actually be detrimental • Other kernel objects can be used in cases where a binary semaphore would be advantageous to a counting semaphore

  13. Event Flags • Using event flags, a task can easily wait for multiple events to take place • A single 8-, 16-, or 32-bit variable, contained in a structure known as an event flag group, represents a collection of events • Each bit in the variable corresponds to a single event • Application code determines whether a set or cleared bit indicates the occurrence of an event

  14. Shared Resources • A global variable or data structure that is used by multiple tasks is considered a shared resource • Variables accessed by both tasks and ISRs are also shared resources • Oftentimes, peripheral devices are shared resources • For example, an Ethernet controller that is accessed by multiple tasks

  15. Problems Created by Shared Resources • While one task is manipulating a shared resource, other tasks should not be able to gain access to that resource • If this rule is not enforced, tasks might read corrupt data • Bugs resulting from the corruption of shared resources can be highly frustrating

  16. Protecting Shared Resources • Application developers are responsible for controlling access to their code’s shared resources • µC/OS-III provides services for protecting shared resources Question 2 – Another example of a shared resource that needs protection?

  17. What needs to be protected? • Read-modify-write passages are notorious sources of data corruption Short pieces of code that simply read or write global variables can cause problems too, though

  18. Disabling Interrupts • Interrupts are disabled before each shared resource is accessed and then re-enabled afterwards • µC/OS-III, like other kernels, uses this method to protect its own global variables • Application code can disable interrupts for short periods of time without negatively impacting interrupt latency

  19. Semaphores • In addition to being well suited for synchronization, semaphores can be used for protecting shared resources • Semaphores were originally designed for this purpose • The same semaphore API functions are used for both synchronization and resource protection

  20. Semaphores (continued) • When a semaphore is used for protecting a shared resource, tasks must pend on the semaphore before accessing the resource • This method cannot be used for resources that are accessed by ISRs • If the value of the semaphore’s counter is 0, the resource is unavailable • Interrupts and context switches can occur while shared resources are being accessed

  21. Priority Inversions • There is a well documented problem associated with the use of semaphores for resource protection • The problem, known as priority inversion, can arise when a low priority task is in the midst of accessing a resource that is needed by a higher priority task

  22. Priority Inversion (Continued) High-priority task Medium-priority task Low-priority task

  23. Mutexes • A mutex is yet another mechanism for protecting shared resources • In µC/OS-III, mutexes provide built-in protection from priority inversion • Priority inheritance • Unlike a semaphore, a µC/OS-III mutex does not incorporate a counter • The mutex is either available or in use

  24. Choosing How to Protect Shared Resources • Shared resources that are accessed by ISRs can only be protected by disabling interrupts • Application code should not disable either interrupts are the scheduler for extended periods of time • Semaphores should only be used for synchronization • Mutexes protect against priority inversion

  25. µC/OS-III’s Inter-Task Communication Services • Tasks in a µC/OS-III-based application can send and receive messages using services that the kernel provides • Application developers determine the contents of these messages • µC/OS-III’s message passing services (or more formally, its inter-task communication services) have much in common with its synchronization and mutual exclusion services

  26. Message Queues • In µC/OS-III, a message queue is a list of OS_MSG structures • The kernel manages the list • Through API functions, tasks can request the insertion or removal of messages • A message is a void pointer • When a task is waiting on a message, the kernel runs other tasks

  27. MessageQueue Message Queue Example USB Task USB ISR OS_Q App_QUSB; /* Initialization Code */ OSQCreate((OS_Q *)&App_QUSB, (CPU_CHAR *)”USB Queue”, (OS_MSG_QTY)20, (OS_ERR *)&err); void App_Task_USB (void *p_arg) { while (1) { p_buf = OSQPend((OS_Q *)&App_QUSB, (OS_TICK )0, (OS_OPT)OS_OPT_PEND_BLOCKING, (OS_MSG_SIZE *)&msg_size, (CPU_TS *)&ts, (OS_ERR *)&err); Process packet; Free buffer back to pool; } } void App_ISR_USB (void) { Clear USB (or DMA) interrupt; p_buf = Get Buffer from pool; OSQPost((OS_Q *)&App_QUSB, (void *)p_buf, (OS_MSG_SIZE)buf_size, (OS_OPT )OS_OPT_POST_FIFO, (OS_ERR *)&err); }

  28. Type Casting Messages • By casting messages, developers can sometimes avoid dealing with shared data • Sending tasks and receiving tasks must not interpret messages differently Question 3 – An example of shared data between tasks?

  29. Another model for Resource Protection • Queues can be used to regulate access to controlled resources • Only one task directly accesses the resource and that task receives messages from others • “Using design patterns to identify and partition RTOS tasks: Part 2,” Michael C. Grischy and David E. Simon, Embedded.com,www.embedded.com/columns/technicalinsights/179103020?_requestid=206440

  30. Section Summary – Configuration • Developers should be conscious of kernel configuration and the potential impact it can have on memory footprint • Under the RTOS, application developers control the initial µC/OS-III configuration using the Platform Builder • Changes can be made to many parameters at run time using API calls

  31. Port Overview • A kernel port adapts µC/OS-III to a particular CPU architecture • Most ports are written in a combination of C and assembly language • Oftentimes, a port must be modified to migrate to a new tool-chain • A µC/OS-III port normally consists of three files • os_cpu.h • os_cpu_a.s • os_cpu_c.c

  32. Question 4: What topics would you like to see?

  33. Our Next Class!! Tune in on February 13-18, 2017 for our next CEC class: “Designing API’s and HAL’s for Real-Time Embedded Systems” Instructor: Jacob Beningo

  34. References • Jean Labrosse’s CEC on Micrium μC/OS II/IIIhttps://www.designnews.com/continuing-education-center/introduction-real-time-kernels • My CEC on Multitaskinghttps://www.designnews.com/continuing-education-center/multitasking-scratch • My CEC on MQXhttps://www.designnews.com/continuing-education-center/hands-on-develop-rtos-application-using-freescale-mqx • My CEC on FreeRTOShttps://www.designnews.com/continuing-education-center/hands-on-develop-rtos-application-using-freertos

  35. This Week’s Agenda 1/30 Introduction to μC/OS II/III1/31 The Micrium Maker Program 2/1 Setting up our Development System 2/2 Writing Our Tasks and Establishing Scheduling 2/3Mutexes, Messages, and Semaphores, Oh My!

  36. Please stick around as I answer your questions! • Please give me a moment to scroll back through the chat window to find your questions • I will stay on chat as long as it takes to answer! • I am available to answer simple questions or to consult (or offer in-house training for your company)c.j.lord@ieee.orghttp://www.blueridgetechnc.comhttp://www.linkedin.com/in/charleslordTwitter: @charleslordhttps://www.github.com/bradatraining

More Related