Software Development with an Open Source RTOS

Lab Exercise 1 - Tasks, Priorities, Task States Highest priority ready task  Time slice same priority tasks  Idle task  Low priority background or continuous tasks  Spare processin

Trang 1

Software Development with an Open Source RTOS

Trang 2

2

Renesas Technology & Solution Portfolio

Trang 3

Microcontroller and Microprocessor Line-up

Industrial & Automotive, 130nm

44 DMIPS, True Low Power Embedded Security, ASSP

25 DMIPS, Low Power

10 DMIPS, Capacitive Touch

 Industrial & Automotive, 150nm

 190µA/MHz, 0.3µA standby

 Industrial, 90nm

 Automotive & Industrial, 90nm

 500µA/MHz, 35µA deep standby

 1mA/MHz, 100µA standby

Trang 4

4

Microcontroller and Microprocessor Line-up

Wide Format LCDsIndustrial & Automotive, 130nm350µA/MHz, 1µA standby

44 DMIPS, True Low Power Embedded Security, ASSP

25 DMIPS, Low Power

10 DMIPS, Capacitive Touch

 500µA/MHz, 35µA deep standby

 1mA/MHz, 100µA standby

Trang 5

‘Enabling The Smart Society’

DVR

Game Console

Smart Phones

Navigation Systems

Music Players

Tablet PC

Trang 6

Trang 7

Definitions, RTOS, and FreeRTOS

Trang 8

8

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

Trang 9

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

Trang 10

10

Why Use an RTOS? (1 of 2)

 Abstracting timing information

 Kernel is responsible for system time

 Event driven software

 Code executes only when it is needed

Trang 11

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

Trang 12

12

Why FreeRTOS?

 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

Trang 13

What is our role with FreeRTOS?

 Work with FreeRTOS to qualify ports

 Provide sample projects with FreeRTOS

Trang 14

Lab Exercises

Trang 15

General Notes on Lab Exercises

 Refer to lab handout

 Total of 6 lab exercises

Trang 16

16

Lab Exercise 1 - Tasks, Priorities, Task States

Trang 17

Lab Exercise 1 - Tasks, Priorities, Task States

 Highest priority ready task

 Time slice same priority tasks

 Idle task

 Low priority background or continuous tasks

 Spare processing time

 System in low power

Trang 18

18

Lab Exercise 1 – You can start the lab now

Trang 19

Lab Exercise 1 – Recap (1 of 3)

Trang 20

20

Trang 21

 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

Trang 22

22

Lab Exercise 2 – Queue Management

Trang 23

Lab Exercise 2 – Queue Management

 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

Tail

Head

20 10

Send 10

Tail

10

Head

Receive 20

Trang 24

24

Lab Exercise 2 – More on Queues

 Use pointers for large data

 Pointers queued

 Some rules must be followed

 Clearly define the owner of

Trang 25

Trang 26

26

 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

Trang 27

 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

Trang 28

28

 No sender tasks Receiver task

blocks waiting for a message but

Trang 29

Lab Exercise 3 – Interrupt Management

Trang 30

 In the handler task

 Semaphores links events to tasks

 Let’s look at a sequence of events

Trang 31

Lab Exercise 3 – Semaphores

 APIs: vSemaphoreCreateBinary(),

xSemaphoreCreateCounting(),

xSemaphoreGiveFromISR(), xSemaphoreTake()

 Queue with a length of one

 Always either empty or full

 Event count, initial value = zero

 Resource management, initial count = number of resource

Task

Interrupt gives the semaphore xSemaphoreGiveFromISR()

Task Task

Semaphore is available Task unblocks.

Another interrupt event gives the semaphore xSemaphoreGiveFromISR()

xSemaphoreTake() Task

Trang 32

32

Trang 33

 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

Trang 34

 Similar sequence of events

 Handler task takes them and

processes the events

 ISR returns to Periodic task

Trang 35

Lab Exercise 4 – Resource Management

Trang 36

36

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

Trang 37

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

Trang 38

38

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

Trang 39

Trang 40

40

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

Trang 41

Lab Exercise 5 – Priority Inversion, Inheritance

Trang 42

Priority Inheritance: LP task raises its priority to HP task priority

Trang 43

Trang 44

44

 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

 HP task ready but can not run

 LP task holds on the resource

7 seconds delay

Trang 45

 LP task raises to HP task level

and gives the resource back

No delay

Trang 46

46

Lab Exercise 6 – Gatekeeper Tasks

Trang 47

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

Trang 48

48

Trang 49

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

Trang 50

Questions?

Trang 51