Presentation is loading. Please wait.

Presentation is loading. Please wait.

Renesas Electronics America Inc. © 2012 Renesas Electronics America Inc. All rights reserved. Class ID: 9L02I Software Development with an Open Source.

Similar presentations


Presentation on theme: "Renesas Electronics America Inc. © 2012 Renesas Electronics America Inc. All rights reserved. Class ID: 9L02I Software Development with an Open Source."— Presentation transcript:

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

2 © 2012 Renesas Electronics America Inc. All rights reserved.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

3 © 2012 Renesas Electronics America Inc. All rights reserved.3 Renesas Technology & Solution Portfolio

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

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

6 © 2012 Renesas Electronics America Inc. All rights reserved.6 ‘Enabling The Smart Society’ DVR Game Console Smart Phones Navigation Systems Music Players Tablet PC

7 © 2012 Renesas Electronics America Inc. All rights reserved.7 Agenda Definitions Why RTOS? Why FreeRTOS? Lab Exercises Questions Feedback Form

8 © 2012 Renesas Electronics America Inc. All rights reserved.8 Definitions, RTOS, and FreeRTOS

9 © 2012 Renesas Electronics America Inc. All rights reserved.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

10 © 2012 Renesas Electronics America Inc. All rights reserved.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

11 © 2012 Renesas Electronics America Inc. All rights reserved.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

12 © 2012 Renesas Electronics America Inc. All rights reserved.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

13 © 2012 Renesas Electronics America Inc. All rights reserved.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 61508 compliant More on FreeRTOS site http://www.freertos.org/ http://www.freertos.org/a00090.html#RENESAS

14 © 2012 Renesas Electronics America Inc. All rights reserved.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

15 © 2012 Renesas Electronics America Inc. All rights reserved.15 Lab Exercises

16 © 2012 Renesas Electronics America Inc. All rights reserved.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 LED5Task1 LED6Task2 LED7Task3 LED8Task 4 LED9Run time stats LED10Idle Task

17 © 2012 Renesas Electronics America Inc. All rights reserved.17 Lab Exercise 1 - Tasks, Priorities, Task States

18 © 2012 Renesas Electronics America Inc. All rights reserved.18 Lab Exercise 1 - Tasks, Priorities, Task States APIs: xTaskCreate(), vTaskDelay(), vTaskDelayUntil(), vTaskStartScheduler() Pre-emptive scheduling Highest priority ready task Time slice same priority tasks Idle task Low priority background or continuous tasks Spare processing time System in low power MUST NOT BLOCK!

19 © 2012 Renesas Electronics America Inc. All rights reserved.19 Lab Exercise 1 – You can start the lab now

20 © 2012 Renesas Electronics America Inc. All rights reserved.20 Lab Exercise 1 – Recap (1 of 3)

21 © 2012 Renesas Electronics America Inc. All rights reserved.21 Lab Exercise 1 – Recap (2 of 3)

22 © 2012 Renesas Electronics America Inc. All rights reserved.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

23 © 2012 Renesas Electronics America Inc. All rights reserved.23 Lab Exercise 2 – Queue Management

24 © 2012 Renesas Electronics America Inc. All rights reserved.24 Lab Exercise 2 – Queue Management APIs: xQueueCreate(), xQueueSendToBack(), xQueueSendToFront(), xQueueReceive(), uxQueueMessagesWaiting() Communication between tasks and interrupts Blocking API call Not owned by a particular task Any task can write to a queue Any task can read from a queue Byte by byte copy of the data

25 © 2012 Renesas Electronics America Inc. All rights reserved.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!

26 © 2012 Renesas Electronics America Inc. All rights reserved.26 Lab Exercise 2 – You can start the lab now

27 © 2012 Renesas Electronics America Inc. All rights reserved.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.

28 © 2012 Renesas Electronics America Inc. All rights reserved.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.

29 © 2012 Renesas Electronics America Inc. All rights reserved.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

30 © 2012 Renesas Electronics America Inc. All rights reserved.30 Lab Exercise 3 – Interrupt Management

31 © 2012 Renesas Electronics America Inc. All rights reserved.31 Lab Exercise 3 – Interrupt Management Events Message reception Button push Exceeding a threshold Detection methods Polled Interrupt driven Processing interrupts In the ISR In the handler task Semaphores links events to tasks Let’s look at a sequence of events

32 © 2012 Renesas Electronics America Inc. All rights reserved.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

33 © 2012 Renesas Electronics America Inc. All rights reserved.33 Lab Exercise 3 – You can start the lab now

34 © 2012 Renesas Electronics America Inc. All rights reserved.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

35 © 2012 Renesas Electronics America Inc. All rights reserved.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

36 © 2012 Renesas Electronics America Inc. All rights reserved.36 Lab Exercise 4 – Resource Management

37 © 2012 Renesas Electronics America Inc. All rights reserved.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

38 © 2012 Renesas Electronics America Inc. All rights reserved.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

39 © 2012 Renesas Electronics America Inc. All rights reserved.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

40 © 2012 Renesas Electronics America Inc. All rights reserved.40 Lab Exercise 4 – You can start the lab now

41 © 2012 Renesas Electronics America Inc. All rights reserved.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

42 © 2012 Renesas Electronics America Inc. All rights reserved.42 Lab Exercise 5 – Priority Inversion, Inheritance

43 © 2012 Renesas Electronics America Inc. All rights reserved.43 Lab Exercise 5 – Priority Inversion, Inheritance

44 © 2012 Renesas Electronics America Inc. All rights reserved.44 Lab Exercise 5 – You can start the lab now

45 © 2012 Renesas Electronics America Inc. All rights reserved.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

46 © 2012 Renesas Electronics America Inc. All rights reserved.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 Both task waiting for the same resource HP task is blocked LP task briefly raises its priority to the same level with HP task HP task runs about 7 times between LP task executions No delay

47 © 2012 Renesas Electronics America Inc. All rights reserved.47 Lab Exercise 6 – Gatekeeper Tasks

48 © 2012 Renesas Electronics America Inc. All rights reserved.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

49 © 2012 Renesas Electronics America Inc. All rights reserved.49 Lab Exercise 6 – You can start the lab now

50 © 2012 Renesas Electronics America Inc. All rights reserved.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

51 © 2012 Renesas Electronics America Inc. All rights reserved.51 Questions?

52 © 2012 Renesas Electronics America Inc. All rights reserved.52 ‘Enabling The Smart Society’ DVR Game Console Smart Phones Navigation Systems Music Players Tablet PC

53 © 2012 Renesas Electronics America Inc. All rights reserved.53 Please utilize the ‘Guidebook’ application to leave feedback or Ask me for the paper feedback form for you to use… Please Provide Your Feedback…

54 Renesas Electronics America Inc. © 2012 Renesas Electronics America Inc. All rights reserved.


Download ppt "Renesas Electronics America Inc. © 2012 Renesas Electronics America Inc. All rights reserved. Class ID: 9L02I Software Development with an Open Source."

Similar presentations


Ads by Google