Software Development with an Open Source RTOS

Size: px

Start display at page:

Download "Software Development with an Open Source RTOS"

Hillary Craig
6 years ago
Views:

1 Software Development with an Open Source RTOS Fatih Peksenar - Sr. Manager, Application Engineering Class ID: 9L02I Renesas Electronics America Inc.

Mr. Fatih Peksenar Manager, Applications Engineering Responsible for integrated firmware development environment framework within the Renesas America Applications Group.

2 Mr. Fatih Peksenar Manager, Applications Engineering Responsible for integrated firmware development environment framework within the Renesas America Applications Group. Ported FreeRTOS to various Renesas platforms. Examples are: RSKH8S1668, RSKSH7216, RSKRX62N, RDKRX62N PREVIOUS EXPERIENCE: Lead software engineer for telecom companies where used various RTOS frameworks including: VxWorks, ecos, MQX, and other home grown kernels MSEE from the University of Minnesota 2

3 Renesas Technology & Solution Portfolio 3

4 8/16-bit 32-bit Microcontroller and Microprocessor Line-up DMIPS, Superscalar Automotive & Industrial, 65nm 600µA/MHz, 1.5µA standby 500 DMIPS, Low Power Automotive & Industrial, 90nm 600µA/MHz, 1.5µA standby 165 DMIPS, FPU, DSC Industrial, 90nm 242µA/MHz, 0.2µA standby 25 DMIPS, Low Power Industrial & Automotive, 150nm 190µA/MHz, 0.3µA standby 10 DMIPS, Capacitive Touch Industrial & Automotive, 130nm Wide 350µA/MHz, Format LCDs 1µA standby 1200 DMIPS, Performance Automotive, 40nm 500µA/MHz, 35µA deep standby 165 DMIPS, FPU, DSC Industrial, 40nm 242µA/MHz, 0.2µA standby Embedded Security, ASSP Industrial, 90nm 1mA/MHz, 100µA standby 44 DMIPS, True Low Power Industrial & Automotive, 130nm 144µA/MHz, 0.2µA standby 4

8/16-bit 32-bit Microcontroller and Microprocessor Line-up 2010 2013 1200 DMIPS, Superscalar

5µA standby 500 DMIPS, Low Power 32-Bit High Performance Automotive DSP, & FPU Industrial, with

2µA standby 25 DMIPS, Low Power Industrial & Automotive, 150nm 190µA/MHz, 0.

1µA standby 1200 DMIPS, Performance Automotive, 40nm 500µA/MHz, 35µA deep standby 165 DMIPS, FPU,

5 8/16-bit 32-bit Microcontroller and Microprocessor Line-up DMIPS, Superscalar Automotive & Industrial, 65nm 600µA/MHz, 1.5µA standby 500 DMIPS, Low Power 32-Bit High Performance Automotive DSP, & FPU Industrial, with High 90nm Integration 600µA/MHz, 1.5µA standby 165 DMIPS, FPU, DSC Industrial, 90nm 242µA/MHz, 0.2µA standby 25 DMIPS, Low Power Industrial & Automotive, 150nm 190µA/MHz, 0.3µA standby 10 DMIPS, Capacitive Touch Industrial & Automotive, 130nm Wide 350µA/MHz, Format LCDs 1µA standby 1200 DMIPS, Performance Automotive, 40nm 500µA/MHz, 35µA deep standby 165 DMIPS, FPU, DSC Industrial, 40nm 242µA/MHz, 0.2µA standby Embedded Security, ASSP Industrial, 90nm 1mA/MHz, 100µA standby 44 DMIPS, True Low Power Industrial & Automotive, 130nm 144µA/MHz, 0.2µA standby 5

6 Enabling The Smart Society DVR Game Console Smart Phones Navigation Systems Music Players Tablet PC 6

7 Agenda Definitions Why RTOS? Why FreeRTOS? Lab Exercises Questions Feedback Form 7

8 Definitions, RTOS, and FreeRTOS 8

9 What is Your RTOS Experience? I have previously used an RTOS in a commercial product I am using an RTOS in my current project I am considering using an RTOS in the near future and would like to get as much info as possible I am a Super-Loop user and here to burn you down 9

10 Some Definitions REAL-TIME: Computing with a deadline Hard real-time (Air bag) Soft real-time (Adaptive volume) TASK: Self contained code that handles a singular functionality or semi-independent portion of an application Process Thread SCHEDULER: Implements the scheduling policy Kernel Operating system (OS) PRIORTY: Used in arbitration mechanism 10

11 Why Use an RTOS? (1 of 2) Abstracting timing information Kernel is responsible for system time Modularity Tasks are independent modules with well defined purpose Team development Designers can work on different tasks simultaneously Code reuse Modules allow code re-use with less effort Improved efficiency Event driven software Code executes only when it is needed 11

12 Why Use an RTOS? (2 of 2) Flexible interrupt handling Short interrupt routines that detects events Most of the work deferred to a task Mixed processing requirements Periodic execution Continuous functions Event driven processing Real-time requirement ordering with priorities Control over peripherals Shared resources Gatekeeper tasks 12

13 Why FreeRTOS? Widely used and known Open source Simple and easy to port Feature rich but small size Free use and distribute Path to commercial versions OpenRTOS: Full support, additional components SafeRTOS: Functional safety, IEC compliant More on FreeRTOS site

14 What is our role with FreeRTOS? Port FreeRTOS to Renesas MCUs Work with FreeRTOS to qualify ports Provide sample projects with FreeRTOS Direct Drive LCD Firmware Integration Technology (FIT) Support by FreeRTOS Partner with other RTOS vendors for full support Micrium: uc/os Segger: embos CMX: CMX-RTX 14

15 Lab Exercises 15

16 General Notes on Lab Exercises Refer to lab handout Total of 6 lab exercises Short description up front About 10-minute labs Recap at end LEDs show running task LED5 Task1 LED6 Task2 LED7 Task3 LED8 Task 4 LED9 Run time stats LED10 Idle Task 16

17 Lab Exercise 1 - Tasks, Priorities, Task States 17

18 Lab Exercise 1 - Tasks, Priorities, Task States APIs: xtaskcreate(), vtaskdelay(), vtaskdelayuntil(), vtaskstartscheduler() Suspended vtasksuspend() Pre-emptive scheduling Highest priority ready task vtasksuspend() vtaskresume() Time slice same priority tasks Ready Running Idle task vtasksuspend() Event Low priority background or continuous tasks Spare processing time System in low power MUST NOT BLOCK! Blocked Blocking API function 18

19 Lab Exercise 1 You can start the lab now 19

20 Lab Exercise 1 Recap (1 of 3) 20

21 Lab Exercise 1 Recap (2 of 3) 21

Lab Exercise 1 Recap (3 of 3) Hard real time -> Higher priority Soft real time -> Lower priority Execution times Processor utilization Rate Monotonic Scheduling (RMS) Unique priority

22 Lab Exercise 1 Recap (3 of 3) Hard real time -> Higher priority Soft real time -> Lower priority Execution times Processor utilization Rate Monotonic Scheduling (RMS) Unique priority based on the periodic execution rate The higher periodic execution the higher the priority Better scheduling of tasks Not all tasks are periodic Execution times must be considered 22

23 Lab Exercise 2 Queue Management 23

24 Lab Exercise 2 Queue Management APIs: xqueuecreate(), xqueuesendtoback(), xqueuesendtofront(), xqueuereceive(), uxqueuemessageswaiting() Head Communication between tasks and interrupts Blocking API call Not owned by a particular task Send Tail Tail Tail Receive 20 Any task can write to a queue Any task can read from a queue Byte by byte copy of the data 24

25 Lab Exercise 2 More on Queues Use pointers for large data Pointers queued Some rules must be followed Clearly define the owner of RAM Avoid simultaneous memory modifications Sending task accesses the memory until pointer is queued Receiving task accesses the memory after the pointer is received from the queue NO ACCESS IN BETWEEN! Make sure RAM being pointed is valid DO NOT USE STACK! RAM Tail 10 Head 20 25

26 Lab Exercise 2 You can start the lab now 26

27 Lab Exercise 2 Recap (1 of 3) Receiver task is the highest priority task so it runs as soon as data is sent to queue and removes it. Therefore, the items in queue is always zero. There are 2 sender tasks and 1 receiver task. The receiver tasks runs twice as more and prints out 2 messages. Therefore it consumes more MCU processing time. 27

28 Lab Exercise 2 Recap (2 of 3) Receiver task priority is lower than the sender tasks. Sender tasks fills the queue and can not send anymore. All tasks are at the same priority so they are time-sliced. Number of items in the queue can be as much as 2. 28

29 Lab Exercise 2 Recap (3 of 3) No sender tasks. Receiver task blocks waiting for a message but times out. Queue API calls can Return immediately Block indefinitely Block for a certain period of time 29

30 Lab Exercise 3 Interrupt Management 30

31 Lab Exercise 3 Interrupt Management Events Message reception Button push Exceeding a threshold Priority Detection methods Polled Interrupt driven Processing interrupts In the ISR In the handler task ISR Handler Task Task1 t1 t2 t3 Time Semaphores links events to tasks Let s look at a sequence of events 31

32 Lab Exercise 3 Semaphores APIs: vsemaphorecreatebinary(), xsemaphorecreatecounting(), xsemaphoregivefromisr(), xsemaphoretake() Binary semaphore Queue with a length of one Always either empty or full Counting semaphore Event count, initial value = zero Resource management, initial count = number of resource Another Interrupt interrupt gives event the gives semaphore the semaphore xsemaphoregivefromisr() Task Semaphore is xsemaphoretake() available. Task unblocks. 32

33 Lab Exercise 3 You can start the lab now 33

periodic task resumes Sequence of events (soft real-time) Periodic task causes an interrupt ISR runs and gives the

34 Lab Exercise 3 Recap (1 of 2) Sequence of events (hard real-time) Periodic task causes an interrupt ISR runs and gives the semaphore ISR requests context switch Context switches and handler task runs Context switches back and periodic task resumes Sequence of events (soft real-time) Periodic task causes an interrupt ISR runs and gives the semaphore ISR does not requests context switch Periodic task continues Context switches at next timer tick Handler task runs 34

35 Lab Exercise 3 Recap (2 of 2) Counting semaphores Event detection Resource management Similar sequence of events ISR gives 3 semaphores Handler task takes them and processes the events ISR returns to Periodic task 35

36 Lab Exercise 4 Resource Management 36

37 Lab Exercise 4 Resource Management Resource sharing/peripheral access LCD, standard IO, memory Read/Modify/Write operation Non-atomic operations Non-atomic access to variables Multiple member of a structure 32-bit access on a 16-bit device Reentrant Functions Safe to call from more than one task/interrupt No data access other than on stack or registers 37

38 Lab Exercise 4 Best Practices Do not share resources Use mutual exclusion when accessing a shared resource Access a resource only from a single task RTOS tools for resource management Creating critical sections taskenter_critical() Suspending the scheduler vtasksuspendall() Make use of mutexes Designing gatekeeper tasks 38

39 Lab Exercise 4 Mutual Exclusion = Mutexes APIs: xsemaphorecreatemutex(), xsemaphoretake(), xsemaphoregive() Special type of binary semaphore Used to control a shared resource A task takes the mutex before accessing the resource No other tasks can use the resource when mutex is taken The task gives the mutex back after it is done Resource is now available to other tasks Works as longs as all agree with these rules 39

40 Lab Exercise 4 You can start the lab now 40

exercises? Messages printed from basic_io.

41 Lab Exercise 4 Recap Print 2 is a higher priority tasks and preempts Print 1 task corrupting the output Why we did not see this in previous exercises? Messages printed from basic_io.c file using vtasksuspendall() and xtaskresumeall() calls No corruption in the output when mutex is used 41

42 Lab Exercise 5 Priority Inversion, Inheritance 42

43 Lab Exercise 5 Priority Inversion, Inheritance HP Task MP Task Priority Inversion: HP task delayed by LP and MP tasks LP Task t1 t2 t3 t5 t6 Time HP Task MP Task Priority Inheritance: LP task raises its priority to HP task priority LP Task t1 t2 t3 t4 t5 Time 43

44 Lab Exercise 5 You can start the lab now 44

Lab Exercise 5 Recap (1 of 2) Initially, semaphore is used LP task takes the resource, and resumes MP task MP task takes 7 seconds to complete HP task attempts to run

45 Lab Exercise 5 Recap (1 of 2) Initially, semaphore is used LP task takes the resource, and resumes MP task MP task takes 7 seconds to complete HP task attempts to run every 1 second but it blocks waiting for the resource still hold by LP task PRIORTIY INVERTION HP task ready but can not run LP task holds on the resource 7 seconds delay 45

Lab Exercise 5 Recap (2 of 2) Use of mutex LP task raises to HP task level and gives the resource back No 7 seconds delay HP task runs every 1 second as planned PRIORTY INHERITANCE No

46 Lab Exercise 5 Recap (2 of 2) Use of mutex LP task raises to HP task level and gives the resource back No 7 seconds delay HP task runs every 1 second as planned PRIORTY INHERITANCE No delay HP task runs about 7 times between LP task executions Both task waiting for the same resource HP task is blocked LP task briefly raises its priority to the same level with HP task 46

47 Lab Exercise 6 Gatekeeper Tasks 47

48 Lab Exercise 6 Gatekeeper Tasks Gatekeeper task has sole ownership of a resource Only the gatekeeper task accesses the resource Other tasks access the recourse through the services provided by the gatekeeper Things to consider when creating gatekeeper tasks Up front system design Agree on services and interfaces Allow for future expansion/changes Always use the services of the gatekeeper to access the resource 48

49 Lab Exercise 6 You can start the lab now 49

50 Lab Exercise 6 Recap Print 1, Print 2 tasks, real-time statistics task and an interrupt service routine use the services of a gatekeeper task Gatekeeper task uses a queue as an interface No corruption with the print out 50

51 Questions? 51

52 Enabling The Smart Society DVR Game Console Smart Phones Navigation Systems Music Players Tablet PC 52

53 Please Provide Your Feedback Please utilize the Guidebook application to leave feedback or Ask me for the paper feedback form for you to use 53

54 Renesas Electronics America Inc.

Using the FreeRTOS Real Time Kernel

Using the FreeRTOS Real Time Kernel i ii Using the FreeRTOS Real Time Kernel Renesas RX600 Edition Richard Barry iii First edition published 2011. All text, source code and diagrams are the exclusive property