Mobile and Embedded Device

Why use an OS?

● In our previous work we have seen how to execute a number of tasks on our system

● Some of these tasks can run asynchronously – For example interrupt driven tasks ● So if we want to exploit the resources of our system efficiently we require some software support to do this – Namely an operating system

Which Operating System?

● There are a number of choices when selecting an OS – Size, cost, features ● Free – FreeRTOS: http://www.freertos.org – TinyOS: http://www.tinyos.net – Chibios: http://www.chibios.org/ – eCos, uKOS, EROS, Nut/OS – Various Linux flavours ● Commercial – VxWorks: http://www.windriver.com – QNX: http://www.qnx.com – SafeRTOS: http://www.highintegritysystems.com/safertos.html – uC/OSII: http://www.micrium.com – Salvo: http://www.pumpkininc.com – INTEGRITY, VelOSity, THEOS, RMX

Why FreeRTOS

● Free (Both “Speech” and “Beer”) – No Royalties, Open Source – Although documentation costs ● Lightweight – Low overhead, simple code ● Portable – ~8 major architectures officially supported, more unofficially ● Cooperative or Preemptive – We're going to be using preemptive ● Good Documentation – http://www.freertos.org – Look under FreeRTOS API – Functional docs plus code examples ● Developed by an Ex-Student! – Richard Barry, BSc CRTS

What required from an OS?

● For small embedded systems they are required to be – Small memory footprint – Efficient use of resources – Fast ● We require what is normally called an 'executive' rather than an operating system – Lots of features can be missing or excluded

● No file system ● No/limited user protection ● Limited system accounting

Tasks

● At a minimum the RTOS should offer the ability to run a series of tasks

● These are separate programs

● They should be able to be scheduled

● Co-ordinated

● Prioritised

● Protected

Task life cycle

Task states

● Running: – currently executing task ● ready: – candidate for scheduling – running task has higher or equal priority – scheduler must choose next ready task with maximum priority ● Blocked: – task waiting on an event – temporal delay or external user interaction ● Suspended: – neither running, ready, nor blocked – cannot be executed until it becomes ready again ● Idle task: – systematically created in every application – lowest priority – may have idle-task hook – e.g., to put device in low power mode

FreeRTOS tasks

portBASE_TYPE xTaskCreate( pdTASK_CODE pvTaskCode, const signed portCHAR * const pcName, unsigned portSHORT usStackDepth, void *pvParameters, unsigned portBASE_TYPE uxPriority, xTaskHandle *pxCreatedTask );

pvTaskCode the actual function/program to run pcName the name – only sued for debugging usStackDepth the size of the stack in words uvParameters pointers to the parameters – can be NULL

UxPriority the task priority – must be greater than 0 (Idle task) pxCreatedTask a handle to the task – like a file handle, used by other functions

Scheduling

● Requires tick interrupt – Time slicing ● Uses priorities

● Can be cooperative or preemptive

● Requires an idle task

●

Priorities

Column 1 6 Column 2 Column 3

0 Row 1 Row 2 Row 3 Row 4

Semaphores

● As tasks will frequently have access to data that may be difficult to share the system will require semaphores

● These will allow certain resources to be available yet protected

● There are – Binary, mutexs and counting semaphores

Queues

● As many tasks will be waiting on some of the scheduler's queues or waiting for resources or events, FreeRTOS needs to be able to provide safe and reliable access to queues

● There are a whole series of primitives that are provided for queue management which allow queues to interact with semaphores and interrupts

Porting

● The ARM architecture is well supported

● There are ports to some Cortex M3 devices

● There is little in the way of devices – These must be written by the developer

● Although there are a number around ● The file FreeRTOSConfig.h is used for all the main configuration information